lardon3d/docs/roadmap/roadmap.md

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.

Fondations PASS / FROZEN

• Gates A–G Sparse SfM, dont F0, orchestration Task/Project DB et politique Governor : Sparse SfM et frontière ressource.
• Track Model / Track Builder v1 : Track Model et Track Builder.
• Phase H v1 d'enrichissement incrémental multi-snapshot : Project DB.
• MVS-M1, frontière OpenMVS v2.4.0, identité dense et export COLMAP/PLY borné : pipeline de reconstruction.
• Task Runtime, checkpoints atomiques, Queue, Scheduler et Resource Governor : Task, Queue et Governor.
• Project DB v19 et 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.

S3 Capture / Acquisition Ingestion — PASS / FROZEN

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

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. La campagne complète n'a pas encore été matérialisée.

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, et non une fonctionnalité déjà réalisée.

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 :

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 TUI détaillée, 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.

NEXT REAL-DATA MILESTONE — SELECTED SCIENTIFIC EXECUTION ON ENGINE BAY INPUTS — IMPLEMENTATION / VALIDATION IN PROGRESS

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, un exécutable éphémère crée 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 :

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
→ 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, ni version Project DB v23 : Task, Queue, Scheduler et Resource Governor existants conservent leurs responsabilités.

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, et son statut ne revendique encore ni implémentation achevée, ni validation réussie, ni PASS/FROZEN.

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é.

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.

Un éventuel GPU COMPUTE v1 est postérieur et optionnel. Il ne peut être ouvert que si un audit futur et une preuve d'équivalence à la frontière concernée le justifient ; sinon le chemin CPU demeure le chemin retenu. Il ne modifie pas les contrats scientifiques, les résultats canoniques ni l'unique gouvernance des ressources.

L'ordre de travail autorisé à court terme est :

fondation scientifique pré-SfM courante
→ INTERNAL PARALLELISM + COMPUTE RESOURCES v1
  (Candidate, Matcher, Visual Index, audit feature threading,
   correction progression/Resource Governor, audit GPU)
→ GPU COMPUTE v1 optionnel, seulement si audit et équivalence le justifient
→ poursuite pré-SfM réelle complète de S21
→ acquisition dédiée de calibration
→ Sparse SfM réel
→ Dense / MVS

NEAR TERM

Scratch SSD externe et swap optionnel

Matériel envisagé : SSD externe d'environ 500 Go dans un boîtier USB-C 10 Gb/s. La capacité planifiée est : détecter un disque externe adapté, le présenter dans la configuration TUI/projet et demander si ce projet doit l'utiliser.

Usages possibles : workspace/scratch, intermédiaires dense/mesh/texturing et, sur activation explicite, swap de sécurité. Le contrat devra être possédé par l'exécution Task, le Resource Governor et la politique temporaire du projet ; il ne doit pas devenir un gestionnaire de stockage ad hoc.

• le scratch déplace les gros intermédiaires hors de la RAM et du disque système ;
• il peut permettre des jobs bornés plus grands ;
• 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 et Governor-controlled ;
• retrait, déconnexion, ownership, nettoyage et publication atomique exigent des sémantiques explicites ;
• aucun montage, formatage, swapon ou nettoyage destructif automatique n'est actuellement implémenté ou autorisé.

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 :

dense → mesh → refinement → texturing → consolidation → export

Le scratch devient particulièrement pertinent à cette frontière.

Workflow TUI-first

La TUI exposera état projet, découverte de campagne, confirmation des candidats, progression, pause/reprise/annulation disponible, Governor, choix du scratch et étapes aval. ncurses reste au thread principal. Aucun projet GUI général n'est introduit.

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 :

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 :

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 et ne remplace pas le prochain milestone d'intégration multi-campagne A6000 + S21.

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 :

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 :

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 :

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 :

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 :

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

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é :

CURRENT NEXT
  fondation scientifique pré-SfM courante
  → INTERNAL PARALLELISM + COMPUTE RESOURCES v1
  → GPU COMPUTE v1 optionnel si audit/équivalence le justifient
  → poursuite pré-SfM réelle complète de S21
  → acquisition physique dédiée de calibration
  → calibration connue validée → Sparse SfM réel multi-campagne
  → dense / MVS → publication
→ LATER
  Coverage Analysis → Coverage Viewer → suggestions de points de vue
  → localisation live → intégration HDMI/USB → 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-tâches 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.

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. stabilité et intégrité scientifique avant débit ;
2. résultats atomiques et durables avant parallélisme ;
3. lots bornés et reprise avant taille de campagne ;
4. un Task Runtime, un Scheduler et un Resource Governor ;
5. scratch optionnel sans élargissement implicite des budgets RAM ;
6. TUI de contrôle avant visualisation riche ;
7. documentation canonique alignée sur le code validé.