feat: complete incremental reconstruction phase H

AGENTS.md

@@ -81,12 +81,8 @@ créé pour les benchmarks, diagnostics, expérimentations ou probes matériels.
 - Un reformatage ne doit jamais modifier le comportement.
 - Ces règles s'appliquent également aux fichiers créés sous `/tmp`.
 
-## Long run OpenCode
+## Validation longue
 
-- `.opencode/work/current_ticket.md` est la mémoire durable du ticket et doit
-  être actualisé après chaque phase majeure.
-- Avant une compaction ou une fin de session incomplète, écrire
-  `.opencode/work/handoff.md` avec la prochaine action exacte.
 - Une seule validation lourde à la fois : normal, ASan/UBSan, TSan puis stress.
 - Un timeout doit être isolé et expliqué ; le répéter jusqu'au vert est interdit.
 - Après les tests verts, imposer revue, audit de concurrence si pertinent,

README.md

@@ -140,7 +140,6 @@ Acquisitions
 - [Tests](docs/development/testing.md)
 - [Concurrence](docs/development/concurrency.md)
 - [Profil de performance de la machine cible](docs/performance/target_hardware.md)
-- [OpenCode long run](docs/development/opencode_long_run.md)
 
 ### Roadmap
 - [Roadmap](docs/roadmap/roadmap.md)

docs/architecture/matcher.md

@@ -75,7 +75,7 @@ matérialisée.
 
 Le Match File complet est sérialisé dans un buffer heap borné à 98336 octets et
 écrit par un unique `write_exact`, puis synchronisé une fois. Les mesures locales
-restent dans `.opencode/work/current_ticket.md`, pas dans ce contrat canonique.
+restent dans le rapport de session, pas dans ce contrat canonique.
 À 8192 features, le coût CPU dominant reste l'évaluation exacte des distances
 dans `cv::BFMatcher::knnMatch`. ORB peut remplacer ce seul hot path par Vulkan.
 Une feasibility réelle a rejeté Vulkan pour SIFT et RootSIFT : leur accumulation

docs/development/opencode_long_run.md

@@ -1,76 +0,0 @@
-# OpenCode long run
-
-`ocaway` lance OpenCode 1.18.15 pour un ticket autonome tout en conservant les
-interdictions destructives du projet. Le mode normal `opencode` reste inchangé.
-
-## Lancement
-
-Le wrapper suivi par le dépôt est `.opencode/bin/opencode-away`. Il doit être
-installé sous `~/.local/bin/opencode-away`, puis l'alias contenu dans
-`.opencode/zshrc.snippet` doit être ajouté à `~/.zshrc`. Ces deux destinations
-sont des symlinks vers les dotfiles utilisateur sur cette machine.
-
-Depuis la racine d'un dépôt Git :
-
-```sh
-ocaway
-```
-
-Les arguments sont transmis tels quels à OpenCode. Le wrapper exporte
-`LARDON_OPENCODE_LONG_RUN=1`, suspend uniquement les processus `swayidle` qui
-étaient actifs, puis lance :
-
-```sh
-systemd-inhibit \
-  --what=sleep:idle:handle-lid-switch \
-  --who="OpenCode Long Run" \
-  --why="Autonomous Lardon3D development ticket" \
-  --mode=block \
-  opencode --auto
-```
-
-systemd 261 supporte les trois inhibitions demandées. La configuration locale
-utilise `HandleLidSwitch=suspend` et laisse `LidSwitchIgnoreInhibited` à sa
-valeur par défaut `yes`, compatible avec l'inhibiteur `block`. Aucun fichier
-systemd ou logind n'est modifié.
-
-Le wrapper enregistre les PID `swayidle` qui n'étaient pas déjà stoppés, leur
-envoie `SIGSTOP`, puis restaure exactement ces PID avec `SIGCONT` à la sortie,
-sur INT, TERM ou HUP. Le code retour du processus OpenCode est conservé.
-
-`opencode-away --check` vérifie les préconditions sans lancer OpenCode ni
-suspendre `swayidle`. `OPENCODE_AWAY_COMMAND` est un seam de test réservé aux
-validations du wrapper ; en usage normal il est absent.
-
-## Permissions et sécurité
-
-La configuration est une allowlist : les outils et commandes inconnus sont
-refusés, et `--auto` ne peut pas contourner un refus. Restent interdits :
-privilèges root, gestion de paquets, Git destructif ou publiant,
-suppression, arrêt de processus ou machine, écriture externe, `.git/` et
-`scan3d/`. Les écritures normales restent dans le worktree courant.
-
-Les sous-agents approuvés sont autorisés explicitement par leur identifiant.
-Chaque agent possède ses propres règles ; il n'hérite pas implicitement d'une
-permission plus large du parent.
-
-## Mémoire et handoff
-
-Le ticket courant est résumé dans `.opencode/work/current_ticket.md` après
-chaque phase. Avant une session fraîche, `.opencode/work/handoff.md` contient
-l'architecture pertinente, les décisions, fichiers, tests, échecs, travail
-restant et la prochaine action exacte.
-
-Les sorties d'outils sont plafonnées et compactées. Les validations lourdes
-sont séquentielles : ciblé, normal, ASan/UBSan, TSan, stress, revue et docs.
-
-## Limites
-
-Une inhibition empêche sleep, idle et la réaction logind au capot tant que le
-wrapper et sa session utilisateur vivent. Elle ne garantit pas la survie du
-processus si le terminal ou toute la session graphique est détruite. Aucun tmux
-n'est créé automatiquement.
-
-Si une dépendance externe manque, si un secret est requis ou si une opération
-explicitement interdite devient nécessaire, le ticket s'arrête avec un handoff
-au lieu de contourner la restriction.

