diff --git a/AGENTS.md b/AGENTS.md index 74465d6..620b1ed 100644 --- a/AGENTS.md +++ b/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, diff --git a/README.md b/README.md index 6e27b0f..f4ac5ce 100644 --- a/README.md +++ b/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) diff --git a/docs/architecture/matcher.md b/docs/architecture/matcher.md index 251e6c9..fe36ab1 100644 --- a/docs/architecture/matcher.md +++ b/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 diff --git a/docs/development/opencode_long_run.md b/docs/development/opencode_long_run.md deleted file mode 100644 index 79eb159..0000000 --- a/docs/development/opencode_long_run.md +++ /dev/null @@ -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. diff --git a/docs/opencode_handoff.md b/docs/opencode_handoff.md deleted file mode 100644 index dbf8b03..0000000 --- a/docs/opencode_handoff.md +++ /dev/null @@ -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. -``` diff --git a/docs/opencode_models.md b/docs/opencode_models.md deleted file mode 100644 index 29dd7cc..0000000 --- a/docs/opencode_models.md +++ /dev/null @@ -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`. diff --git a/docs/opencode_workflow.md b/docs/opencode_workflow.md deleted file mode 100644 index 0d838dc..0000000 --- a/docs/opencode_workflow.md +++ /dev/null @@ -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.