# Roadmap canonique Lardon3D Cette feuille de route décrit l'ordre de dépendance actuel. Les contrats détaillés restent dans `docs/architecture/`; ce document indique ce qui est fermé, ce qui vient immédiatement ensuite et ce qui demeure volontairement différé. ## Situation actuelle Lardon3D possède une chaîne scientifique persistante allant des acquisitions explicites aux frontières Sparse SfM et MVS validées. Les travaux volumineux doivent rester incrémentaux, bornés, reprenables, durables et admis par l'unique Resource Governor : aucune étape ne peut supposer qu'une campagne entière tient en RAM ou termine dans une seule vie de processus. ## POLITIQUE CANONIQUE D'UTILISATION DES RESSOURCES — HUMAN AUTHORITY La politique d'exploitation est désormais explicite : **Lardon3D doit viser le MAXIMUM SAFE USEFUL THROUGHPUT** sur chaque Task de production. Le Resource Governor réserve d'abord uniquement les ressources nécessaires pour que le poste reste normalement utilisable pendant les calculs : - Arch Linux / Sway et les services normaux du bureau ; - Firefox ; - lecture audio/musique normale ; - usage interactif léger. Tout CPU, RAM, capacité I/O et accélérateur validé restant appartient au travail Lardon3D lorsqu'un travail utile existe. La stabilité du poste est protégée par cette réserve interactive et par les signaux de pression ; elle ne justifie plus de laisser des ressources sûres et utiles inactives par conservatisme historique. Sur l'hôte de référence actuel, le résultat normal de cette politique est approximativement : ```text 16 CPU logiques au total 4 CPU logiques réservés à l'hôte interactif 12 CPU logiques disponibles au compute-pool ~3 GiB de MemAvailable conservés comme réserve RAM dure Radeon 780M UMA disponible pour les backends GPU validés et utiles ``` Ces nombres sont des **résultats de l'hôte courant**, jamais des constantes produit. Un futur hôte 32 threads ne doit pas hériter d'un plafond 12 ; le Governor doit dériver sa réserve et donner le reste au calcul selon topologie, affinité, pression et enveloppe réelle de la Task. La règle canonique est : ```text SERIALISM_REQUIRES_PROOF ``` Une opération atomique par item n'impose pas de sérialiser les items indépendants. Une publication owner-only ou ordonnée n'impose pas de sérialiser la préparation. Lorsqu'il existe plusieurs unités indépendantes et que la science, la persistance et la reprise restent exactes, la Task doit exposer au Governor un parallélisme borné. Un chemin long `CPU1` ou `batch1` avec travail indépendant disponible et ressources sûres libres est désormais considéré comme un **défaut opérationnel** tant qu'une preuve concrète ne démontre pas l'une des limites suivantes : - dépendance scientifique ou algorithmique réellement sérielle ; - genou de scaling mesuré ; - limite mémoire ; - saturation I/O ; - backend GPU validé rendant des CPU supplémentaires inutiles ; - contrainte de publication qui ne peut pas être séparée de la préparation sans casser le déterminisme ; - autre limitation matérielle mesurée et documentée. Le Governor reste l'unique autorité de ressources. L'utilisateur normal ne choisit ni CPU, ni workers, ni lot, ni inflight, ni GPU, ni scratch, ni budget RAM. Une Task décrit ses minimum/useful/safe, ses coûts fixes/transitoires/par participant et ses capacités GPU/I/O ; le Governor choisit le maximum sûr **et utile** disponible à l'instant. La politique GPU est symétrique : un backend de production **VALIDATED AND USEFUL** doit être préféré lorsqu'il est disponible et sûr ; aucun backend GPU non validé ne doit être inventé pour afficher de l'activité GPU. Candidate, Visual Index ou GV peuvent donc rester CPU lorsque leur décision mesurée le justifie, tandis qu'ORB Matcher Vulkan reste GPU-first lorsqu'il est éligible. La RAM doit être utilisée agressivement jusqu'à la réserve interactive ; `swap`, zram et scratch ne sont jamais de la RAM admise, et l'UMA est comptée exactement une fois contre la RAM hôte. Les signaux PSI et les deltas actifs de swap peuvent réduire l'admission ; après disparition de la pression, le Governor doit réadmettre les ressources utiles au lieu de rester durablement bridé. Cette politique s'applique aussi au travail d'ingénierie Codex : builds, tests, benchmarks et preuves réelles indépendantes doivent utiliser le parallélisme sûr disponible plutôt qu'un `-j8`/`--num-processes 1` historique. Un run CPU1 reste légitime comme cohorte de mesure ou lorsqu'une dépendance concrète l'impose, mais jamais comme défaut universel. Les rebuilds, tests lourds, revues ou agents coûteux déjà acquis et non affectés par le delta ne doivent pas être relancés sans raison. La règle reste : **WORK FIRST, RETURN LAST**, avec revue delta-based depuis le checkpoint de maintenance. Statut de cette décision : ```text RESOURCE_UTILIZATION_POLICY=HUMAN_AUTHORITY SERIALISM_REQUIRES_PROOF=CANONICAL IMPLEMENTATION_AUDIT=REQUIRED_BEFORE_NEXT_LONG_REAL_RUN ``` Cette autorité rouvre uniquement les **contrats opérationnels de ressources** quand ils empêchent cette politique. Elle ne rouvre aucune science FROZEN. ### Fondations PASS / FROZEN - Gates A–G Sparse SfM, dont F0, orchestration Task/Project DB et politique Governor : [Sparse SfM](../architecture/sparse_sfm.md) et [frontière ressource](../architecture/resource_boundary.md). - Track Model / Track Builder v1 : [Track Model](../architecture/tracks.md) et [Track Builder](../architecture/track_builder.md). - Phase H v1 d'enrichissement incrémental multi-snapshot : [Project DB](../architecture/project_database.md). - MVS-M1, frontière OpenMVS v2.4.0, identité dense et export COLMAP/PLY borné : [pipeline de reconstruction](../architecture/reconstruction_pipeline.md). - Task Runtime, checkpoints atomiques, Queue et Resource Governor : [Task](../architecture/task_system.md), [Queue](../architecture/task_queue.md) et [Governor](../architecture/resource_governor.md). - Project DB v22 gelé, overlay optique additif v23 gelé et couche opérationnelle additive v24 actuellement en validation pour `raw.develop.batch/1`, ainsi que S1–S3 Capture / Acquisition Ingestion : provenance Capture/Asset, import capture-safe, publication dérivée, développement RAW, siblings multi-source, évidence S3-D, orchestration S3-E et campagne bornée : [Project DB et ingestion](../architecture/project_database.md). ### S3 Capture / Acquisition Ingestion — PASS / FROZEN ```text S3-A Derived Image Publication PASS / FROZEN S3-B1 Deterministic RAW Development PASS / FROZEN S3-C Multi-Source Capture Association PASS / FROZEN S3-D Acquisition Pairing Evidence v1 PASS / FROZEN S3-E Multi-Source Ingestion v1 PASS / FROZEN Bounded Campaign Ingestion PASS / FROZEN Project DB v19 ``` ```text entrées d'acquisition explicites → publication SOURCE immuable → provenance Capture/Asset → métadonnées RAW/JPEG et évidence d'acquisition → propositions de campagne déterministes → regroupement fort ou explicitement confirmé → un Capture par observation physique résolue et siblings SOURCE → développement RAW déterministe si demandé → image_id scientifique immuable → pipeline aval existant ``` Les identités restent distinctes : `Capture != fichier`, `Capture != asset`, `Capture != image_id`, `Capture != SHA-256` et `Capture != basename`. ### Validation réelle Sony A6000 Campagne `Photogrammetrie/2026-08-26_Baie_Moteur_A6000` : - 953 ARW et 953 JPEG, soit 1906 sources ; - métadonnées : ARW 953/953 OK, JPEG 953/953 OK ; - JPEG Sony reconnus comme conteneurs MPF valides : APP2 `MPF\0`, images JPEG secondaires validées, remplissage inter-image/final nul, maximum privé huit ; - `STRONG_GROUPS=0`, `CANDIDATE_PAIRS=953`, ambiguïtés 0, contradictions 0 ; - plan identique après inversion de l'ordre des racines. Le stem commun ne prouve jamais une acquisition. Les 953 propositions doivent être confirmées et deviennent `CALLER_EXPLICIT`, jamais `STRONG`. ### Limite de reprise DB v19 (historique) S3-E reprend une matérialisation connue par `resume_capture_id`. Une campagne peut reconstruire son plan et conserver côté appelant le `capture_id` de chaque groupe. Si le processus meurt après création du Capture mais avant rétention durable de cet ID, DB v19 ne peut le redécouvrir sans inventer une identité interdite. Il n'existe donc pas de garantie whole-campaign exactly-once. Une future identité durable de requête/campagne pourra fermer cette fenêtre ; elle ne sera jamais déduite d'un chemin, SHA, basename, timestamp, métadonnée ou `image_id`. ## Exécution durable de campagne d'acquisition — PASS / FROZEN Project DB v20 apporte une migration additive v19→v20. Une tâche de campagne enregistre atomiquement son snapshot générique, sa référence de checkpoint et sa requête typée immuable. Le Task ID est l'identité opérationnelle de la campagne ; la requête ne déduit aucune identité depuis les sources. Son codec v1 est borné, à champs de largeur fixe et little-endian ; il conserve les sources, les confirmations explicites et les options d'ingestion. La requête persiste les confirmations comme `CALLER_EXPLICIT`, jamais comme inférence `STRONG`. Le plan conserve des IDs de groupe un-based et Project DB persiste la correspondance `(task_id, group_id) → capture_id`, ainsi que le curseur. Chaque séquence admet et matérialise exactement un groupe via S3-E. Après le retour de S3-E, une transaction conserve le Capture et avance le curseur avant la progression générique et le checkpoint. Pause et annulation sont coopératives aux frontières de groupe ; entre deux groupes, `sequence_break` rend la réservation et impose une nouvelle admission. À la réouverture, la registry existante reconstruit la tâche à partir de son Task ID et de sa requête, puis la Queue et le Governor existants la réadmettent. Aucun runtime, queue, governor ou mécanisme de persistance parallèle n'est introduit. La fenêtre résiduelle acceptée demeure l'arrêt après le retour de S3-E et avant la transaction de rétention : elle ne déclenche aucune inférence de Capture et ne fournit pas de garantie exactly-once pour ce groupe. ## ENGINE BAY MULTI-CAMPAIGN INTEGRATION — PASS / FROZEN L'intégration réelle a validé les deux campagnes dans un même projet temporaire Project DB v20 : A6000 (953 ARW + 953 JPEG, 953 confirmations `CALLER_EXPLICIT`, plan déterministe) et Samsung S21 FE SM-G990B (3544 JPEG, groupes singleton déterministes). Un échantillon borné a exercé deux Captures A6000 (JPEG SOURCE puis RAW dérivé) et trois Captures S21, avec ScanSets isolés, Queue/Governor, persistance tâche/groupe→Capture et reprise sans duplication. La capacité bornée des propositions de revue conserve un préfixe déterministe ; elle ne limite jamais l'évaluation complète ni le groupement scientifique. ### État de calibration des campagnes réelles L'infrastructure Project DB v22, exécution sélectionnée, `raw.develop` et Calibration Bootstrap v1 est **PASS / FROZEN** : la suite normale 53/53, les contrôles syntaxiques C17, `git diff --check`, la validation ciblée ASan/UBSan et l'audit final ont passé. La suite ASan/UBSan complète reste qualifiée par le comportement LSan du pilote tiers RADV ; elle n'est pas déclarée PASS complet du dépôt. Ce gel concerne l'infrastructure de persistance et d'import borné, pas la calibration des campagnes réelles ni leur Sparse SfM. Les campagnes réelles S21 et A6000 Engine Bay actuellement évaluées sont `CALIBRATION_UNAVAILABLE` par non-identifiabilité scientifique des données disponibles pour le contrat Sparse SfM à calibration connue. Ce statut ne signifie ni échec logiciel, ni défaut des sources, ni rejet de qualité. Sans pseudo-calibration, interpolation de métadonnées ou import inféré, le Sparse SfM réel est `BLOCKED_BY_KNOWN_CALIBRATION_DATA`; l'intégration synthétique à calibration connue a passé. Une acquisition physique dédiée de calibration est une étape future, décrite dans [Calibration Bootstrap v1](../architecture/calibration_bootstrap.md), et non une fonctionnalité déjà réalisée. `CALIBRATION_SCIENCE_V1=PASS/FROZEN` fixe désormais le protocole physique, les seuils, le regroupement optique, la preuve de coordonnées et le bundle de provenance requis pour les **futures** campagnes connues-calibrées. Il ne réhabilite aucune campagne historique : S21 Engine Bay reste définitivement non rétro-calibrable. Voir [Calibration Science v1](../architecture/calibration_science_v1.md). `CALIBRATION_TOOLING_V1=PASS/FROZEN` ajoute le pont opérationnel borné entre un bundle d'évidence Science v1 déjà acquis et l'importeur immuable `L3DCALB1` v1. Il valide les HARD REJECTS, produit l'artefact déterministe et s'arrête à la transition `CALIBRATION → READY`; il ne résout aucune calibration, ne lance pas Sparse SfM et ne rétro-calibre pas S21. `CALIBRATION_SOLVER_PREFLIGHT_V1=PASS` retient un exécutable externe épinglé sur OpenCV 5.0.x, dont le seul rôle futur est de produire le bundle d'évidence consommé par Calibration Tooling. Il ne devient pas une dépendance runtime et ne lance aucun stage de reconstruction. Voir [Calibration Solver Preflight v1](../architecture/calibration_solver_preflight_v1.md). ## PHOTO QUALITY TRIAGE / ACQUISITION SELECTION — PASS / FROZEN L'étape qualité canonique implémentée se place après la découverte bornée, les métadonnées et l'association minimale des sources, mais avant la matérialisation normale d'une campagne et avant toute représentation scientifique, feature, matching, SfM ou MVS : ```text série source explicite → découverte bornée / métadonnées → candidats d'acquisition et confirmations existantes → Photo Quality Triage → recommandation GOOD / SUSPECT / REJECT par acquisition physique → sélection ou override humain explicite → création/exécution durable de campagne pour les groupes retenus → représentations scientifiques → features → candidats → matching → vérification → tracks → Sparse SfM ``` Le triage consomme les groupes d'acquisition existants et ne redéfinit jamais Capture, Asset, `image_id`, SHA-256, chemin ou basename. Une paire A6000 RAW+JPEG confirmée est donc une seule unité de triage ; le JPEG caméra valide est le proxy rapide préféré et l'analyse ne développe pas les RAW à grande échelle. Un JPEG S21 singleton est la représentation d'analyse naturelle. Le résultat est non destructif et explicable : `GOOD` est sélectionné par défaut, `SUSPECT` attend une acceptation explicite et `REJECT` est exclu par défaut mais peut être forcé par l'humain. Ces états sont une recommandation et une sélection opérationnelle, jamais une identité ni une suppression de source. L'implémentation reste déterministe, générique aux appareils, bornée en mémoire et I/O, et exécutée par les Task, Queue et Resource Governor existants. Le décodage JPEG applique une limite opérationnelle de 8192 pixels sur le plus grand axe, une réduction à 1024 pixels et une réservation incluant le contexte retenu plus 20 MiB de buffers d'analyse par groupe ; ces bornes ne sont pas des limites scientifiques de campagne ou de dataset. Elle doit conserver une voie honnête pour les RAW sans proxy plutôt que de présumer que chaque RAW a un JPEG sibling. La revue interactive détaillée des recommandations Photo Quality, la guidance de capture et les keyframes vidéo restent des intégrations ultérieures qui réutiliseront ce même chemin de qualité, sans second pipeline. Cette limite ne concerne pas l'observatoire runtime TUI courant. ## SELECTED SCIENTIFIC EXECUTION ON ENGINE BAY INPUTS — PASS / FROZEN L'intégration réelle opt-in porte uniquement sur les acquisitions sélectionnées des campagnes Engine Bay et s'arrête à la frontière pré-SfM validable. Pour chaque campagne, l'exécutable d'évidence a créé un projet temporaire Project DB v22 distinct : Visual Index v1 est borné à 4096 images, tandis que l'ensemble A6000+S21 en compte 4497. Cette séparation est opérationnelle ; elle ne redéfinit ni Capture, ni Asset, ni `image_id`, ni l'identité scientifique des acquisitions. Le runner compose les API durables existantes, dans cet ordre : ```text qualité → campagne d'acquisition → snapshot immuable de la sélection → représentation (A6000 `raw.develop`, S21 JPEG SOURCE) → features ORB → Visual Index → candidats du même ScanSet → matching ORB → GV gelée → arrêt durable avant Tracks ``` Il rouvre ensuite le Project DB afin de rapporter l'évidence durable produite. Il n'introduit ni coordinateur réutilisable, ni DAG, ni sidecar, ni scheduler distinct : Task, Queue et Resource Governor existants conservent leurs responsabilités. L'overlay optique Project DB v23, ajouté ultérieurement, ne réinterprète pas cette preuve v22 ; les copies des deux projets migrent avec les comptes scientifiques inchangés et les nouvelles tables optiques vides. Pour A6000, le JPEG caméra pairé reste un SOURCE valide et le proxy rapide de Photo Quality, mais la représentation géométrique FROZEN de cette exécution sélectionnée reste le PNG déterministe dérivé du RAW (`L3DRAWD1`). Passer cette preuve au JPEG caméra nécessiterait une tranche scientifique/calibration séparée prouvant l'équivalence exacte ; ce changement n'est pas une optimisation opérationnelle ordinaire. Le Sparse SfM réel final reste `BLOCKED_BY_KNOWN_CALIBRATION_DATA` pour ces campagnes ; aucune pseudo-calibration, interpolation de métadonnées ou inférence d'identité ne le contourne. Dense, mesh et publication aval ne font pas partie de ce jalon pré-SfM. Ce milestone est une intégration réelle, pas une nouvelle série de micro-gates S3. Son statut acquis ne rend pas disponibles les données de calibration physique manquantes et n'autorise pas à devancer les dépendances scientifiques. ## INTERNAL PARALLELISM + COMPUTE RESOURCES v1 — PASS / FROZEN La fondation scientifique pré-SfM courante comprend le parallélisme interne borné des étapes Candidate, Matcher et Visual Index, l'audit du threading des features, et l'admission/libération des ressources par le Resource Governor existant. Elle ne crée ni parallélisme inter-Tasks, ni pool global, ni second Scheduler, ni second Governor, ni persistance parallèle. Le contrat gelé est celui du [parallélisme interne borné](../architecture/internal_parallelism.md). L'audit GPU vérifie les coutures réellement disponibles, les coûts UMA, les réservations et la préservation des sorties canoniques. Il ne présume pas qu'un GPU soit approprié ni qu'une sortie GPU partage automatiquement l'identité scientifique CPU. Le gel ne revendique pas de comparaison de débit durable CPU-versus-GPU sur corpus : la pression hôte a contaminé cette mesure. Cette limite de preuve v1 n'annule pas l'évidence directe fournie à la tranche suivante. Pour le hot path ORB Matcher, Vulkan est désormais validé, déterministe et mesurément supérieur ; il devient donc le workload primaire de la politique v2 GPU-first, sous admission GPU/UMA, avec fallback CPU. Candidate, Feature et Visual Index restent explicitement rejetés pour le GPU, et SIFT/RootSIFT Matcher restent BFMatcher L2 CPU. **COMPUTE_GOVERNOR_V2 — PASS / FROZEN.** **ORB_VULKAN_ASYNC_EXECUTION — PASS / FROZEN.** Cette tranche autorisée fait évoluer l'unique Governor, sans créer de scheduler, Queue, daemon ou persistance parallèle : télémétrie bornée, admission adaptative par séquence et `AUTO` GPU-first pour les backends exacts et mesurément supérieurs. La couture ORB Matcher normale est gelée avec CPU complet en fallback ; les choix CPU/Vulkan explicites restent des overrides de debug, benchmark et reproductibilité. Les dimensions retenues et toutes les validations v2 sont closes. Le pool CPU12 est validé comme preuve de cet hôte, pas comme plafond produit. Le Governor dérive désormais le pool lourd depuis le masque permis et les groupes package/core/SMT. Sur l'hôte unrestricted courant, il obtient `0-5,8-13` et réserve `6,7,14,15`; un caller déjà précontraint ne subit pas une seconde réserve. Le worker Queue seul applique/vérifie son propre masque ; aucun TID auxiliaire énuméré n'est muté. Creator/main/TUI reste unrestricted. Les CPU déjà exclus de l'affinité du processus comptent dans la réserve hôte ; le fallback count-only ne fabrique aucun masque. La cible RAM conserve une réserve dure de 3 GiB de `MemAvailable`; la zone 3–4 GiB est une prudence qui ne soustrait pas 4 GiB à toute capacité. Les petits hôtes dégradent le budget en conservant au moins une unité de calcul. Les PSI CPU/mémoire/I/O et les deltas swap-in/swap-out sont des signaux actifs ; l'occupation totale du swap reste historique. Admission CPU et lot sont indépendantes. Sur la 780M, Hardware Profile classe conservativement comme UMA le petit aperture VRAM amdgpu de 512 Mio accompagné d'environ 7,99 Go de GTT système ; la capacité rapportée reste observable mais ne devient pas un budget séparé. Les coûts GPU sont débités exactement une fois de la RAM hôte. La nouvelle autorité humaine `SERIALISM_REQUIRES_PROOF` **supersède toute interprétation** de l'inventaire de maintenance qui ferait d'un ancien `CPU1`/`batch1` un plafond permanent. Les preuves scientifiques et résultats de la maintenance restent FROZEN ; seules les enveloppes opérationnelles peuvent être rouvertes lorsqu'un travail indépendant est inutilement sérialisé. Une Task fixe demeure fixe seulement si sa sérialité ou son genou de scaling est prouvé. Cette règle doit être appliquée à toutes les Tasks de production avant d'engager de nouvelles preuves réelles longues. L'audit Phase 1 couvre les kinds de production de l'époque et sépare leurs dimensions fixes des dimensions réellement adaptables. Il confirme que tous passent par l'unique Governor, même les formes fixes, et que le contrat reste immutable pendant une séquence. Cette tranche ferme l'enveloppe privée, la sélection AUTO, les diagnostics bornés, l'enforcement OpenCV borné au compute-pool, la politique d'affinité privée et la réconciliation du contexte retenu des campagnes nouvelles ou restaurées. La création/reprise AUTO ne touche plus Vulkan sur le main ; le premier begin appartient au worker contraint. Inflight ORB normal est fixé à 1, helpers reste 0 ; depth 2 reste une capacité privée de sûreté/benchmark. Ces choix ne créent aucune limite de dataset, identité scientifique ou version Project DB. La signature durable des nouvelles Tasks ORB normales est la classe `MIXED`, sémantiquement réelle pour une politique susceptible d'exécuter CPU ou Vulkan. Elle reconstruit AUTO ; toutes les signatures CPU anciennes/courantes restent CPU fixes et Vulkan reste fixe, sans migration DB/codec. La couture asynchrone est privée, request-bound et nettoie son slot sur toute sortie. Une preuve événementielle bornée établit la soumission du successeur avant la publication du prédécesseur pour deux paires 769×769. La rampe ne croît plus sur la seule santé : l'adaptation générique exige deux observations par fenêtre, tandis que le lot ORB Vulkan en exige huit, avec retour au palier accepté sans gain et reset immédiat sous pression. Ces éléments sont **PASS / FROZEN** dans les limites validées. Les diagnostics de séquence distinguent backend sélectionné et backend réel ; les participants CPU Matcher restent `cpu_threads` et `helpers=0`. Une paire Vulkan inéligible ou en panne est recalculée entièrement sur CPU sans preuve partielle. Les extractions ORB/SIFT/RootSIFT testées à 1/2/4/8/12 consomment leur contrat OpenCV immutable avec sorties égales. Le rolling distingue un handle soumis d'une inéligibilité locale et n'appelle jamais `finish` sans requête. La panne backend invalide immédiatement l'admission partagée sur toute sortie précoce ; seules les reprises AUTO peuvent établir cette disponibilité, indépendamment de l'ordre des reprises fixes ou historiques. Le statut est **PASS / FROZEN**. La boucle privée mesure l'utilisation `/proc/stat` du compute-pool, `MemAvailable`, PSI mémoire/I/O `some/full`, deltas swap actifs, RSS/HWM observé et GPU busy DRM, avec `unknown` sur absence ou parse non strict. Le backend Vulkan fournit des compteurs cumulés bornés de submit/complétion/fence/readback/ GPU/starvation/panne/discard ; Matcher agrège en plus CPU et publication par séquence. Le diagnostic est tirable par numéro de série, sans log ncurses ni histoire persistée. Les CPU réductibles progressent vers la capacité exacte du kind/compute-pool selon les observations de scaling ; sous pression, l'admission se réduit puis doit pouvoir remonter. Candidate mesure chaque séquence. Un fallback réel annule l'essai Vulkan au lieu d'empoisonner sa baseline. Cette implémentation est **PASS / FROZEN** sans ajouter de helper GPU. L'évidence retenue avant cette implémentation compare le contrôle synchrone à 49,989 paires/s et rolling depth 1 à 55,124 paires/s (+10,27 %), avec le même digest `7a9dbc38a23a600379167d55e24836b7acbb22eea25573e7440bdc9e4602b3b3`. La starvation depth 1 (53,847 s sur 74,613 s, GPU busy max 25 %) motive deux slots bornés mais ne constitue pas une mesure depth 2. Le backend partage device/pipeline/layout/cache et duplique seulement 640 Kio de payload, command/fence/descriptors/query par slot. Le payload mappé suit exactement la capacité de séquence admise : zéro avant initialisation, 640 Kio à depth 1 et 1,25 Mio uniquement pendant un contrôle privé depth 2, avec retour à 640 Kio avant la prochaine admission depth 1. L'enveloppe normale n'essaie plus inflight 2. Les générations de requête ne bouclent pas ; un slot épuisé est retiré définitivement. Le harness réel a exécuté le corpus 4113 paires pour le contrôle synchrone, rolling depth 1 et l'A/B forcé depth 1/depth 2. L'ABBA forcé donne 54,661652238 et 55,797311953 paires/s (+2,077617 %, sous le deadband 5 %). Chaque run porte 4113 paires durables ; le débit combiné est `(2 * 4113 * 1e9) / somme(wall_ns)`, pas la moyenne des débits par run. Les walls bruts 75326831673/75162582080 et 73662096698/73764360098 ns donnent les moyennes 75,244706877/73,713228398 s. Fence vaut 6,0684/3,6776 s, starvation 54,4534/50,1465 s, publication 29,2582/30,0548 s, submit CPU 0,2655/0,3818 s, readback 0,0460/0,0873 s et GPU busy max 23/24 %. Les quatre exécutions conservent le digest `7a9dbc38a23a600379167d55e24836b7acbb22eea25573e7440bdc9e4602b3b3`, quatre séquences de fallback local par exécution et zéro panne/discard. Depth 2 est donc **REJECTED_WITH_MEASURED_REASON** pour la politique normale : `DEPTH_MAX_VALIDATED_SAFETY=2`, `DEPTH_MAX_USEFUL=1`. Les huit runs item-valides `forced-batch{2,4,8,12}-items{,-b}.stdout.jsonl` publient chacun 4113 paires, six items locaux, zéro panne/autre et le même digest. Leurs débits combinés sont 54,180767704, 66,094373197, 74,784998723 et 76,755814095 paires/s. Batch 4 puis 8 gagnent +21,988624373 % et +13,148812987 % ; batch 12 ne gagne que +2,635308425 %, sous le deadband 5 %. AUTO normal suit donc `BATCH_MAX_USEFUL=8`; batch 12 reste une capacité privée sûre `REJECTED_WITH_MEASURED_REASON`. Le contrôle de production sans override `short-auto-batch8-governor-v2.stdout.jsonl` atteint réellement `1 → 2 → 4 → 8`, puis publie 4113/4113 résultats à 76,072 paires/s avec le même digest, six fallbacks locaux, zéro panne/discard, inflight 1 et helpers 0. La preuve de fermeture S21 `final-s21-auto.stdout.jsonl` exécute le chemin production normal sur 172 741 Candidate Pairs : 172 741 Match Results, zéro doublon, curseur complet, digest `e5128a2e599ff593c4f79850e067254b1f249d19e8480a44973306b1af250f70` et 73,649 résultats durables/s. AUTO choisit Vulkan sur toutes les admissions, termine batch 8/inflight 1/helpers 0 et ne compte aucune panne/discard/pending. Une admission YELLOW réduit batch 8 à 1, puis les séquences GREEN rétablissent 1 → 2 → 4 → 8 ; le gate possède donc une preuve réelle de recovery. La poursuite S21 ferme le Geometric Verifier v3 sans rejouer le Matcher. La Task 2832 consomme les 172 741 Match Results et publie 172 275 GVR v3, dont 24 065 acceptés et 148 210 rejetés, avec zéro doublon et curseur complet. La seconde reprise crée zéro ligne ; une Task interrompue sur une copie dédiée reprend le même ID et converge vers les mêmes lignes exactes. Feature, Candidate et Matcher ne sont pas rejoués. `REAL_S21_GV_V3=PASS/FROZEN`. Les gates de fermeture acquises incluent : ```text GOVERNOR_CONTROLS_ALL_TASKS=PASS HOST_CPU_RESERVE=PASS HOST_RAM_RESERVE=PASS REAL_TIME_TELEMETRY=PASS SLOW_START=PASS HYSTERESIS=PASS PRESSURE_THROTTLE=PASS PRESSURE_RECOVERY=PASS GPU_FIRST_AUTO=PASS ORB_VULKAN_TRUE_ASYNC=PASS TRUE_GPU_CPU_OVERLAP=PASS VULKAN_RESOURCE_BOUNDS=PASS UMA_ACCOUNTING=PASS SCIENTIFIC_EQUIVALENCE=PASS RESTART_IDEMPOTENCE=PASS FINAL_FULL_S21_AUTO_RUN=PASS FULL_NORMAL_SUITE=PASS C17=PASS ASAN_UBSAN=PASS GIT_DIFF_CHECK=PASS FINAL_XHIGH_REVIEW=PASS DOC_CONSISTENCY=PASS MATCHER_GPU=EXISTING_BACKEND_VALIDATED_AND_PREFERRED COMPUTE_GOVERNOR_V2=PASS/FROZEN ORB_VULKAN_ASYNC_EXECUTION=PASS/FROZEN REAL_S21_GV_V3=PASS/FROZEN FEATURE_REPLAY=0 CANDIDATE_REPLAY=0 MATCHER_REPLAY=0 SPARSE_SFM_EXECUTED=0 ``` L'expérience normale est donc : l'utilisateur lance une Task ; l'unique Governor choisit et explique le contrat borné de sa prochaine séquence. Aucun réglage CPU/GPU/lot/inflight/helper n'est requis en production ordinaire. Avec la nouvelle autorité humaine, ce choix doit désormais rechercher explicitement le **maximum sûr et utile**, et non conserver une sous-utilisation historique. ## GLOBAL MAINTENANCE AUDIT — PASS / FROZEN Le checkpoint canonique de revue est le tag `global-maintenance-2026-09-01`, au commit `b84f860d868c66d9ee84b85ceb1bc6480b95aca5`. Les revues futures sont strictement delta-based depuis ce point : `git diff global-maintenance-2026-09-01...HEAD`, puis examen des fichiers modifiés, des contrats, tests et documents directement affectés, et des frontières de dépendances traversées. Les systèmes PASS/FROZEN inchangés héritent de la preuve du [registre de maintenance](../architecture/global_maintenance_audit.md) et ne sont rouverts que sur preuve concrète ; ne pas répéter un audit global A-à-Z. Les résultats acquis restent notamment : - Project DB v23 ajoute neuf relations optiques sans backfill ni inférence ; - le Governor réserve l'hôte sans plafond CPU global 12, avec réserve RAM dure 3 GiB, PSI/swap actif et UMA comptée une fois ; - Candidate, Visual Index, Feature, Matcher et GV possèdent leurs capacités et décisions GPU mesurées ; - le contrôleur SSD UDisks2 optionnel est une frontière physique revue, avec identité Drive+labels+UUID, leases et drain sûr ; - la TUI est un observatoire/centre de contrôle validé opérationnellement ; - la frontière de session détruit/joint la Queue avant Project DB, puis recrée une seule Queue. Le nouvel impératif `SERIALISM_REQUIRES_PROOF` ne nie aucune de ces preuves. Il supersède uniquement l'idée qu'un ancien profil opérationnel conservateur serait un plafond permanent lorsque de nouvelles preuves réelles montrent du travail indépendant et des ressources sûres inutilisées. Les validations finales exécutables de la maintenance sont acquises : build Clang portable 931/931 + suite 64/64, build Clang Vulkan 939/939 + suite 65/65 sur Radeon réelle, ASan/UBSan 64/64 avec la limitation LSan OpenCL externe qualifiée, LSan loader-free 20/20, TSan, headers publics 76/76 et contrôles ABI/diff/`scan3d`. La gate de maintenance reste fermée ; les nouvelles corrections de ressources sont revues en delta et ne réouvrent pas l'audit A→Z. ## REAL S21 TRACKS — PASS / FROZEN `REAL_S21_TRACKS=PASS/FROZEN`. La preuve part du projet GV v3 immuable `/home/fy59/Documents/Lardon/.real-pre-sfm-2026-08-31/s21-gv-v3`, dont le SHA-256 de Project DB est, avant et après les exécutions, `56aa5ec37624b322e9f77a90b138cc7390ef817a9cec3bef7e4c87609fd2eeed`. Les reflinks de preuve conservent exactement 2 826 Feature Sets, 172 741 Candidate Pairs/Match Results, 172 275 parents GVR (24 065 `GEOMETRIC_VERIFIED`, 148 210 `GEOMETRIC_REJECTED`). Aucun Feature, Candidate Pair, Matcher ou GVR n'a été rejoué ni créé ; le source reste intègre. Sparse SfM et Dense restent à zéro. Le rejet initial de la Task `track_builder.run` 2835 à 0 % est conservé comme constat historique : son enveloppe alors utilisée valait 19 546 898 688 octets (18,204 Gio), au-delà des 12 750 811 136 octets (11,875 Gio) admis après réserve. Ce n'est pas le modèle opérationnel validé. Le modèle compact actuel, qui réserve les capacités vivantes du scope et le pic du Match File parent, est admis par le Governor ; aucun scratch ni lease scratch n'a été utilisé. La Task fraîche primaire 2837 termine `COMPLETE` à 100 % et publie le seul Track Set 1 : 912 447 Tracks, 2 495 768 observations, longueurs min/max/moyenne 2/42/2,7352470883240341, zéro doublon et zéro Track à images conflictuelles. Son digest canonique persistant est `c30eba192627bf73eaf21ff30d81038d8cc6bbf36a69226f88cdc8c37f7d74a1`. La reprise exacte suivante réutilise Track Set 1 (`task_track_id=0`) sans modifier ces Tracks. Le run complet propre de la Task 2837 dure 3 316 s (1788262322 → 1788265638). La preuve de récupération est distincte : la Task 2835 est créée pendante sur un reflink, interrompue par `SIGTERM` sans publication, puis reprise par le runner corrigé. Elle termine `COMPLETE` à 100 % et retrouve le même Track Set 1, les mêmes comptes et le même digest ; le scénario interrompu avait publié zéro Track Set. Cette preuve valide la reprise opérationnelle sans rouvrir le contrat scientifique Tracks gelé. ## PROJECT DB v24 / RAW BATCH A6000 — IMPLEMENTED / VALIDATION IN PROGRESS L'autorisation humaine additive v24 est limitée au parallélisme opérationnel du développement RAW. Project DB v24 conserve v22/v23 et ajoute uniquement la persistance typée `raw_development_batch_tasks` nécessaire au nouveau kind `raw.develop.batch/1`. Cette version ne change aucune identité scientifique, aucune calibration ni `L3DRAWD1`. Le pattern de production est : ```text une Task owner admise par le Governor → participants RAW indépendants et bornés → join de tous les participants → publication owner-only dans l'ordre des selected_item_index → avance durable du curseur selected_execution ``` L'atomicité par Capture est conservée ; la sérialisation entre Captures indépendantes ne l'est plus. La transition historique `raw.develop/1` → `raw.develop.batch/1` reste légitime et ne réécrit aucune ancienne Task. État durable A6000 au dernier arrêt sûr avant l'audit global d'utilisation des ressources : ```text Projet: /home/fy59/Documents/Lardon/.real-pre-sfm-2026-09-01/a6000-pre-sfm-v23-final Schema v24 Captures 953 GOOD 689 SUSPECT 206 REJECT 58 selected_execution 1 selected items 689 RAW_ASSET published representations 259 next_item_index 259 remaining RAW representations 430 Features 0 Visual Index 0 Candidate 0 Matcher 0 GV 0 Tracks 0 Sparse SfM 0 Dense/MVS 0 ``` Le digest d'inventaire source pré/post est `fa725d8a82b529521134dd600b5cf42ed58ad523108636741a1431441e17b029`. Les JPEG caméra et RAW sont tous deux des SOURCE assets explicites par Capture, mais cette exécution A6000 FROZEN utilise les PNG déterministes dérivés RAW pour la géométrie. Les JPEG restent les proxies de triage ; ils ne remplacent pas cette représentation scientifique sans nouvelle tranche d'équivalence scientifique/calibration. La v24 et la Task batch ont déjà passé build normal, matrice ciblée, contrôles C17, `git diff --check`, ASan/UBSan ciblé et TSan sur la couture concurrente. La preuve réelle complète, l'équivalence finale, l'audit d'utilisation de toutes les Tasks affectées et la fermeture documentaire restent à terminer avant de marquer cette tranche `PASS/FROZEN`. ## PROJECT DB v25 / FEATURE BATCH — IMPLEMENTED / VALIDATION IN PROGRESS L'overlay additif v25 ajoute uniquement la persistance typée de `features.extract.batch/1`. Il ancre un propriétaire durable à l'ordre immutable de l'exécution sélectionnée, au domaine ORB exact et à un curseur monotone. Les Tasks `features.extract/1` historiques restent inchangées et sont reprises avant le suffixe batch. La préparation inter-images est bornée par le Governor, OpenCV reste CPU1 dans chaque participant, et publication/cursor/checkpoint restent owner-only et ordonnés. Le build et les tests ciblés sont acquis ; le benchmark réel du palier utile et la preuve A6000 restent à exécuter avant toute revendication PASS/FROZEN. ## REAL A6000 PRE-SFM — PASS / FROZEN `REAL_A6000_PRE_SFM=PASS/FROZEN`. La continuation du 2 septembre 2026 utilise le projet durable `/home/fy59/Documents/Lardon/.real-pre-sfm-2026-09-01/a6000-pre-sfm-v23-final` directement à la frontière Match Result acquise. Les 689 Feature Sets, le Visual Index complet, les 38 420 Candidate Pairs et les 38 420 Match Results de la Task Matcher 170 `COMPLETE/100` sont conservés : `FEATURE_REPLAY=0`, `CANDIDATE_REPLAY=0` et `MATCHER_REPLAY=0`. Ni l'acquisition, ni RAW, ni les assets/identités amont ne sont réécrits. La Task GV v3 171 termine `COMPLETE/100`, consomme le curseur Match Result jusqu'à 38 420 et publie exactement 37 805 GVR applicables : 10 952 `GEOMETRIC_VERIFIED` et 26 853 `GEOMETRIC_REJECTED`. Son fingerprint reste `6944a471d611d8ffc59dac7cf15a5b79b97e2371d4c51785c477d68c1577f74c`; zéro mapping GVR dupliqué est observé. Les diagnostics Governor coalescés retiennent 2 714 admissions, le compute-pool de 12 CPU avec 4 CPU réservés, une fenêtre finale de 16, RSS/HWM maximal 41 877 504/42 319 872 octets, `MemAvailable` minimal 10 555 641 856 octets et des deltas swap-in/out nuls. La préparation GV reste dans la forme validée Governor-admise et bornée ; aucune nouvelle policy CPU/GPU n'est introduite par ce run. La Task Track Builder 172 termine `COMPLETE/100` et publie atomiquement le seul Track Set 1, de scope 10 952 GVR, avec 130 714 Tracks et 318 944 observations. L'audit SQL confirme zéro observation de Track dupliquée, zéro Track contenant deux observations de la même image et zéro observation orpheline. La seconde continuation crée seulement la Task GV 173, qui traverse le même curseur, publie zéro GVR et réutilise Track Set 1 sans créer de Task Track Builder ni modifier les 130 714 Tracks. `RESTART_IDEMPOTENCE`, `DETERMINISM`, `TRACK_CONFLICT_INVARIANTS` et `RESOURCE_POLICY_ENFORCED` sont donc PASS pour cette frontière réelle. Sparse SfM, reconstruction sparse, Dense/MVS et fusion inter-campagnes restent à zéro. Ce gel atteste uniquement le pré-SfM A6000 à travers GV puis Tracks ; il ne contourne pas le blocage de calibration réel et ne promeut aucune étape aval. ## RESOURCE UTILIZATION ENFORCEMENT — CURRENT NEXT Avant de reprendre les 430 RAW restants ou toute autre preuve réelle longue, la prochaine tranche opérationnelle doit appliquer la politique canonique à l'ensemble des Tasks de production, en revue delta uniquement. Objectifs : ```text RESOURCE_UTILIZATION_POLICY=IMPLEMENTED SERIALISM_REQUIRES_PROOF=ENFORCED ACCIDENTAL_CPU1_PATHS=0_OR_MEASURED_JUSTIFICATION VALIDATED_GPU_BACKENDS=PREFERRED_WHEN_ELIGIBLE BUILD_TEST_PARALLELISM=HOST_RESERVE_AWARE ``` Pour chaque Task, auditer uniquement les dimensions opérationnelles : minimum/useful/safe CPU et batch, indépendance des items, séparation préparation/publication, coûts RAM par participant, saturation I/O et backend GPU validé. Une valeur CPU1/batch1 peut rester seulement avec preuve concrète. Il ne faut pas inventer de second scheduler, pool global ou parallélisme inter-Tasks pour satisfaire cette politique : le parallélisme interne borné et l'unique Queue/Governor restent la voie normale. Les tests Codex doivent suivre la même règle : build et tests indépendants parallèles jusqu'à la réserve interactive ; serialisation uniquement pour fixtures partagées, déterminisme scientifique, mémoire/I/O/GPU exclusif, sanitizer ou pression mesurée. Les validations acquises et non affectées ne sont pas répétées. Les modèles/agents coûteux sont réservés aux vraies frontières scientifiques, concurrence/persistance délicate et revue finale nécessaire. ## NEAR TERM Ordre court terme désormais canonique : ```text GLOBAL MAINTENANCE AUDIT PASS / FROZEN → REAL S21 TRACKS PASS / FROZEN → RESOURCE UTILIZATION ENFORCEMENT CURRENT NEXT (SERIALISM_REQUIRES_PROOF, max safe/useful throughput, politique tests/builds Codex comprise) → reprise A6000 v24 au curseur 259 → 430 représentations RAW restantes → Features → Visual Index → Candidate → Matcher AUTO / ORB Vulkan si éligible → GV → Tracks → STOP avant Sparse SfM → acquisition physique dédiée de calibration → calibration connue validée → Sparse SfM réel par campagne → fusion / Phase H selon dépendances → Dense / MVS ``` ### Scratch SSD externe et swap optionnel Le contrôleur physique actuel découvre par UDisks2 une paire exacte de labels `LARDON_SWAP`/`LARDON_SCRATCH`, exige des UUID stables et la même identité Drive, et ignore les renommages de nœud `/dev`. Modèle, série et vitesse USB restent de la télémétrie optionnelle, jamais une identité produit. Les états bornés sont `ABSENT`, `DETECTED`, `ENABLING`, `ENABLED`, `IN_USE`, `DRAINING`, `SAFE_TO_UNPLUG` et `ERROR`. Les usages futurs possibles sont workspace/scratch et intermédiaires dense/mesh/texturing. Leur consommation devra être explicitement possédée par les Tasks et passer par les wrappers de lease du Resource Governor ; le contrôleur physique et le registre actuel n'inventent aucune éligibilité Task. Le swap de sécurité reste une fonction du drain physique explicite et jamais un budget de travail. - les leases scratch ont une ownership explicite ; `DRAINING` refuse les nouveaux leases et attend leur libération exacte ; - le swap n'est arrêté que si son usage est absorbable tout en conservant la réserve hôte de 3 GiB, sans PSI élevé ni swap-in/out actif ; - SSD/swap ne sont jamais de la RAM ni une extension du budget scientifique ; - latence et débit USB restent distincts de la mémoire ; - l'utilisation reste optionnelle ; le Governor demeure l'unique orchestrateur de ressources et seul owner des leases scratch de production ; - une action UDisks potentiellement appliquée mais non vérifiable verrouille le tuple physique original ; un remplacement n'obtient aucune autorité ; - aucun formatage, partitionnement, fsck, réparation, arrêt forcé ou suppression n'est permis. Le contrôleur, son registre Governor, le worker joinable unique et sa présentation/actions F10 sont **CURRENT / VALIDATED OPERATIONAL**. Ce statut ne crée aucun consommateur scratch par lui-même. ### Publication durable dense / mesh MVS-M1 reste la frontière scientifique gelée. Les prochaines étapes portent sur exécution, reprise, budgets mémoire/stockage et publication atomique : ```text dense → mesh → refinement → texturing → consolidation → export ``` Le scratch devient particulièrement pertinent à cette frontière. ### Workflow TUI-first courant La TUI expose actuellement état projet, Tasks et contrôles disponibles, progression durable/ETA, Governor/ressources, profils optiques et SSD F10. ncurses reste au thread principal ; les opérations SSD bornées utilisent un seul thread joinable sans devenir un scheduler. La découverte/édition optique ne devine aucune identité : objectif manuel sans EXIF, profils/configurations immuables, affectations campagne/Capture et sélection de calibration exacte restent explicites. Le viewer général, la capture guidance, la consommation dense du scratch et les workflows scientifiques aval restent futurs. ### Sources mixtes et multi-ScanSet Sony A6000, Samsung S21 et futures sources peuvent varier en device, objectif, résolution et format. Elles réutilisent le même modèle Capture/Asset/Image, sans fork par caméra. Plusieurs ScanSets et représentations sélectionnées alimentent l'enrichissement Phase H existant vers un modèle consolidé ; Phase H n'est pas redéfini ici. ## LATER ### Ingestion vidéo et keyframes — PLANNED Une vidéo sera une source d'acquisition portant sa propre provenance, pas un pipeline scientifique parallèle : ```text asset vidéo SOURCE → timeline et métadonnées déterministes → extraction bornée et déterministe de keyframes → filtres blur/netteté/redondance → diversité de mouvement et de point de vue → représentations frame sélectionnées / candidats Capture → pipeline scientifique Lardon3D existant ``` Le futur contrat devra lier chaque frame à l'asset vidéo source, définir une identité d'extraction reproductible et retenir le timestamp exact de chaque frame. Les sujets de conception incluent espacement temporel, netteté, rejet des frames redondantes, diversité de mouvement/point de vue, traitement borné, reprise et admission par le Resource Governor. L'analyse de couverture pourra ultérieurement contribuer à la sélection : ```text besoin de couverture actuel + trajectoire caméra / frames vidéo → retenir les frames apportant une information géométrique utile ``` Cette relation reste un sujet de recherche et d'ingénierie ; aucune politique de sélection n'est gelée. Il n'existera **aucun second pipeline SfM propre à la vidéo** : les keyframes validées rejoindront les mêmes Capture, provenance, images, features, matching, tracks, Sparse SfM et étapes aval que les photos. ### Capture Guidance / Live Coverage — PLANNED, LONG TERME Le but à long terme n'est pas seulement de reconstruire ce qui a été photographié, mais de guider activement l'opérateur vers les photographies qui manquent encore pour obtenir une reconstruction fiable. Cette capacité est postérieure à une reconstruction suffisamment mature ; elle ne fait pas partie de S3. ```text photographies existantes → reconstruction Lardon3D → analyse de qualité de couverture → régions faibles ou manquantes → localisation de la caméra courante → projection dans la Live View → photographies supplémentaires par l'opérateur → ingestion / mise à jour de reconstruction → mise à jour de couverture ↺ ``` #### Dépendances et niveaux de maturité L'ordre conceptuel est : ```text Sparse SfM → calibration et poses caméra → géométrie dense / mesh lorsque nécessaire → métriques de couverture → viewer et localisation live → Capture Guidance / Live Coverage ``` Une première analyse peut s'appuyer sur la géométrie sparse et les tracks ; un mesh dense n'est donc pas une condition universelle. Les niveaux suivants sont des paliers de roadmap, **pas de nouveaux Gates** : 1. **Offline Coverage Analysis** — calculer les régions faibles ou manquantes depuis une reconstruction existante. 2. **Coverage Viewer** — afficher géométrie, caméras, qualité de couverture et zones faibles. 3. **Suggested Supplementary Viewpoints** — associer une région faible à une direction ou un cône de points de vue suggéré. 4. **Live Camera Localization** — estimer la pose de la caméra courante par rapport à la reconstruction. 5. **Live Coverage Overlay** — reprojeter la couverture dans le flux vidéo. 6. **Closed Acquisition Loop** — guider, capturer, transférer, ingérer, reconstruire, réévaluer puis guider à nouveau. #### Coverage Analysis — PLANNED L'analyse estimera à quel point une région de surface ou de géométrie reconstruite est soutenue par des observations photographiques. Ses entrées potentielles comprennent : - nombre de Captures observant la région, angle et diversité angulaire ; - parallaxe disponible et diversité des points de vue ; - résolution effective projetée sur la surface ; - netteté, exposition et qualité d'image ; - support features/tracks et qualité de reprojection/triangulation ; - confiance de reconstruction, visibilité et occlusions ; - provenance et historique des ScanSets. Une expression telle que la suivante n'est qu'une intuition **NON CONTRACTUELLE** : ```text coverage_score = f( observation_count, angle_quality, parallax_quality, effective_resolution, sharpness, viewpoint_diversity, reconstruction_confidence ) ``` Les métriques exactes, poids, seuils et normalisations nécessitent une validation expérimentale ultérieure. Aucun score scientifique n'est défini ou gelé par cette roadmap. #### Coverage Viewer — PLANNED Le Coverage Viewer ne sera pas un simple viewer de mesh : il servira à examiner la qualité d'acquisition et de reconstruction. Les overlays futurs pourront montrer positions, directions et frustums des caméras, surfaces bien ou mal couvertes, zones jamais vues, trous de reconstruction, faible nombre d'observations, diversité angulaire ou parallaxe insuffisante, support features/tracks faible, reconstruction peu fiable et contribution par ScanSet. Une heatmap pourrait par exemple utiliser rouge pour une photographie supplémentaire requise, orange pour un angle médiocre, violet pour une parallaxe insuffisante, jaune pour un problème de qualité d'image et l'affichage normal pour une couverture satisfaisante. Ces couleurs, catégories et significations sont **des exemples seulement** : elles ne sont ni choisies ni gelées. Lardon3D reste TUI-first. La TUI conserve le contrôle du projet, du workflow et du runtime. Une frontière visuelle/acquisition séparée pourra posséder l'affichage vidéo, le rendu points/mesh, les frustums, overlays et indications live. Son architecture finale n'est pas définie ici ; elle devra préserver l'isolation du viewer, consommateur de snapshots validés sans accès aux buffers workers mutables. #### Suggested Supplementary Viewpoints — PLANNED Le résultat recherché dépasse la coloration d'une surface défaillante : ```text région de surface faible + direction caméra / cône de points de vue suggéré ``` Il pourra exprimer « cette région demande des photographies supplémentaires », « photographier depuis une direction plus oblique », « le nombre d'images est suffisant mais la diversité des points de vue ne l'est pas », « cette cavité est vue par trop peu de Captures » ou « la géométrie d'acquisition fournit une parallaxe insuffisante ». La recommandation devra dériver d'évidence géométrique et de reconstruction, jamais du nombre de fichiers, de basenames similaires ou d'heuristiques arbitraires déconnectées de la géométrie. L'algorithme d'optimisation du point de vue n'est pas encore défini. #### Live Camera Localization — PLANNED Live Coverage dépendra de la localisation d'une vue nouvelle/live par rapport à une reconstruction existante. Les prérequis probables incluent calibration caméra, reconstruction sparse et points 3D existants, extraction de features sur la frame live, correspondances 2D↔3D, estimation de pose calibrée, confiance de pose et perte/réacquisition gracieuse du tracking. Cette capacité pourra réutiliser la géométrie Sparse SfM, mais elle n'est ni conçue ni implémentée à ce jour. #### Live Coverage et boucle d'acquisition — PLANNED La couche temps réel est distincte de l'analyse offline. Le déroulé cible est : 1. construire une reconstruction initiale et calculer l'évidence de couverture ; 2. recevoir sur le PC la Live View via une capture HDMI ; 3. estimer la pose de la caméra courante dans la reconstruction ; 4. projeter les régions 3D faibles/manquantes dans la frame vidéo ; 5. indiquer les acquisitions supplémentaires nécessaires pendant que l'opérateur déplace la caméra ; 6. déclencher une photographie et transférer RAW/JPEG par le chemin d'acquisition ; 7. faire entrer les nouveaux assets/Captures dans la provenance Lardon3D existante ; 8. mettre à jour reconstruction et couverture, puis retirer progressivement de l'overlay les régions corrigées. L'expérience visée est conceptuellement : « les observations photogrammétriques sont insuffisantes ici ; prendre une photographie supplémentaire approximativement depuis cette direction ». #### Frontière caméra HDMI / USB Le Sony A6000 fournit un exemple concret de matériel cible, sans définir une architecture scientifique propre à Sony : ```text Sony A6000 ── HDMI → capture device → Live View ───────────┐ └─ USB → contrôle / shutter / RAW+JPEG ───────┤ ↓ Lardon3D sur PC live camera pose + reconstruction/geometry/coverage ↓ reprojection et Live View overlay ``` Le calcul lourd, la reconstruction et le mesh restent sur le PC. La caméra est principalement le capteur d'image, la source Live View et un dispositif d'acquisition potentiellement contrôlable ; elle ne transporte ni n'exécute la reconstruction. HDMI vise une Live View à faible latence. USB pourra selon les capacités réelles de l'appareil fournir contrôle, déclenchement, métadonnées et transfert RAW/JPEG. Tous les appareils ne partagent pas le même protocole : les transports et contrôles spécifiques resteront à la frontière des adaptateurs d'acquisition, hors de l'identité Capture gelée et du cœur scientifique. Sony A6000, Samsung S21/mobile et futures caméras consommeront le modèle commun : ```text Capture physique ↔ assets SOURCE ↔ représentations scientifiques sélectionnées ``` Capture Guidance consommera le modèle projet/reconstruction commun, sans fork scientifique par device. #### Boucle multi-ScanSet / Phase H ```text ScanSet 1 → reconstruction → analyse de couverture → zones faibles/manquantes → acquisition supplémentaire → ScanSet 2 → ingestion / reconstruction → alignement et enrichissement Phase H → couverture mise à jour → répétition si nécessaire ``` Cette boucle est particulièrement importante quand un objet ne peut être capturé en une seule passe. Elle réutilise Phase H v1 sans le redéfinir. Pour une baie moteur, l'opérateur pourra à terme viser avec l'A6000 une bride, une cavité ou une face mal observée mise en évidence dans la Live View, se déplacer selon l'indication et ajouter une image avant ingestion et mise à jour de la couverture. La valeur pratique est forte lorsque l'accès disparaîtra, qu'un moteur ou composant doit être retiré, ou que le démontage modifiera la scène : découvrir les photographies manquantes après coup pourrait être coûteux ou impossible. Ce scénario motive la direction produit ; ce n'est pas un contrat scientifique. #### État futur et ordre de dépendance Cette roadmap ne prétend implémenter aujourd'hui ni capture HDMI, contrôle USB, pose live, projection de mesh, score ou heatmap de couverture, recommandation automatique, ingestion vidéo, sélection de keyframes, ni reconstruction live incrémentale. Ces capacités restent planifiées, ultérieures ou exploratoires. L'ordre demeure sans ambiguïté : ```text CURRENT NEXT GLOBAL MAINTENANCE AUDIT PASS / FROZEN → REAL S21 TRACKS PASS / FROZEN → RESOURCE UTILIZATION ENFORCEMENT CURRENT NEXT → A6000 PRE-SFM v24 resume from cursor 259 → RAW batch → Features → Visual Index → Candidate → Matcher AUTO / validated Vulkan when eligible → GV → Tracks → STOP before Sparse SfM → dedicated physical calibration acquisition → known calibration → real Sparse SfM → multi-campaign registration/fusion → dense / MVS → publication → LATER Coverage Analysis → Coverage Viewer → suggested viewpoints → live localization → HDMI/USB integration → Capture Guidance / Live Coverage ``` Vidéo/keyframes pourra progresser en parallèle lors d'une phase ultérieure, mais réutilisera toujours la même provenance Capture et le même pipeline scientifique. - **Maintenance projet** : vérification de provenance, assets orphelins, scrub/réconciliation et réclamation sûre du scratch. Aucun asset immuable partagé n'est supprimé silencieusement. - **Exports/publication live** : snapshots validés et consommation sans accès aux buffers workers mutables. ## DEFERRED / OPTIONAL - pools multiples CPU/GPU/IO, parallélisme inter-Tasks et multi-GPU ; - DAG général de dépendances et priorités complexes ; - infrastructure backend générique et distribution de calcul ; - ALIKED tant que provenance modèle, export ONNX et oracle upstream ne sont pas reproductibles. Le report du parallélisme **inter-Tasks** ne constitue jamais une permission de sérialiser accidentellement les unités indépendantes **à l'intérieur d'une Task active**. L'unique Queue/Governor et le fanout interne borné suffisent pour appliquer `SERIALISM_REQUIRES_PROOF` sans créer un second runtime. Ces idées ne doivent pas devancer l'intégration réelle multi-campagne ni créer un second runtime, Governor ou système de persistance. ## Principes de séquencement 1. intégrité scientifique et réserve interactive hôte sont inviolables ; à l'intérieur de ces limites, le maximum de débit sûr et utile est obligatoire ; 2. `SERIALISM_REQUIRES_PROOF` : l'atomicité d'un item ne sérialise pas les items indépendants et toute sous-utilisation durable doit avoir une raison mesurée ; 3. résultats atomiques et durables avant publication concurrente ; préparation parallèle bornée autorisée lorsque l'égalité exacte est préservée ; 4. lots bornés, reprise et mémoire honnêtement comptée avant taille de campagne ; 5. un Task Runtime/Queue et un Resource Governor, sans second scheduler ; 6. backend GPU validé et utile préféré automatiquement, sans GPU artificiel ; 7. scratch optionnel sans élargissement implicite des budgets RAM ; 8. builds/tests/preuves Codex parallèles jusqu'à la réserve hôte lorsqu'ils sont indépendants ; aucune sérialisation ou revalidation lourde par habitude ; 9. TUI de contrôle avant visualisation riche ; 10. documentation canonique alignée sur le code validé et revue delta-based depuis `global-maintenance-2026-09-01`.