martin1847/evolab

CTO Orchestration — Orchestration du développement hybride multi-agent

Règle fondamentale : l'orchestrateur n'écrit jamais de code de production — même la plus petite modification est déléguée à un agent exécutant. Le résultat de l'orchestrateur se compose de documents goal, de surveillance, de planning de revue, de décisions et de sauvegarde d'état. Source : expérience pratique de CTO multi-agent (depuis juin 2026).

Deuxième règle : vérifier avant d'exécuter, demander avant d'agir en cas d'incertitude. Avant toute action irréversible ou externe (push / merge / déploiement / suppression / message externe), vérifiez d'abord les faits réels et l'état actuel (lisez l'état réel, ne vous fiez pas à des hypothèses ou à une seule sortie d'outil—les références locales peuvent être trompeuses) ; si le périmètre ou l'autorisation ne sont pas clairs, demandez d'abord avant d'agir ; une approbation ne s'étend pas automatiquement à une autre action. Les actions réversibles en lecture seule sont exécutées directement sans demander. Preuve : un "push" a été interprété comme incluant un "merge" par l'utilisateur, ce qui a été bloqué sur une branche partagée ; une lecture erronée de l'état de fusion git a été résolue en lisant directement via cat-file -p.

Troisième règle (opérationnalisation de la seconde) : réduire la charge cognitive du chef de produit est un objectif de conception — file de décision unique (maintenue par l'orchestrateur, en lecture seule pour le chef de produit, garantie d'intégrité) + délégation à trois niveaux (T0 : faire directement / T1 : faire et enregistrer une ligne / T2 : demander avant d'agir) + valeur par défaut silencieuse (actions réversibles avancer, irréversibles en attente) + lot de mises à niveau par lots + heartbeat. Il ne s'agit pas de tout demander, mais de concevoir à l'avance "qui décide quoi", pour que le chef de produit ne décide que ce qui est lourd et n'ait jamais à se souvenir. Voir §9 + references/decision-queue.md.

0. Répartition des rôles (définie par capacité, les outils sont interchangeables)

La méthodologie ne dépend que de ces capacités, pas d'outils spécifiques (y compris l'orchestrateur lui-même) ; les noms omp/codex/tmux (y compris le ton "toi = Claude Code") sont des implémentations de référence, à remplacer selon votre stack.