docs/opencode_handoff.md

@@ -1,222 +0,0 @@
-# Transmission du développement à OpenCode (DÉPRÉCIÉ)
-
-> **Ce document est déprécié.** Il a été remplacé par la documentation structurée dans :
-> - [.opencode/context.md](../.opencode/context.md) (contexte permanent)
-> - [.opencode/work/current_ticket.md](../.opencode/work/current_ticket.md) (handoff)
-> - [docs/architecture/overview.md](architecture/overview.md) (vue d'ensemble)
-> - [docs/roadmap/roadmap.md](roadmap/roadmap.md) (feuille de route)
->
-> Ce document est conservé uniquement pour la traçabilité historique.
-
----
-
-## 1. Vision du projet
-
-Lardon3D doit devenir un moteur complet de photogrammétrie Linux, piloté depuis
-une TUI ncursesw. Le terminal reste le centre de contrôle pendant les calculs,
-y compris ceux qui dureront plusieurs heures. La priorité est la robustesse :
-maîtrise de la mémoire, reprise après interruption, résultats atomiques et
-réactivité permanente du système hôte.
-
-Le logiciel traite les données par petits lots : lecture, calcul, validation et
-écriture, puis libération avant le lot suivant. Il préfère une progression plus
-lente mais bornée à une opération monolithique susceptible de saturer la RAM,
-le GPU intégré ou les entrées-sorties.
-
-Lardon3D n'est pas un frontend OpenMVS. Son architecture, son modèle de projet,
-son ordonnanceur, son gouverneur de ressources, ses formats de résultats et sa
-reprise doivent lui appartenir. Un moteur externe éventuel serait un outil
-encapsulé par une étape, jamais le propriétaire du pipeline ni de l'état.
-
-## 2. Architecture actuelle
-
-```text
-TUI
- ↓
-Task
- ↓
-Estimate
- ↓
-Governor
- ↓
-Reservation
- ↓
-Scheduler
- ↓
-Worker
-```
-
-La TUI gère ncurses, les entrées, les écrans et les snapshots destinés au
-layout. Le layout dessine uniquement. Les modules métier ne dépendent pas de
-ncurses et aucun worker ne l'appelle.
-
-`Task` fournit état, progression, pause, reprise, annulation coopérative et
-callback. Chaque tâche possède une `Lardon3DResourceEstimate` immuable. Le
-profil matériel décrit les capacités stables ; un `ResourceSnapshot` mesure la
-disponibilité dynamique. Le `ResourceGovernor` est l'unique arbitre des budgets
-RAM, GPU, CPU et IO. Il répond `START`, `WAIT`, `REDUCE_BATCH` ou `REJECT` et
-crée atomiquement une réservation opaque pour toute admission.
-
-La `TaskQueue` actuelle est FIFO avec un worker. Elle demande une réservation
-juste avant l'exécution, transmet une copie du contrat au callback et libère la
-réservation après succès, échec ou annulation. En `WAIT`, elle dort sur une
-condition variable jusqu'à notification. Une tâche en pause conserve son
-contrat dans cette version.
-
-## 3. Invariants
-
-- Aucun callback de tâche sans estimation et réservation active validée.
-- Le gouverneur décide des ressources ; le scheduler exécute le contrat sans le
-  réinterpréter.
-- Aucune variable globale d'état ni singleton.
-- ncurses appartient exclusivement au thread principal.
-- TUI, dessin et logique métier restent séparés.
-- Les objets aux durées de vie complexes sont opaques et nettoyés explicitement.
-- Une réservation est libérée exactement une fois ; la double libération est
-  refusée sans modifier les budgets.
-- Les budgets et calculs de lots contrôlent les dépassements d'entiers.
-- Les sorties structurantes sont atomiques ; un rollback ne retire que ce que
-  l'opération courante vient de créer.
-- Les fichiers utilisateur antérieurs ne sont jamais écrasés silencieusement.
-- La stabilité du système et la réactivité de la TUI priment sur le débit.
-- Aucun traitement lourd monolithique : préférer des séquences et lots bornés.
-- La mémoire d'un iGPU partagé est comptée dans le budget RAM système.
-- Le swap et la zram sont des filets de sécurité, pas de la mémoire de travail.
-- Une interruption doit préserver le dernier état validé et permettre la
-  reprise à une frontière connue.
-- Le viewer futur reste séparé, non bloquant et lecteur de snapshots validés.
-
-## 4. État actuel
-
-### Terminé
-
-- TUI modulaire avec écrans Accueil, Projets, Import, Viewer, Aide, Tâches et
-  Ressources.
-- État applicatif central, projets persistants et configuration de leur racine.
-- Import sûr, asynchrone et annulable vers `images/originals`, avec manifeste
-  TSV atomique et rollback cohérent.
-- Catalogue vérifié, navigation, tri et filtre en mémoire.
-- Moteur générique de tâches et file FIFO à un worker.
-- Détection du profil matériel et capture des snapshots Linux.
-- Gouverneur thread-safe, estimations, lots adaptatifs et réservations opaques.
-- Intégration scheduler/gouverneur avec réservation obligatoire avant callback.
-- Tests normaux, ASan/UBSan et TSan des fondations.
-
-### En cours
-
-- Consolidation de la documentation et transfert vers OpenCode.
-- Les contrats de lot existent, mais leur enchaînement en séquences complètes
-  n'est pas encore orchestré.
-
-### Non commencé
-
-- Étapes de photogrammétrie, pipeline et cache de calcul.
-- DAG, dépendances, priorités et scheduler multi-worker.
-- Persistance des tâches et checkpoints après crash.
-- Migration de l'import vers le scheduler générique.
-- Publication live des résultats et viewer Vulkan.
-
-## 5. Dette technique
-
-- Le FIFO strict bloque toute la file lorsqu'une tâche en tête reçoit `WAIT`.
-- La file possède un seul worker.
-- Une libération externe exige un appel explicite à
-  `lardon3d_task_queue_resources_changed()`.
-- Les tombstones des réservations libérées restent alloués jusqu'à la
-  destruction du gouverneur.
-- Une erreur de capture des ressources échoue la tâche sans distinguer une
-  panne transitoire.
-- La destruction concurrente du gouverneur ou de la file avec leurs API actives
-  n'est pas supportée ; la file doit être détruite avant le gouverneur.
-- Les files ne possèdent pas encore de capacité maximale ni de contre-pression.
-- Les tâches et checkpoints ne survivent pas au processus.
-- L'import conserve son système de thread spécialisé.
-- `meson.build` référence deux fois `resource_snapshot.c` et
-  `resource_governor.c` dans la cible principale ; Meson le tolère, mais cette
-  duplication déclarative devra être nettoyée séparément.
-
-## 6. Ordre recommandé
-
-1. Sélectionner une tâche admissible sans blocage par la tête de file, afin que
-   `WAIT` n'immobilise pas des travaux compatibles avec les budgets restants.
-2. Définir résultats atomiques, identifiants, métadonnées de validation et
-   frontières de reprise avant de produire des calculs coûteux.
-3. Ajouter le DAG et les dépendances pour représenter explicitement le pipeline.
-4. Persister tâches et checkpoints afin de rendre la reprise réelle.
-5. Orchestrer des séquences adaptatives mesurées, une réservation par lot.
-6. Borner les files, ajouter la contre-pression, puis introduire les pools CPU,
-   IO et GPU sans déplacer l'arbitrage hors du gouverneur.
-7. Migrer l'import vers cette infrastructure validée.
-8. Publier des snapshots live atomiques avant de commencer le viewer Vulkan.
-
-Cet ordre évite de paralléliser ou visualiser des résultats dont le cycle de
-vie, la validation et la reprise ne seraient pas encore définis.
-
-## 7. Optimisations futures
-
-Les éléments suivants sont prévus mais ne sont pas implémentés : DAG de
-dépendances, scheduler sélectionnant intelligemment les tâches admissibles,
-séquences et lots adaptatifs, apprentissage des tailles de lots à partir des
-mesures, pipeline photogrammétrique, cache, reprise après crash, publication
-live et viewer Vulkan. Le viewer devra être séparé de la TUI, s'afficher sur le
-workspace 8 et consommer uniquement des snapshots validés.
-
-Aucune de ces évolutions ne doit contourner les estimations et réservations ni
-introduire des files ou allocations non bornées.
-
-## 8. Profil matériel cible
-
-Lardon3D détecte la machine au démarrage et observe ensuite ses ressources. Il
-ne doit contenir aucune constante de dimensionnement propre à un processeur, un
-volume de RAM ou un GPU particulier. Les valeurs matérielles connues servent à
-établir des plafonds ; les snapshots dynamiques et réservations déterminent ce
-qui peut réellement démarrer.
-
-L'optimisation CPU, RAM, GPU et IO vise une utilisation soutenue mais sûre. Une
-marge reste disponible pour Linux, la TUI et les autres applications. Les iGPU
-partagent la RAM et doivent être comptabilisés comme tels. Le swap et la zram
-signalent une pression dangereuse, jamais une capacité normale supplémentaire.
-
-## 9. Principes d'évolution
-
-- Lire `AGENTS.md` et toute la documentation d'architecture avant de modifier
-  les fondations.
-- Étendre les abstractions validées au lieu de les réécrire.
-- Ne jamais contourner le gouverneur ni fabriquer un contrat d'exécution.
-- Maintenir la propriété explicite des tâches, réservations, threads, mutex,
-  conditions, descripteurs et allocations.
-- Préférer plusieurs petits lots validés à une grande opération.
-- Borner mémoire, files, parallélisme et IO avant toute optimisation de débit.
-- Préserver l'annulation coopérative, les rollbacks ciblés et les écritures
-  atomiques.
-- Ajouter les tests de durée de vie et concurrence avec chaque évolution.
-- Valider avec Clang, Meson, tests, `git diff --check`, ASan/UBSan et TSan selon
-  le risque.
-- Ne jamais modifier ni ajouter `scan3d/` ou `scan3d/tri_photos.py`.
-
-## 10. Prompt OpenCode
-
-```text
-Tu reprends le développement de Lardon3D, un moteur complet de photogrammétrie
-Linux en C17 piloté par une TUI ncursesw.
-
-Avant toute modification :
-- lis README.md, AGENTS.md, docs/opencode_handoff.md et tous les documents de
-  docs/architecture/ ;
-- inspecte entièrement le dépôt, l'état Git, les headers publics, les sources,
-  les tests et meson.build ;
-- comprends les propriétés, durées de vie et frontières de threads existantes ;
-- préserve les changements utilisateur et ne touche jamais à scan3d/.
-
-Respecte impérativement tous les invariants documentés : séparation TUI/métier/
-layout, ncurses uniquement sur le thread principal, estimations immuables,
-gouverneur seul arbitre des ressources, réservation active avant tout callback,
-budgets et files bornés, traitement par petits lots, sorties atomiques,
-rollback ciblé, reprise et stabilité du système prioritaire.
-
-Ne réécris pas les fondations validées et ne contourne jamais le gouverneur.
-Poursuis les développements dans l'ordre recommandé par ce document, un ticket
-à la fois, sans ajouter prématurément DAG, pools, photogrammétrie ou Vulkan.
-Exécute les validations prescrites par AGENTS.md et rapporte honnêtement leurs
-résultats ainsi que la liste exacte des fichiers du ticket.
-```

docs/opencode_models.md

@@ -1,186 +0,0 @@
-# Modèles OpenCode (DÉPRÉCIÉ)
-
-> **Ce document est déprécié.** Il a été remplacé par la documentation structurée dans :
-> - [.opencode/context.md](../.opencode/context.md) (contexte permanent)
-> - [.opencode/agents/](../.opencode/agents/) (définitions des agents)
->
-> Ce document est conservé uniquement pour la traçabilité historique.
-
----
-
-Inventaire effectué le 6 août 2026 avec
-`opencode models --refresh --verbose`. Le seul fournisseur connecté exposé est
-`opencode` via OpenCode Zen. Aucun modèle local n'est apparu. Les catégories
-ci-dessous reposent sur le nom explicite et les champs `cost` retournés par le
-CLI, pas sur une supposition liée à la famille du modèle.
-
-## Modèles gratuits détectés
-
-Sept modèles sont explicitement nommés « Free » et annoncent un coût nul en
-entrée, sortie et cache :
-
-- `opencode/deepseek-v4-flash-free` : agent principal `lardon-build` ; repli
-  recommandé `opencode/nemotron-3-ultra-free` en cas de saturation 503.
-- `opencode/nemotron-3-ultra-free` : architecture, concurrence, revue et repli
-  de l'agent principal.
-- `opencode/mimo-v2.5-free` : exploration rapide et validations.
-- `opencode/laguna-s-2.1-free` : testé comme reviewer sur Lardon3D ; résultats
-  jugés insuffisants. Non utilisé dans les rôles actifs.
-- `opencode/ling-3.0-flash-free` : documentation.
-- `opencode/longcat-2.0-free` : disponible, non configuré actuellement.
-
-## Gratuité non confirmée
-
-`opencode/big-pickle` annonce un coût nul dans les métadonnées du CLI, mais son
-nom ne le qualifie pas explicitement de gratuit. Il reste volontairement non
-configuré tant que les conditions de son offre ne sont pas confirmées.
-
-## Modèles payants volontairement exclus
-
-Les modèles suivants annoncent un coût non nul et ne sont référencés par aucun
-agent ni par la configuration principale :
-
-- Claude : `claude-fable-5`, `claude-haiku-4-5`, `claude-opus-4-1`,
-  `claude-opus-4-5`, `claude-opus-4-6`, `claude-opus-4-7`,
-  `claude-opus-4-8`, `claude-opus-5`, `claude-sonnet-4`,
-  `claude-sonnet-4-5`, `claude-sonnet-4-6`, `claude-sonnet-5`.
-- DeepSeek : `deepseek-v4-flash`, `deepseek-v4-pro`.
-- Gemini : `gemini-3-flash`, `gemini-3.1-pro`, `gemini-3.5-flash`,
-  `gemini-3.5-flash-lite`, `gemini-3.6-flash`.
-- GLM : `glm-5`, `glm-5.1`, `glm-5.2`.
-- GPT : `gpt-5`, `gpt-5-codex`, `gpt-5-nano`, `gpt-5.1`,
-  `gpt-5.1-codex`, `gpt-5.1-codex-max`, `gpt-5.1-codex-mini`,
-  `gpt-5.2`, `gpt-5.2-codex`, `gpt-5.3-codex`,
-  `gpt-5.3-codex-spark`, `gpt-5.4`, `gpt-5.4-mini`, `gpt-5.4-nano`,
-  `gpt-5.4-pro`, `gpt-5.5`, `gpt-5.5-pro`, `gpt-5.6-luna`,
-  `gpt-5.6-sol`, `gpt-5.6-terra`.
-- Grok : `grok-4.5`, `grok-build-0.1`.
-- Kimi : `kimi-k2.5`, `kimi-k2.6`, `kimi-k2.7-code`, `kimi-k3`.
-- MiniMax : `minimax-m2.5`, `minimax-m2.7`, `minimax-m3`.
-- Qwen : `qwen3.5-plus`, `qwen3.6-plus`.
-
-Tous ces identifiants ont le préfixe fournisseur `opencode/`. Aucun basculement
-automatique vers eux n'est autorisé. Si tous les modèles gratuits adaptés sont
-indisponibles, interrompre le travail plutôt que choisir un modèle payant.
-
-## Modèles locaux
-
-Aucun fournisseur ni modèle local n'a été détecté dans la configuration
-OpenCode actuelle.
-
-## Optimisation du quota
-
-L’agent par défaut est `lardon-orchestrator` sur MiMo V2.5 Free.
-
-Le contexte permanent est chargé depuis `.opencode/context.md`. L’orchestrateur
-ne relit pas automatiquement AGENTS.md, l’overview ni toute la documentation
-d’architecture. Il utilise uniquement le handoff courant et les documents
-directement liés au ticket.
-
-MiMo assure :
-
-- l’orchestration ;
-- l’exploration ciblée ;
-- les tests ;
-- les petits tickets.
-
-DeepSeek V4 Flash Free est réservé à l’implémentation complexe. Il ne sert ni à
-l’orchestration, ni à l’exploration, ni aux tests, ni à la documentation.
-
-Nemotron 3 Ultra Free assure :
-
-- les reprises après indisponibilité de DeepSeek ;
-- l’architecture ;
-- la concurrence ;
-- la revue générale.
-
-Ling 3.0 Flash Free est réservé à la documentation.
-
-North Mini Code Free n’est plus utilisé dans les rôles actifs. Il reste mentionné
-dans l’inventaire historique comme modèle testé puis écarté en raison de résultats
-jugés insuffisants et trop erratiques sur Lardon3D.
-
-Les commandes `lardon-plan`, `lardon-small`, `lardon-ticket`,
-`lardon-ticket-backup` et les commandes de reprise utilisent un contexte
-progressif.
-
-Elles ne lisent jamais automatiquement tout le dépôt ni toute l’architecture.
-Elles transmettent uniquement :
-
-- objectif ;
-- contraintes ;
-- fichiers concernés ;
-- API ;
-- invariants ;
-- risques ;
-- tests requis ;
-- prochaine action sûre.
-
-Les rapports de succès restent courts. Le handoff ignoré
-`.opencode/work/current_ticket.md` permet une reprise sans rejouer l’exploration
-ou l’analyse déjà terminée.
-
-Nemotron ne relit jamais sa propre implémentation lorsqu’il a servi de backup.
-
-Dans ce cas :
-
-- MiMo fournit seulement une première revue locale simple ;
-- la revue de concurrence sensible est différée jusqu’au prochain passage Codex ;
-- le workflow signale explicitement qu’aucune revue indépendante forte n’a eu
-  lieu.
-
-Aucun modèle payant n’est utilisé automatiquement.
-
-## Chaîne de secours
-
-La voie normale est DeepSeek V4 Flash Free pour l'implémentation. En cas de 503,
-saturation, quota épuisé ou interruption, sauvegarder le handoff et reprendre
-avec Nemotron 3 Ultra Free. Si Nemotron est indisponible, MiMo V2.5 Free est
-limité aux petits changements ; il doit refuser une fondation sensible.
-
-GPT-5.6 Sol n'est pas actif dans OpenCode, car l'identifiant visible passe par
-Zen et annonce un tarif. Pour utiliser le quota ChatGPT/Codex, la voie normale
-reste Codex CLI via `lardon-codex-handoff`, puis
-`lardon-resume-from-codex`. Aucun modèle payant n'est un fallback.
-
-## GPT-5.6 Sol dans OpenCode
-
-Vérification locale du 6 août 2026 avec OpenCode 1.18.13 :
-
-- identifiant exact : `opencode/gpt-5.6-sol` ;
-- fournisseur : `opencode`, affiché comme OpenCode Zen ;
-- endpoint déclaré : `https://opencode.ai/zen/v1` ;
-- authentification active : credential Zen de type `api` ;
-- clé OpenAI API séparée : non requise par cette route Zen, mais le credential
-  Zen reste nécessaire ;
-- OAuth ChatGPT/Codex : non détecté ;
-- plugin Codex OAuth : non installé ;
-- OpenCode Zen utilisé : oui ;
-- tarif affiché : entrée 5, sortie 30, cache lecture 0,5 et écriture 6,25 dans
-  les unités tarifaires retournées par OpenCode ; tarifs supérieurs au-delà du
-  palier de contexte indiqué ;
-- facturation distincte du quota Codex : route Zen tarifée, donc à considérer
-  distincte ;
-- quota Codex partagé : non confirmé et aucune preuve locale ne l'indique ;
-- test minimal : non exécuté, car la route identifiée est payante ;
-- classement : **Q3 — GPT-5.6 Sol fourni par OpenCode Zen** ;
-- politique : aucun agent, commande active ou fallback Sol dans OpenCode.
-
-La preuve locale combine `opencode models --refresh --verbose`, qui expose le
-fournisseur, l'endpoint et le coût, et `opencode providers list`, qui expose un
-seul credential OpenCode Zen. La configuration globale ne déclare aucun
-fournisseur OpenAI ni plugin d'authentification Codex. Aucun secret n'a été lu
-ou reproduit dans ce document.
-
-## Actualisation
-
-Les offres changent. Réexécuter :
-
-```sh
-opencode models --refresh --verbose
-```
-
-Comparer les identifiants, le fournisseur et surtout les champs `cost`. Ne pas
-déduire la gratuité du nom seul. Mettre ensuite à jour ce document et chaque
-frontmatter `model:` sous `.opencode/agents/`, puis valider la configuration
-avec `opencode debug config`.

docs/opencode_workflow.md

@@ -1,90 +0,0 @@
-# Workflow OpenCode et Codex (DÉPRÉCIÉ)
-
-> **Ce document est déprécié.** Il a été remplacé par la documentation structurée dans :
-> - [.opencode/context.md](../.opencode/context.md) (contexte permanent)
-> - [.opencode/work/current_ticket.md](../.opencode/work/current_ticket.md) (handoff)
-> - [docs/development/build.md](development/build.md) (instructions de build)
-> - [docs/development/testing.md](development/testing.md) (procédures de test)
->
-> Ce document est conservé uniquement pour la traçabilité historique.
-
----
-
-Ce workflow minimise le contexte tout en conservant un handoff fiable. Le
-fichier `.opencode/work/current_ticket.md` est local et ignoré par Git. Il ne
-contient que l'objectif, les contraintes, fichiers et documents utiles, plan,
-travail terminé et restant, fichiers modifiés, commandes, tests, décisions,
-erreurs, modèle actif et prochaine action sûre.
-
-## A. Ticket gratuit normal
-
-Lancer `/lardon-plan`, puis `/lardon-ticket`. North orchestre et explore via des
-agents distincts, puis DeepSeek implémente. Architect et concurrency ne sont
-appelés que si le périmètre l'exige. Tests et revue Nemotron interviennent une
-seule fois après le code.
-
-## B. DeepSeek retourne 503
-
-Lancer `/lardon-save-handoff`, puis `/lardon-resume-backup`. Nemotron lit le
-handoff et le diff, reprend la prochaine action et ne refait pas l'analyse si
-les informations suffisent. Nemotron ne peut ensuite pas fournir une revue
-indépendante de son propre travail : MiMo effectue une première revue locale
-simple. Toute revue de concurrence sensible attend le prochain passage Codex,
-et le rapport indique explicitement l'absence de revue indépendante forte.
-
-## C. DeepSeek et Nemotron sont indisponibles
-
-Lancer `/lardon-resume-light` uniquement si le travail restant est petit et
-local. Pour une fondation sensible, conserver le handoff et attendre DeepSeek
-ou Codex ; ne pas forcer MiMo à réécrire l'architecture.
-
-## D. Petit ticket avec MiMo
-
-Lancer `/lardon-small`. L'exploration reste ciblée, MiMo est le seul auteur,
-puis les validations ciblées et `git diff --check` sont exécutées. Basculer vers
-le workflow normal si la complexité dépasse une correction locale.
-
-## E. Quota Codex renouvelé
-
-GPT-5.6 Sol visible dans OpenCode est une offre Zen payante, pas une voie Codex
-confirmée. Lancer `/lardon-codex-handoff`, copier le prompt court produit dans
-Codex CLI, puis utiliser Codex directement. Aucune clé n'est copiée entre les
-outils.
-
-## F. Retour depuis Codex
-
-Lancer `/lardon-resume-from-codex`. OpenCode lit le handoff et le diff laissé
-par Codex, puis effectue revue et tests sans refaire l'architecture. Le handoff
-est ensuite actualisé.
-
-## G. GPT-5.6 Sol direct dans OpenCode
-
-Ce scénario est désactivé : Q1 n'est pas confirmé. Il ne pourra être ajouté que
-si une route ChatGPT/Codex officiellement supportée, sans facturation Zen ou API
-distincte, et une consommation du quota Codex sont toutes prouvées.
-
-## H. Authentification directe avec quota inconnu
-
-Le cas Q2 n'a pas été observé. S'il apparaît plus tard, aucune utilisation ne
-doit être automatique : documenter le fournisseur et le risque, puis obtenir une
-décision explicite avant une commande expérimentale.
-
-## I. Fallback payant interdit
-
-La configuration ne référence que des modèles explicitement gratuits. Une panne
-de tous les secours gratuits arrête le ticket en conservant le handoff. Elle ne
-doit jamais sélectionner `big-pickle`, GPT-5.6 Sol ou un autre modèle tarifé ou
-de statut inconnu.
-
-## Chargement progressif
-
-1. Lire AGENTS.md et l'overview injectés par la configuration.
-2. Faire identifier par explore les seuls fichiers et documents utiles.
-3. Charger ces documents seulement ; appeler architect si une abstraction est
-   touchée.
-4. Transmettre à l'implémenteur un résumé concis, jamais les documents complets.
-5. Appeler uniquement les validations et revues pertinentes.
-
-Pour une reprise, commencer par le handoff et le diff. Les sorties intermédiaires
-ne conservent que conclusions, risques, fichiers, commandes, erreurs et
-décisions ; les longs logs et les sources complètes sont exclus.