117 lines
6.3 KiB
Markdown
117 lines
6.3 KiB
Markdown
# Registry des types métier de tâches
|
|
|
|
## Feature kinds v1A
|
|
|
|
La registry statique conserve `features.extract` v1 pour ORB et ajoute
|
|
`features.extract.sift` v1 et `features.extract.rootsift` v1. Les reconstructeurs
|
|
chargent la table dédiée, revalident le fingerprint et ne capturent aucun
|
|
`AppState`.
|
|
|
|
## Contrat
|
|
|
|
Une instance possède un **task ID** stable. Son **task kind** décrit son
|
|
comportement métier, son **task state** décrit son état d'avancement, la
|
|
**checkpoint version** décrit le codec générique et la **task kind version**
|
|
versionne les paramètres nécessaires au reconstructeur. Ces identités ne sont
|
|
pas interchangeables.
|
|
|
|
Le kind v1 est une chaîne ASCII de 1 à 64 caractères au format
|
|
`[a-z0-9][a-z0-9._-]*`. La version est un entier non nul. Aucun kind n'est
|
|
déduit d'un nom, callback ou pointeur et aucune normalisation n'est effectuée.
|
|
|
|
## Registry et ownership
|
|
|
|
La registry est une vue bornée à 64 descriptors sur un tableau statique
|
|
immutable. Le lookup est linéaire, déterministe, sans allocation et sûr en
|
|
lecture concurrente. Elle ne charge aucun code dynamiquement.
|
|
|
|
Un descriptor contient exactement le kind, sa version et un reconstructeur.
|
|
Le reconstructeur produit callback, userdata et destructeur optionnel. Avant le
|
|
transfert, la registry nettoie le userdata sur toute erreur ; après restauration
|
|
réussie, `Lardon3DTask` en devient propriétaire et le détruit une fois après la
|
|
fin de l'exécution. Le constructeur métier n'est jamais appelé sous mutex DB.
|
|
|
|
La registry peut normaliser une ancienne estimation opérationnelle connue. Le
|
|
reconstructeur reçoit toujours le snapshot durable original afin de valider le
|
|
mode exact ; la registry applique ensuite l'estimation effective uniquement à
|
|
la copie privée transmise à la restauration de `Task`. Cette normalisation est
|
|
éphémère et déterministe : elle ne stage, ne promeut et ne publie aucun
|
|
checkpoint contenant seulement une estimation différente sous le même résumé.
|
|
Une panne pré-terminale peut donc répéter la normalisation exacte. Cette couture
|
|
ne peut modifier ni identité, paramètres scientifiques, progression ou curseur
|
|
métier, et toute forme voisine est rejetée.
|
|
|
|
## Persistance et legacy
|
|
|
|
Le checkpoint générique reste en version 1. Project Database v7 conserve le
|
|
kind/version ; les lignes migrées depuis v1 restent `NULL/NULL` et sont classées
|
|
`LEGACY_UNTYPED`. Un kind inconnu ou une version non supportée reste inspectable
|
|
mais inexécutable. Aucun type n'est inventé et aucun code n'est sélectionné par
|
|
adresse persistée.
|
|
|
|
## Statut
|
|
|
|
**IMPLEMENTED** — identité typée immutable, registry statique, lookup,
|
|
migration DB v1→v2, classification recovery et restauration explicite testée.
|
|
|
|
**IMPLEMENTED** — le descriptor production `import.images`, version 1, charge
|
|
le chemin source borné depuis la table dédiée et reconstruit callback et
|
|
userdata sans `AppState *` ancien.
|
|
|
|
**IMPLEMENTED** — `project_open()` utilise la registry production immutable
|
|
pour restaurer hors mutex DB et transférer chaque tâche acceptée à la queue.
|
|
|
|
**NOT_YET_WIRED** — autosave complet et réconciliation orpheline.
|
|
|
|
**IMPLEMENTED** — `features.extract` version 1 reconstruit une extraction ORB
|
|
depuis `image_id` et ses paramètres bornés.
|
|
|
|
**IMPLEMENTED** — `visual_index.update`, version 1, recharge
|
|
`visual_index_id + after_feature_set_id` et reconstruit un contexte neuf.
|
|
|
|
**IMPLEMENTED** — `candidate_pair.generate`, version 1, recharge
|
|
`visual_index_id + after_feature_set_id + top_k + minimum_evidence_count
|
|
+ scanset_filter + exclude_same_asset` depuis `candidate_pair_generate_tasks`
|
|
et reconstruit un contexte boundé. La restauration reconnaît uniquement le
|
|
snapshot opérationnel sériel historique v1 exact et remplace éphémèrement sa
|
|
demande d'un thread CPU par douze avant admission. Le checkpoint historique et
|
|
le curseur typé restent inchangés. Les snapshots Candidate courants et tous les
|
|
autres kinds restent inchangés.
|
|
|
|
**IMPLEMENTED** — `matcher.run`, version 1, recharge la configuration Matcher,
|
|
l'identité Feature Set et le curseur `after_candidate_pair_id`. Il traite une
|
|
Candidate Pair atomique à la fois dans des lots bornés à huit, checkpoint le
|
|
curseur et repasse par le Governor entre les lots. La table durable
|
|
`matcher_tasks` est introduite par Project DB v11, après le Match Result v10.
|
|
Son reconstructeur accepte les formes opérationnelles exactes CPU8/GPU0 et
|
|
CPU1/GPU1/640 Kio, puis normalise éphémèrement leurs deux prédécesseurs CPU12
|
|
vers la forme courante correspondante avant l'admission. Une forme
|
|
voisine échoue au lieu de servir d'indice de backend ; le payload Project DB ne
|
|
change pas et ne persiste aucune identité matérielle.
|
|
|
|
**IMPLEMENTED** — `features.extract.sift` et `features.extract.rootsift`
|
|
acceptent leur forme CPU12 courante et normalisent uniquement leur forme CPU1
|
|
historique exacte. Cette compatibilité opérationnelle n'altère ni fingerprint,
|
|
Feature Set, checkpoint durable, ni politique scientifique.
|
|
|
|
**IMPLEMENTED** — `geometric_verifier.run`, version 1, recharge la configuration
|
|
Fundamental immuable, en revalide le fingerprint et reprend `after_match_result_id`.
|
|
Project DB v13 ajoute uniquement `geometric_verifier_tasks`, car le checkpoint
|
|
générique v1 ne possède aucun payload propre au kind.
|
|
|
|
**IMPLEMENTED** — `track_builder.run`, version 1, reconstruit un scope explicite
|
|
depuis son payload Project DB v15 et son asset little-endian validé. Le callback
|
|
réutilise l'orchestration Gate C et le reconstructeur refuse toute corruption,
|
|
version, fingerprint, checksum, tri, unicité ou L3DTSIS1 incohérents.
|
|
|
|
**PASS / FROZEN** — `sparse_sfm.run`, version 1, recharge le
|
|
payload scientifique explicite Project DB v17, restaure l'estimation générique
|
|
persistée et rejoue D puis E depuis les références Track Set/calibration. Le
|
|
fingerprint F0 est recalculé ; le checkpoint générique v1 reste inchangé.
|
|
|
|
**PASS / FROZEN** — `incremental_reconstruction.run`,
|
|
version 1, recharge le payload Project DB v18 composé du prédécesseur, du Track
|
|
Set d'extension, du scope de calibration et du fingerprint H. La tâche atomique
|
|
recalcule depuis ces entrées après redémarrage, passe par la Queue et le
|
|
Governor avec son estimation H immuable, et ne persiste aucun état de solveur.
|
|
Elle n'ajoute ni DAG ni dépendance implicite.
|