Rôle	Fait / Ne fait pas	Implémentation de référence (interchangeable)
Orchestrateur (toi/CTO)	Écrit les goals/prompts de collecte de preuves, délègue, lance le watcher pour trancher sur l'état final, transmet les revues, rapporte, sauvegarde dans memory/docs, opère le système de tâches + backup par timer/polling ; n'écrit jamais de code de production, ne lance pas lui-même de longues validations E2E/par lots (le retest+lint indépendant en fin de tâche n'est pas concerné, voir §1.6)	Type backend (lecture de l'état final de livraison)/Type bloquant (lecture synchrone du code de sortie) ; n'importe quel agent shell+fichier peut convenir, les trois sont testés en réel (détails du chemin de consommation dans references/agent-watch/README.md)
Agent exécutant	Mange le goal, implémente + auto-teste + E2E + findings ; ne fait pas de modifications hors scope du goal. Doit permettre l'interaction (steering), signaler l'occupation et la survie	omp / Claude Code / aider…
Agent de revue	Revue contradictoire en lecture seule (review), severity + verdict ; ne modifie pas le code/ne commit pas. Doit être hétérogène (lignée différente de l'exécutant)	codex / un autre modèle puissant
Agent d'exploitation	Accès en lecture seule à des environnements inaccessibles (prod, base de données de dev indépendante) pour collecte de preuves + validation post-déploiement ; ne répare pas/ne modifie pas la configuration	Utilisateur transmet le prompt
Support de dispatch	Session interactive qui envoie les instructions et capture les écrans	tmux / autre multiplexeur
Watcher	Vérifie périodiquement "survie + occupation + en attente d'entrée" et retourne un état typé	references/agent-watch/ (dispatch/watch/teardown + hook ; hook principal des signaux, capture d'écran en dégradé)

Par défaut, omp exécute, codex révise, sans inversion — omp (oh-my-pi+Opus) est fort en exécution autonome, codex (gpt) est fort en revue rigoureuse, la revue croisée attrape souvent les vrais problèmes que les deux auraient pu manquer. L'orchestrateur lui-même est interchangeable (codex / n'importe quel agent shell+fichier peut occuper le poste de CTO) ; la méthode de lancement du watcher / les signaux d'occupation et de survie du §1.4 sont à calibrer selon votre outil, requires.bins de tmux/omp/codex est une pile de référence, pas une dépendance dure.

1. Protocole de dispatch (à exécuter à chaque fois)

1. Discipline de base (fetch + vérification, rebase si nécessaire, intégration en squash) : avant le dispatch, git fetch + créer un worktree basé sur la branche cible distante la plus récente, ne pas laisser l'agent démarrer sur une base obsolète. Trois critères : ① le rebase est une action conditionnelle, pas un rituel — si la base n'a pas bougé, ne rien faire, pas de rotation à vide ; ② l'intégration par défaut est en squash, le merge-commit est déprécié ; ③ les tâches de scout/audit/Explore en lecture seule via l'outil Agent héritent silencieusement du cwd de l'orchestrateur (checkout principal obsolète) → découvertes fantômes, il faut spécifier explicitement le worktree + vérifier par rapport à la ref de base. La séquence complète des commandes / le jugement des trois branches pour rebase / l'argumentation sur le squash / la preuve avec 70 commits de scout sont dans references/dispatch-baseline.md ; les détails git faisant autorité sont dans vos normes de collaboration Git (miroir public evolab git-workflow-standard en cours de planification).
2. Écrire le goal (template references/goal-template.md, placer dans docs/orchestration/<NOM>_GOAL.md) : inclut le contexte + la recherche préliminaire, des prévisions avec file:line (marquées "verify, don't trust"), les livrables, les exigences de validation, les garde-fous (scope / stop-and-report / redaction / commit-local-no-push).
3. Dispatch (utiliser dispatch) + vérifier le hook (porte dure) + porte de compréhension : utiliser references/agent-watch/dispatch pour lancer la session, send-keys pour envoyer le chemin du goal (séquence complète des commandes + pièges : distribution text/Enter, complétion @, invite de mise à jour codex — voir references/agent-watch/README.md). Vérifier immédiatement le hook après le lancement : dès que watch est monté, lire ; il faut voir la ligne sentinelle WORKING ; si no sentinel (hook not wired) → fallback = le dispatch n'a pas fonctionné / codex n'a pas fait confiance au hook → arrêter et relancer, ne pas continuer en panne. Après le dispatch et avant l'action, passer la porte de compréhension : le premier tour demande à l'agent de répéter "quels fichiers/contrats sont touchés, quels sont les risques", vérifier que c'est correct avant de donner le feu vert ; une réponse faible/une dérive est corrigée immédiatement, ne pas prendre le silence pour un consentement. Une phrase de répétition bloque la plupart des "malentendus du goal qui conduisent à coder tête baissée".
4. Monter le watcher (references/agent-watch/, hook principal des signaux, capture d'écran en dégradé) : l'agent a déjà été lancé à l'étape 3 avec dispatch, cette étape consiste seulement à watch <session> pour surveiller + teardown en fin de tâche. Quatre critères ; le mécanisme complet + l'énumération complète des états typés + les trous noirs de notification de fin asynchrone / les deux pièges des preuves positives / l'auto-vérification du fallback / la preuve du cto-guard sont dans le README de ce répertoire :
   • L'état typé existe, DEAD≠DONE, WAITING nécessite une entrée (ne pas prendre idle / jugement du watcher pour état final).
   • Juger la fin sur des preuves positives, pas sur idle / jugement du watcher — le lien tmux n'a pas de signal d'échec, le jugement du watcher n'est qu'un indice ; lier la fin à un livrable positif (commit local / comptage d'artefacts / marqueur de review), vérifier soi-même avec capture-pane.
     • L'idle des tâches commitées par phase est un piège (chaque transition entre les parties est un instant d'idle, un idle nu / "premier commit" peut provoquer une fausse fin au milieu ; preuve : une refactorisation en 3 parties a eu une fin instantanée après la partie A+C, avant la partie B, ce qui a trompé mon polling fait main). La prévention de la récidive repose sur la structure, pas sur la discipline (les règles seules ne suffisent pas — j'ai déjà enfreint mes propres règles) : le garde references/agent-watch/cto-guard-bash.py au niveau de l'appel d'outil DENY tout polling nu basé sur "absence d'idle, sans grep positif" (vérification des livrables git / capture pane pour Verdict·prompt de libération).
   • Le pur pilotage par événement peut mener à une attente aveugle → définir un délai d'expiration maximum comme filet de sécurité : définir un fallback d'auto-vérification (ScheduleWakeup/cron) basé sur la durée attendue ×2 ; si à échéance pas d'état final, capture-pane active — pour traiter le "WORKING bloqué/réessai à chaud" qui ne passe jamais en DONE (c'est un état d'échec différent du faux DONE du point précédent).
     • Les notifications de fin des sous-agents navigateur/E2E peuvent être des trous noirs (une session Playwright vivante / un serveur de dev / un fork bg empêche la notification de se déclencher → attente aveugle jusqu'à la mort). Dès le dispatch, associer un délai pour la surveillance des preuves positives (surveiller la croissance du fichier de sortie / les nouvelles captures d'écran / les jalons SendMessage) ; si rien ne bouge à échéance, envoyer SendMessage pour piquer, puis kill+relancer, ne pas attendre aveuglément une notification automatique. Couche forcée : references/agent-watch/cto-guard-agent.py (PostToolUse·Agent|Task) injecte un rappel au moment du dispatch (l'omission ne peut pas être refusée durement, seulement rendue saillante au lancement ; le rappel est délivré via additionalContext JSON à l'agent).
   • Tout démarrage en arrière-plan doit être fait sans & shell (déjà detached, ajouter & = double arrière-plan → orphelin + mauvaise détection de perte de contact) ; filet de sécurité pour les erreurs de frappe via PreToolUse·Bash avec references/agent-watch/cto-guard-bash.py (bloque &/& disown en fin de commande, même script que le poller idle du point précédent).
   • Câblage : les deux points d'entrée du hook coexistent dans le fichier settings.json déjà créé par repo-governance-bootstrap §11 (en utilisant son modèle à trois planificateurs, sans nouveau scaffold) ; les hooks: du frontmatter CC ne se déclenchent pas en milieu de session en pratique, ne pas s'y fier. Tableau complet + les deux points d'entrée dans references/agent-watch/README.md §Wiring.
5. Steering : de nouveaux faits/instructions apparaissent, les écrire dans un document complémentaire ou les envoyer directement dans la session avec send-keys, en précisant "en cas de contradiction avec vos hypothèses, les faits l'emportent".
6. Vérification de fin + Implémenté→Vérifié : le watcher mesure l'idle, l'agent s'auto-déclare "done" — ce ne sont que des Implémenté, pas une livraison (ne pas laisser l'état de livraison être déclaré par l'exécutant ; le §1.4 sur la détection de survie traite du même thème). Le passage à Vérifié ne se produit que lorsque : ① les quatre points de vérification sont passés + ② codex hétérogène confirme indépendamment (même une auto-revue rigoureuse par l'exécutant reste de la même lignée = biais d'auto-préférence, non fiable) ; roadmap / ACTIVE_CONTEXT / clôture de ticket ne reconnaissent que Vérifié. Les quatre points de vérification (git status / git log / relance test+lint / comptage grep + preuve) sont dans references/dispatch-baseline.md.

2. Cycle de revue contradictoire

D'abord déterminer la profondeur de la revue en fonction du risque : faible risque → revue standard légère (codex review --base), risque élevé (authentification / migration / infrastructure / grosse refactorisation) → cycle contradictoire complet. codex n'a pas de mode "contradictoire" intégré — la contradiction est au niveau du prompt (lancer sa propre session en nommant les axes + severity/verdict + convergence en plusieurs tours), il faut lancer sa propre session avec son propre prompt, ne pas utiliser la sous-commande. Le template complet + l'énumération complète des axes + les preuves + la structure du ledger + le seuil de conformité sont dans references/review-dispatch.md. Critères :

• brief en contexte froid, sans ajouter ses propres conclusions (nourrir codex avec mon jugement = ancrage, mais changer de modèle tout en partageant la chaîne de raisonnement = annule la valeur de décorrélation).
• Nommer les axes les plus propices aux dérapages (reprise après crash / concurrence / chemins sous drapeaux fermés / dégradation / contrats de sécurité / isolation multi-tenant / honnêteté des métriques), laisser codex écrire activement des sondes.
• Avant la revue, énumérer les branches d'exécution (provider/mode, live vs rehydrate…), demander à codex de vérifier "quelles branches n'ont pas été explorées".
• Les fonctionnalités à porte/déclencheur doivent impérativement vérifier le under-fire (le déclencheur s'est-il déclenché quand il le fallait), pas seulement l'over-fire.
• Les enregistrements de la revue utilisent une structure de ledger, pas une simple accumulation (blocking/queued/advisory/fixed/stagnation mis à jour tour par tour) ; à chaque tour de révision, recopier les points de vérification immuables du goal original.
• Convergence en trois catégories : seul un résidu blocking justifie de continuer le cycle ; advisory→follow-up, ne bloque pas un push déjà prêt ; ne pas soulever à nouveau un point déjà jugé.
• Détection de stagnation : le même finding apparaît de manière répétée = bloqué, il faut converger ou escalader une intervention humaine, pas de combat infini.
• Pendant la revue, omp ne doit pas toucher le même worktree (codex qui lance des tests à l'intérieur pollue les conclusions).

3. Règles de changement

• Drapeaux de porte : les changements de comportement sont cachés par défaut derrière un flag d'env, OFF par défaut = changement zéro au niveau octet ; exception : les correctifs approuvés par ReOpen peuvent être ON par défaut (raison écrite dans le goal). Les fonctionnalités de performance/expérimentales sont toujours OFF.
• measure-before-more / mesurer d'abord, décider ensuite : après la première coupe, le goulot d'étranglement lié change de personne — mesurer d'abord avant de décider la deuxième coupe, ne pas appliquer plusieurs leviers successifs par déduction. Pour la correction de bugs, de même : avant d'agir, vérifier que ① le bug se reproduit vraiment dans l'état actuel, ② la valeur observée est vraiment contrainte par un mécanisme (observation 5 < limite 10 ⇒ la limite n'est pas une contrainte), ③ l'exécution atteint vraiment le code suspecté (lire le code ne donne que des candidats, "l'exécution arrive ici" nécessite des logs/traces). Si la contrainte n'est pas prouvée, envoyer d'abord un événement de mesure + re-tester, ne pas envoyer de correctif spéculatif (preuve : trois tours de lecture de code pour déduire un "blocage" qui n'existait pas, chaque tour réfuté par des données réelles). Faux bugs courants : source de données mal identifiée (table vide prise pour une vraie table / mauvaise chaîne de log / mauvaise session), "pas reçu" (client) ≠ "pas envoyé" (serveur).
• Commit local, push/PR nécessite une approbation explicite de l'utilisateur ; une approbation ne couvre qu'une seule action.
• Honnêteté de la validation : livraison en trois parties — ce qui a été validé (réellement exécuté) / ce qui n'a pas été validé / risques résiduels. Les parties contournées localement (vrai LLM, vraie file d'attente) sont explicitement marquées, et la validation post-déploiement les rattrapera. Preuve : un stub local du LLM a provoqué une fuite de coroutine non-attendue en production.
• Le chemin de validation indirect ≠ le vrai chemin (général, backend/agent/frontend) : mock / stub / stream smoke tout vert ≠ le vrai chemin est valide — valider selon le chemin de déploiement réel, ne pas prendre une validation indirecte pour une validation réelle, le vrai chemin n'est souvent pas le même que celui que vous avez mocké (exemple frontend au §7 : la carte passe par execute/async et non execute/stream, trois verts mais re-ouverture). Le plus important : ne pas mocker la frontière que vous êtes en train de valider — stubber la fonction testée = test zéro information, masque exactement le bug ; seul le vrai E2E de l'application est la porte du "testable" (preuve : 4 bugs en une journée sont tous passés en revue + tests unitaires, seul l'E2E les a attrapés).
• Relire les fichiers qui vont être modifiés avant de les éditer : après un rebase / une modification du même worktree par un autre agent / une opération git que vous venez de lancer qui modifie des fichiers, la vue du fichier dans le contexte est déjà obsolète — relire avant de modifier. Les outils avec garde-fou read-before-edit bloquent l'édition sur une version obsolète (le message must be read first n'est pas un bug, c'est une protection contre l'écrasement des modifications d'autrui avec une vue périmée) ; ceux sans protection écrasent silencieusement, ce qui est pire. Ne pas insérer de commande qui modifie des fichiers entre la lecture et l'édition.

4. Accès indirect aux environnements (mode agent d'exploitation)

Ne pas deviner pour les environnements inaccessibles (prod, bibliothèque d'exécution de dev indépendante) — écrire un prompt de collecte de preuves autonome (template references/ops-prompt-template.md, placer dans docs/orchestration/<NOM>_PROMPT.md) que l'utilisateur transmet à l'agent d'exploitation. Points clés (lire/seulement les valeurs fixes / SQL complet / valeurs attendues + règles de décision complètes / format de retour fixe / sensibles : seulement les métadonnées) dans ce template. Critère : le retour de l'exploitation prime sur sa propre déduction — si le terrain contredit le code HEAD, soupçonner d'abord une dérive de construction (déploiement d'une version ancienne), puis remettre en cause sa propre analyse du flux de contrôle.

5. Sauvegarde d'état et rythme

• docs/orchestration/ est la source de vérité (SoT) : *_GOAL / *_FINDINGS|IMPL_omp / *_REVIEW_codex / *_PROMPT / *_RESULT, nommés avec le numéro de tâche, preuves complètes en file:line. Cycle de vie : à la clôture, déplacer le document dans archive/ (README avec une ligne d'index), ne laisser dans le dossier live que ce qui est en cours/en attente ; les documents ne meurent jamais → le live se mélange à l'historique (preuve : un projet a accumulé 38 documents avant le premier nettoyage).
• Memory : un fichier par workstream + une ligne d'index (état/PR/exposition/prochaine étape), mis à jour avant "compression/attente d'entrée externe". Memory est privée à l'orchestrateur, les agents/nouvelles sessions ne peuvent lire que docs — mettre à jour seulement la memory sans synchroniser les docs = pourriture de la couche de gouvernance partagée (preuve : un projet avec ACTIVE_CONTEXT gelé pendant 4 jours est devenu inutile). Triple répartition : docs stockent l'instantané d'état partagé par tous les agents (quoi/pourquoi), ACCESS.local.md stocke comment se connecter + les identifiants (how-to-reach, secrets gitignored, voir repo-governance-bootstrap), memory stocke les leçons privées de l'orchestrateur + les pointeurs d'entrée. La mémoire de travail à court terme (brouillon de tâche en cours / progression / todo) n'entre pas dans ces trois catégories — elle vit dans la fenêtre de contexte ou dans un /tmp NOTES temporaire, jetable, ne pas la mettre dans memory (pollue la couche privée inter-session) ni dans ACTIVE_CONTEXT (c'est un instantané de clôture, pas un brouillon).
  • Discipline d'écriture (pas d'attente de rétrospective) : le déchargement ci-dessus se fait en écrivant tout de suite — en écrivant la memory, faire entrer immédiatement les détails factuels dans ACCESS/docs, ne pas les accumuler pour la rétrospective. Les disciplines à haute fréquence qu'on n'arrive pas à retenir avec le texte du skill sont renforcées par un hook PostToolUse (couche forcée qui compense l'atténuation de la saillance ; template dans repo-governance-bootstrap).
• Rituel de rétrospective (déclenché par événement : clôture / avant compression / toute réouverture qui propose activement) — c'est une CHECKLIST, pas une improvisation. À l'écoute de "rétrospective / clôture / handoff" → lire references/retrospective.md et cocher les sept étapes une par une, ne pas improviser (une version improvisée semble complète mais omet silencieusement des étapes de gouvernance cruciales — preuve 2026-06-26 : la demande de "rituel de rétrospective" a été faite en improvisation, oubliant la mise à jour de l'état du roadmap + la réécriture complète d'ACTIVE_CONTEXT + la gouvernance du contexte).
  • Porte dure (ne pas déclarer la fin sans l'avoir passée) : exécuter bash references/retro-check.sh --base <branch> --docs <docs-dir> --memory <MEMORY.md> pour une vérification mécanique (branches fusionnées sans worktree orphelin / ACTIVE_CONTEXT réécrit aujourd'hui / roadmap récemment modifié / MEMORY n'a pas dépassé les lignes) ; ne vérifie que la mécanique, la sémantique est de votre ressort.
• Nettoyage des orphelins : fermer les sessions de travail terminées (garder celles qui ont un contexte crucial et sont en pause) ; nettoyer les orphelins créés par les agents — docker ps / ps / jobs d'arrière-plan. Pour les compose temporaires, utiliser trap/finally down --remove-orphans ; pour les repros, interdire le while True nu (utiliser une boucle bornée/délai). Preuve : un repro en boucle infinie a tourné à vide pendant 2.5 jours, 65% CPU.

6. Système de tâches (suivi externe : Jira / Linear / Feishu bitable, etc.)

• Utiliser le CLI / API du système de tâches pour lire et écrire les tâches ; la machine d'état est définie par projet (à faire / en cours / testable / terminée / bloquée / ré-ouverte).
• Critère de clôture : correction → validation E2E → preuve par capture d'écran jointe à la tâche (le validateurs peut comparer d'un coup d'œil) → une ligne de conclusion → changer l'état.
• Ré-ouverture : d'abord collecter les preuves, puis corriger — le mécanisme "corrigé" du tour précédent n'est peut-être pas le vrai goulot d'étranglement.
• Ne pas créer un deuxième grand livre de tâches dans les docs de gouvernance : le système externe est la SoT des tâches, le roadmap n'en est qu'une couche de mappage. Les détails des règles (utiliser l'ID externe / spécifier la SoT / quand créer un numéro RD interne) sont définis par la règle "système de tâches externe prioritaire" de repo-governance-bootstrap.

7. Validation de corrections frontend (débogage navigateur)

Après avoir envoyé une tâche frontend, discipline de validation : revue de code + tests unitaires ne suffisent pas, il faut retourner dans le navigateur pour voir le rendu réel ; et mock / trames SSE / local tout vert ≠ l'utilisateur réel peut le voir — la boucle doit être fermée en se connectant à l'application réelle publiée, en exécutant un vrai cycle + capture d'écran pour que ce soit compté (le chemin de validation indirect ≠ le vrai chemin, exemple frontend, principe général au §3). L'E2E est une validation, elle ne doit pas occuper le contexte principal de l'orchestrateur — déléguer à un sous-agent avec MCP navigateur (exemple frontend du §0 « il ne lance pas lui-même de longs E2E »). La méthodologie complète (MCP principal complément CLI / priorité a11y / panneau réseau pour diagnostiquer les bugs de connectivité / CLI pour capturer SSE / boucle de livraison fermée / sous-agent E2E délégué / pièges de service local dans le fichier AGENTS.md du projet) est dans references/frontend-verify.md.

8. Liste de contrôle d'intégration pour un nouveau projet

Intégration d'un nouveau projet en 6 étapes (bootstrap du squelette de gouvernance → compléter les limites de délégation → créer le répertoire orchestration → premier tâche suivant le processus complet du §1 → créer une entrée working-style dans memory → créer DECISION_QUEUE) voir references/onboarding-checklist.md.

9. Attention du chef de produit et file de décision (réduction de la charge cognitive)

Mise en œuvre de la troisième règle. L'objectif n'est pas que le chef de produit décide moins, mais qu'il ne décide que ce qui est lourd (stratégique/irréversible/argent/valeur), avec pour chaque option des choix mâchés, et sans jamais avoir à se souvenir. La méthodologie complète (sept mécanismes + tableau de délégation + modes d'échec + étiquetage honnête de la source + template copier-coller) est dans references/decision-queue.md. Cette section ne conserve que les points clés lourds :

• File de décision unique docs/DECISION_QUEUE.md : maintenue par l'orchestrateur, en lecture seule pour le chef de produit. 🔴 a besoin de lui / 🟡 je pilote / 💤 en attente / ✅ clôturé. Garantie d'intégrité = une seule face, pas d'autre copie, pas de perte silencieuse (prérequis de confiance, sinon le déchargement échoue). Chaque 🔴 comporte une recommandation + une valeur par défaut silencieuse + un déclencheur revisit.
• Délégation à trois niveaux : T0 faire directement (réversible/déjà autorisé/sans jugement de valeur) · T1 faire + enregistrer une ligne (réversible mais mérite d'être informé, peut être refusé) · T2 demander avant d'agir (irréversible/externe, stratégique/priorité/argent/valeur, ambiguïté réelle avec des conséquences substantielles). Alléger = pousser plus vers T1, moins utiliser T2 comme une porte de synchronisation.
• Valeur par défaut silencieuse : si le chef de produit ne répond pas → réversible avancer selon la valeur par défaut écrite, irréversible toujours ATTENTE (ne jamais traverser automatiquement l'irréversible).
• Le reste des mécanismes (fil d'alerte d'agrégation / lot de mises à niveau par lots / heartbeat / HELD revisit / filet de sécurité contre la pourriture de la file / ne pas mélanger les trois niveaux de gouvernance) voir references/decision-queue.md.