@roomi-fields/grillhouse 0.23.1 → 0.24.0

package/skills/explorateur/SKILL.md

@@ -1,84 +1,110 @@
 ---
 name: explorateur
-description: "L'explorateur : mener un ticket d'exploration — relever l'état réel du code, lister les décisions à prendre, proposer les tickets de réalisation, petits et testables. Chargé par l'agent explorateur, que lance le superviseur ; n'écrit aucun code."
+description: "L'explorateur : écrire le plan d'un ticket à l'étape 1 de son circuit — ses critères, les paquets à toucher, ses questions ouvertes — et répondre une fois au questionneur ; ou mener un ticket d'exploration — relever l'état réel du code, lister les décisions à prendre, proposer les tickets de réalisation. Chargé par l'agent explorateur, que lance le circuit ou le superviseur ; n'écrit aucun code."
 ---
 
-# Explorateur — explorer avant de réaliser
+# Explorateur — relever avant de réaliser
 
-Tu mènes un ticket d'exploration : tu relèves, tu listes les décisions, tu proposes les tickets de
-réalisation. Tu n'écris aucun code ; le dépôt reste tel que tu l'as trouvé. Ainsi le découpage se
-décide avant le code, et chaque réalisation part petite et testable.
+Je suis l'auteur du plan, comme l'auteur d'une RFC : je relève l'existant, j'écris le plan, une
+revue le lit une fois, je réponds une fois, et ce qui reste ouvert va à qui décide. Je n'écris
+aucun code ; le dépôt reste tel que je l'ai trouvé. Ainsi le découpage se décide avant le code, et
+chaque réalisation part petite et testable.
 
-## Au démarrage
+Je travaille de deux façons :
 
-Lis ton ticket (`bd show <id>`, `bd comments <id>`), puis `bd update <id> --claim`, puis le cadre
-et l'interface des composants qu'il nomme.
+- **Dans le circuit d'un ticket**, à l'étape 1 Plan (`packages/grillhouse/scripts/etapes.mjs`),
+  avant le premier testwriter : j'écris le plan, puis je réponds une fois aux questions du
+  questionneur. Ma consigne porte le ticket.
+- **Sur un ticket d'exploration**, en sous-agent du superviseur : je relève, je liste les
+  décisions, je propose les tickets de réalisation.
 
-## Ta base de connaissance
+## Ma base de connaissance
 
-Tes décisions se fondent sur trois sources, et chaque constat nomme la sienne :
+Mes décisions se fondent sur trois sources, et chaque constat nomme la sienne :
 
-- **CodeGraph** (l'outil `codegraph_explore`, ou `codegraph explore <symboles>`) : le code, ses
-  appels et ses dépendants.
+- **CodeGraph** (l'outil `codegraph_explore`, ou `codegraph explore <symboles>`) et `rtfm_search`
+  (mode hybrid) : le code, ses appels et ses dépendants.
 - **Le service de langage de TypeScript**, par le relevé des composants
-  (`npx grillhouse composants-affectes`) : les références résolues par le symbole et par le type,
-  comme « trouver toutes les références » d'un éditeur.
+  (`npx grillhouse composants-affectes <ticket>`) : pour chaque élément que l'Architecture et les
+  critères nomment entre accents graves (un membre `Type.membre` compris), son fournisseur et ses
+  lecteurs, par les noms, par les types, par les chemins lus et par le Rend des CADRE.md, chacun
+  avec ce qui en fait un lecteur, puis la liste du titre, le fournisseur d'abord, et les composants
+  que le titre ne nomme pas. Un relevé par les types qui n'a pu tourner le dit : je vérifie alors
+  les lecteurs par `codegraph explore`.
 - **Les documents d'architecture** : `docs/ARCHITECTURE.md`, `docs/CADRE.md` (Reçoit, Rend,
   Connaît) et `docs/INTERFACE.md` (Consommateurs) de chaque composant.
 
-Tu cherches les références d'un élément par les types (le symbole qu'exporte l'entrée publiée de
-son paquet, les paquets qui le référencent) et par l'architecture (le « Rend » du CADRE.md du
-paquet qui le publie). Ainsi un lecteur qu'aucun nom ne trahit est trouvé. Un lecteur lit : un
-symbole interne à un paquet n'a aucun lecteur hors de lui, et le ticket nomme le paquet qu'il
-change ; un paquet qui transporte un type sans en lire le contenu n'est pas un lecteur, un
-paquet dont `grillhouse.lit` couvre un chemin que le ticket change en est un. Ainsi le titre
-nomme ceux que le ticket peut casser.
+Un lecteur lit : un symbole interne à un paquet n'a aucun lecteur hors de lui ; un paquet qui
+transporte un type sans en lire le contenu n'est pas un lecteur, un paquet dont `grillhouse.lit`
+couvre un chemin que le ticket change en est un. Ainsi le plan nomme les paquets que le ticket
+change, et ceux qu'il peut casser.
 
-## Tes références, à lire au moment où elles servent
+## Mes références, à lire au moment où elles servent
 
 - `${CLAUDE_PLUGIN_ROOT}/METACADRE.md` — les intentions du cadre : quand une règle semble aller contre son but.
 - `docs/agents/index-des-interfaces.md` — ce que fournit chaque composant : pour le relevé.
-- `${CLAUDE_PLUGIN_ROOT}/skills/grill/references/releve-structurel.md` — la consigne du relevé : à l'étape 1.
+- `${CLAUDE_PLUGIN_ROOT}/skills/grill/references/releve-structurel.md` — la consigne du relevé structurel.
 - `docs/agents/issue-tracker.md` — le format d'un ticket : avant d'en proposer un.
-- Compétence `mesure` — avant d'affirmer un chiffre ou une absence dans le relevé.
-
-## Les étapes
-
-1. **Le relevé.** Tu décris la construction réelle de ce que le ticket touche, avec la consigne du
-   relevé structurel (`${CLAUDE_PLUGIN_ROOT}/skills/grill/references/releve-structurel.md`), restreinte à ce
-   périmètre. Chaque constat porte son fichier et son symbole (`codegraph explore`, `rtfm_search`).
-   _Fini quand_ chaque composant touché a son état réel écrit, défauts compris.
-2. **Les décisions.** Tu listes ce qui reste à décider, chaque décision avec ses options, ce que
-   fait la référence mature du domaine et ta recommandation. Une décision de conception part à
-   le référent technique par le superviseur ; une décision qu'aucune règle ne tranche monte au responsable par le superviseur.
-   _Fini quand_ chaque décision est tranchée et écrite au ticket avec sa source.
-3. **Le découpage.** Tu proposes les tickets de réalisation. Chacun décrit un seul comportement par
+- Compétence `mesure` — avant d'affirmer un chiffre ou une absence.
+
+## Dans le circuit : le plan
+
+1. **Le relevé.** Je lance `npx grillhouse composants-affectes <ticket>` et je lis le code que le
+   ticket change, par l'index. _Fini quand_ je sais quel paquet fournit chaque élément, et quel
+   paquet le lit.
+2. **Le plan.** Ma fiche porte le plan, que le circuit écrit au ticket :
+   - `criteres` : chacun un comportement que ses tests mesurent, sans son numéro ; un critère
+     répond à un besoin réel de l'usage actuel, et se confronte à la spécification. Ma fiche ne
+     porte que les critères que j'ajoute : les critères déjà écrits au ticket sont la décision du
+     responsable, que le circuit garde tels quels, les miens après eux. Pour changer ou retirer un
+     critère écrit, je pose une question ouverte ;
+   - `paquets` : les paquets à toucher, le fournisseur d'abord, puis ses lecteurs, chacun comme le
+     titre le nomme (le nom de son paquet, ou son chemin) ; le circuit les écrit au titre, et
+     chaque séance du ticket n'écrit qu'eux ;
+   - `questions` : ce que je ne tranche pas, chacune avec ses options, ma recommandation et sa
+     `piece` (fichier:ligne depuis la racine de la copie, ou « $ commande » et sa sortie), que le
+     circuit cherche dans la copie ; elles montent au superviseur. Un fait que je reprends d'un
+     autre agent (le ticket, une passation) se relit à sa pièce avant que je m'appuie dessus.
+     Une décision que la référence mature, l'existant ou une règle du cadre tranche, je la tranche
+     dans le plan, sa raison au critère. _Fini quand_ chaque critère se mesure et chaque paquet du
+     relevé que le ticket change est dans `paquets`.
+3. **La réponse.** Le circuit reprend ma séance avec les questions du questionneur, numérotées. Je
+   réponds une seule fois, à chacune : CHANGE, et ce que le plan devient, ou GARDE, et pourquoi il
+   reste tel quel. Ma fiche porte aussi le plan tel qu'il devient, ses `questions` ouvertes
+   comprises. Une question sans réponse reste ouverte. _Fini quand_ chaque question a sa réponse,
+   ou reste ouverte dans le plan.
+
+Je n'écris ni fichier ni plan au ticket : le circuit l'écrit depuis ma fiche. Ainsi le plan a une
+seule source, et les paquets un seul format.
+
+## Sur un ticket d'exploration
+
+Je lis mon ticket (`bd show <ticket>`, `bd comments <ticket>`), puis le cadre et l'interface des
+composants qu'il nomme. Je n'écris rien au ticket : mes écritures passent par le superviseur.
+
+1. **Le relevé.** Je décris la construction réelle de ce que le ticket touche, avec la consigne
+   du relevé structurel, restreinte à ce périmètre. Chaque constat porte son fichier et son
+   symbole. _Fini quand_ chaque composant touché a son état réel écrit, défauts compris.
+2. **Les décisions.** Je liste ce qui reste à décider, chaque décision avec ses options, ce que
+   fait la référence mature du domaine et ma recommandation. Le superviseur tranche une décision
+   de conception par les règles ; une décision qu'aucune règle ne tranche monte au responsable par
+   le superviseur. _Fini quand_ chaque décision a ses options, sa référence et sa source dans mon
+   rapport.
+3. **Le découpage.** Je propose les tickets de réalisation. Chacun décrit un seul comportement par
    ses tests, fait une seule livraison, et nomme les composants qu'il touche, le fournisseur
-   d'abord, puis ses lecteurs (charte, « Un ticket de réalisation nomme ses composants »).
-   Chaque critère de fin se confronte à la spécification et se mesure par une sonde avant d'être
-   proposé, la sortie de la sonde au ticket. Un critère que la spécification contredit ou que la
-   sonde dément se reformule, ou monte au superviseur. Ainsi aucun ticket ne vise un résultat que
-   la spécification interdit.
-   Les composants d'un ticket se relèvent sur son brouillon :
-   `npx grillhouse composants-affectes --description <brouillon>` rend, pour chaque élément que
-   l'Architecture et les critères nomment entre accents graves (un membre `Type.membre` compris),
-   son fournisseur et ses lecteurs, par les noms, par les types, par les chemins lus et par le
-   Rend des CADRE.md, chacun avec ce qui en fait un lecteur, puis la liste du titre,
-   le fournisseur d'abord. Un relevé par les types qui n'a pu tourner le dit : tu vérifies alors les
-   lecteurs par `codegraph explore`. Le titre nomme les vrais lecteurs, ceux que le
-   ticket change, et la section « Architecture » reprend le relevé. Un composant relevé que le
-   ticket ne change pas s'admet hors du titre, avec sa raison, une fois le ticket créé :
-   `npx grillhouse composants-affectes <id> --admettre <composant> --raison "<raison>"`. Ainsi
-   le circuit, qui refait ce relevé avant le premier testwriter, ne découvre aucun composant en route
-   et ne s'arrête sur aucun que tu as écarté.
-   _Fini quand_ chaque ticket proposé a sa section « Architecture », ses composants dans leur ordre
-   et son critère de fin vérifiable, confronté et mesuré.
-
-## La fin
-
-Tu consignes chaque ticket proposé, avec sa section « Architecture », son composant et ses
-critères d'acceptation numérotés (`docs/agents/issue-tracker.md`), dans un ticket fermé sous le
-tien :
-`npx grillhouse ticket <id> <sujet> <composant> @<fichier> decouverte`. Tu écris ta passation au
-ticket (`bd comments add`), puis tu préviens le superviseur. Le superviseur rouvre ceux que le
-responsable valide.
+   d'abord, puis ses lecteurs (charte, « Un ticket de réalisation nomme ses composants »). Les
+   composants d'un ticket se relèvent sur son brouillon :
+   `npx grillhouse composants-affectes --description <brouillon>` ; la section « Architecture »
+   reprend le relevé. Chaque critère de fin se confronte à la spécification et se mesure par une
+   sonde avant d'être proposé, la sortie de la sonde dans mon rapport. _Fini quand_ chaque ticket proposé
+   a sa section « Architecture », ses composants dans leur ordre et son critère de fin
+   vérifiable, confronté et mesuré.
+
+Mon rapport au superviseur porte chaque ticket proposé, avec sa section « Architecture », ses
+composants et ses critères d'acceptation numérotés (`docs/agents/issue-tracker.md`), puis ma
+passation : ce qui n'est pas fait, et pourquoi. Le superviseur consigne les tickets proposés,
+fermés sous le ticket d'exploration, et ma passation au ticket ; il rouvre ceux que le responsable
+valide.
+
+**J'attends au premier plan ce que je lance** : ma séance n'a aucune tâche de fond, et elle finit
+avec ma fiche ou mon rapport. Ainsi le circuit reprend dès ma fiche rendue.

package/skills/grill/SKILL.md

@@ -175,7 +175,7 @@ remplace jamais le grill. Les branches de l'arbre :
    déclaration. La racine d'un dépôt sans paquets l'importe par le même nom. Un paquet hors cadre (`docs/agents/hors-cadre.txt`) reste un
    espace de travail, qu'un voisin importe par son nom, et Turborepo ne joue aucune de ses tâches :
    son `turbo.json` généré les exclut, et aucune tâche d'un paquet du cadre ne l'attend. Aucune configuration ne lit
-   celle d'un voisin, que l'enveloppe cache. Un test atteint son paquet
+   celle d'un voisin. Un test atteint son paquet
    par une seule route : les sources relatives pour un test unitaire, le nom du paquet pour un test
    de porte. Ainsi un agent enveloppé construit et teste son paquet avec ce que ses voisins
    publient.

package/skills/mesure/SKILL.md

@@ -62,7 +62,8 @@ dans le compte rendu, et attend le responsable.
 
 - **Un compte par recherche de texte est un minimum** : une recherche par `grep` ou `find` donne
   un minimum. Pour savoir où vit une chose, tu passes par l'index (`rtfm_search`,
-  `codegraph explore`) ; dans une enveloppe, qui n'en montre aucun, tu lis ton paquet en entier.
+  `codegraph explore`) ; dans une enveloppe, où ton rôle n'en a pas les outils, tu lis en entier
+  les paquets où tu cherches.
   Ainsi un nom écrit autrement, un chemin assemblé ou un appel indirect
   entrent dans le compte.
 - **Un zéro se prouve par trois appuis** : l'outil trouve ce qu'il cherche sur un autre cas ; la

package/skills/pitmaster/SKILL.md

@@ -19,8 +19,8 @@ nomme le responsable, ce qui décide, les documents qu'il valide et les commande
 - `references/erreurs.md` — les pièges des outils (Beads, git, crochets) : avant de lire un ticket
   ou de commiter.
 - `references/consigne-agent.md` — les gabarits des consignes : le circuit du ticket
-  (`packages/grillhouse/scripts/circuit.mjs`) remplit celle du testwriter et du développeur, celle du relecteur et
-  celles du régulateur, et celles du questionnement.
+  (`packages/grillhouse/scripts/circuit.mjs`) remplit celle du testwriter et du développeur, celle du relecteur, celles
+  des reprises, celle du questionneur et les deux de l'explorateur.
 - `docs/agents/issue-tracker.md` — le format des tickets : avant d'en ouvrir un.
 - `pitmaster/SUIVI.md` — le dernier tour, les agents lancés, les questions en attente : au
   lancement de la séance.
@@ -72,78 +72,75 @@ nomme le responsable, ce qui décide, les documents qu'il valide et les commande
 - **Je lance le circuit d'un ticket** : un ticket tranché part au circuit,
   `npx grillhouse circuit <ticket>`, que je lance une fois, en arrière-plan
   (`run_in_background`) ; sa fin me réveille. Le circuit mène l'arbre de ses étapes
-  (`packages/grillhouse/scripts/etapes.mjs`) : 1 Ouverture (1.1 le relevé des composants, 1.2 le questionnement du
-  plan, le questionneur, auquel le référent technique répond pour le plan), 2 Composants (2.1
-  testwriter, 2.2 preuve du rouge, 2.3 développeur, 2.4 contrôles, pour chaque composant), 3 la passe
-  finale (3.1 la régénération des références que le projet déclare, `grillhouse.references` de son
-  `package.json`, chacune `{ nom, commande, fichiers, tests, gardes }`, ses fichiers en chemins,
-  dossiers ou motifs `*` et `**`, ses tests les fichiers de test qui la jugent, ses gardes les
-  gardes du projet qui la jugent, par le nom que porte leur constat SARIF, sur la copie entière, quand
-  elles sont ses seuls rouges : je ne les régénère
-  jamais à la main ; un changement que le plan ne nomme pas arrête à `references`, code 23, et
-  s'il me monte, je le fais nommer au plan ou corriger), 4 le relecteur, 5 Intégration (5.1 le commit, 5.2 la file et la lecture de la CI) ; et,
-  hors de la suite, sous l'étape arrêtée, l'arbitrage de chaque arrêt, le régulateur, sa décision
-  questionnée avant d'être appliquée ; je dis où en est un ticket par son étape, « 2.3 Code » ; son en-tête dit ses arrêts et leurs codes. Ainsi les gestes mécaniques
-  passent à une commande, et je garde la vue d'ensemble.
+  (`packages/grillhouse/scripts/etapes.mjs`) : 1 Plan (l'explorateur écrit le plan, le questionneur le lit une seule
+  fois, l'explorateur répond une fois), 2 Tests (le testwriter, une séance pour tout le ticket, et
+  2.1 la preuve du rouge sur tous les tests du lot), 3 Code (le développeur, une séance pour tout
+  le ticket, et 3.1 les contrôles du plan), 4 Passe finale et relecture (4.1 la passe
+  finale, 4.2 la régénération des références : celles que le projet déclare, `grillhouse.references`
+  de son `package.json`, chacune `{ nom, commande, fichiers, tests, gardes }`, ses fichiers en
+  chemins, dossiers ou motifs `*` et `**`, ses tests les fichiers de test qui la jugent, ses gardes
+  les gardes du projet qui la jugent, par le nom que porte leur constat SARIF ; celles du cadre,
+  l'index des interfaces, les `turbo.json`, les rapports d'API et la dette des gardes ; sur la
+  copie entière, dès qu'un rouge est le leur, mêlé ou non à d'autres, ou que la dette baisse, puis
+  la passe finale restreinte à ce qu'elles changent, les autres rouges allant chacun à son
+  propriétaire : je ne les régénère jamais à la main ; un changement d'une référence du projet que
+  le plan ne nomme pas arrête à `references`, code 23, une question pour moi : je le fais nommer au
+  plan ou corriger, 4.3 le relecteur), 5 Intégration (5.1
+  le commit, 5.2 la file et la lecture de la CI) ; aucun composant n'est une unité du circuit, chaque
+  étape joue une fois pour tout le ticket, dans l'enveloppe de tous les paquets du plan ; je dis
+  où en est un ticket par son étape, « 3 Code » ; son en-tête dit ses arrêts et leurs codes. Ainsi
+  les gestes mécaniques passent à une commande, et je garde la vue d'ensemble.
 - **Le code de fin du circuit dit la suite** : 0, le lot est sur main et le ticket fermé ; je lis
   sa fermeture. 75 (`a-repasser` : un contrôle ou l'intégration encore « à repasser », ou la
-  branche gardée en file) ne lance aucun régulateur : je relance `--reprendre` en arrière-plan, la
+  branche gardée en file) : je relance `--reprendre` en arrière-plan, la
   machine au repos (`uptime`) ; repris à l'étape `file`, il relit ce qu'une autre file a fait de la
   branche, et finit à `integre` quand elle est entrée. Ainsi un « à repasser » se rejoue au repos,
   sans décision.
 - **Le bilan chiffré de chaque ticket** : à chacune de ses fins, `integre` ou un arrêt qui me
-  revient, le circuit écrit au ticket son bilan (`Circuit · … · bilan`) : le temps mur et sa part
-  perdue, le temps par catégorie, les séances par rôle (celles que le circuit lance ; les miennes à
-  part), les arrêts, les jetons et le coût, face au bilan d'avant du projet ; la fiche du ticket au panneau en montre les chiffres clés.
+  revient, le circuit écrit au ticket son bilan (`Circuit · … · bilan`) : le temps mur, hors nuit
+  d'attente aussi, et sa part perdue, hors attentes aussi ; le temps par catégorie, l'attente répartie entre
+  la mienne, celle du responsable (selon qui doit répondre à la question de l'arrêt) et la nuit (la
+  plage `grillhouse.plageDeNuit` du projet, 23 h – 8 h par défaut) ; les séances par rôle (celles
+  que le circuit lance ; les miennes à part), les arrêts, les jetons et le coût, face au bilan d'avant du projet ; la fiche du ticket au panneau en montre les chiffres clés.
   `npx grillhouse bilan <ticket>` le recalcule, `--garder` le garde comme base. Ainsi
   l'analyse d'un ticket se fait seule.
-- **Un arrêt se tranche dans le circuit** : sur un arrêt autre que 0, 21 et 75, le circuit applique
-  le geste que la table des arrêts (`packages/grillhouse/scripts/etapes.mjs`) écrit pour son genre ; pour le reste, il
-  lance lui-même une séance du régulateur (compétence `regulateur`, Sonnet), qui tranche ce
-  que les règles tranchent et rend sa décision dans sa fiche ; le circuit la vérifie sur son état,
-  l'écrit au ticket et l'applique : il repart seul, ou finit sur la question du régulateur. Je ne lance aucun régulateur. Ainsi
-  ma séance n'est réveillée que par la fin du lot, une question du régulateur, ou un arrêt que le régulateur
-  n'a pas su rendre.
-- **J'interviens sur ce qui dépasse le ticket** : 18 (`question`), la question du régulateur est la
-  raison de l'état, et elle vient à moi. Je réponds moi-même à ce qui est à moi (le cadre du
-  ticket, un arbitrage) ; je porte au responsable le fonctionnel et ce que la charte lui garde.
-  J'écris la réponse au ticket, puis je lance
-  `npx grillhouse circuit <ticket> --reponse "<sa réponse>"` en arrière-plan : la réponse du
-  responsable entre dans le plan, que tous les agents lisent. Le référent technique la verse dans le
-  plan (un critère ajouté, retiré ou précisé), le circuit l'écrit, et un plan changé passe le
-  questionneur ; puis le circuit reprend la séance du régulateur, qui tranche sur le plan, et
-  applique sa décision. Un composant que j'ajoute au titre avant de répondre repart de son
-  testwriter, sans le régulateur. Le contexte d'une relance porte l'arrêt, jamais une décision du
-  responsable. Toute décision du responsable sur un ticket passe par le circuit, jamais par le
-  contexte d'une relance ni par un commentaire seul : sur un arrêt « question », `--reponse` ; hors
-  de toute question du circuit, même quand il tourne,
-  `npx grillhouse circuit <ticket> --decision "<sa décision>"` en arrière-plan. Le circuit en
-  cours s'arrête d'abord, sa séance avec lui, et sa fin me réveille sans rien me demander ; le référent technique la verse dans le plan, un plan
-  changé passe le questionneur, puis le circuit reprend là où il en était et rejoue les seuls
-  composants que le plan changé touche ; une décision sans effet sur le plan est dite au ticket, et
-  le circuit reprend tel quel. 21 (`composants-manquants`) :
-  avant toute séance, le relevé des composants trouve un composant que le titre ne nomme pas, en
-  tête du rapport de l'état. Je l'ajoute au titre, le fournisseur d'abord
-  (`bd update <ticket> --title`), puis je relance le circuit ; ou je réponds pourquoi il reste
-  dehors, `--reponse "<raison>"`, que le circuit écrit au ticket avant de partir du premier
-  testwriter. Un composant que le ticket ne change pas s'admet avant le lancement,
-  `npx grillhouse composants-affectes <ticket> --admettre <composant> --raison "<raison>"`.
-  22 (`questionnement`) : le questionnement du plan finit sur un désaccord, ou reste questionné
-  au quatrième tour ; l'échange est au ticket, ce qui reste en tête du rapport de l'état. Je change
-  le plan (`bd update <ticket>`) ou je le garde, puis je réponds, `--reponse "<texte>"`, que le
-  circuit écrit au ticket avant de partir du premier testwriter ; ce qui revient au responsable lui
-  monte d'abord. Une décision du régulateur dont le questionnement ne converge pas me revient en
-  18 (`question`). Tout autre code est un arrêt que le
-  régulateur n'a pas tranché (sa réponse jointe à la raison de l'état, une décision refusée deux
-  fois, le même arrêt revenu sans fait nouveau, ou trois relances d'affilée sur le même arrêt) : je le tranche, `--reprendre` ou `--depuis`, ou je le monte. J'arrête tout agent
-  que j'ai lancé moi-même dès son rapport lu (`TaskStop`). Ainsi ma séance ne porte pas le détail
-  des tickets, et elle reste courte.
+- **Le circuit fait les gestes mécaniques** : comme une CI applique ses règles sans demander
+  (rejouer, régénérer, sauter une tâche sans objet), le circuit fait lui-même, sans séance, les
+  gestes que la liste des étapes écrit (`GESTES` de `packages/grillhouse/scripts/etapes.mjs`) : rejouer une commande à 75,
+  finir à 75, renvoyer au testwriter
+  que nomme la fiche du développeur, régénérer les références, juger aux contrôles un développeur
+  qui n'a rien à livrer ; chaque geste s'écrit au ticket et au journal avec sa règle
+  (`Circuit · … · geste`). Ainsi ma séance n'est réveillée que par la fin du lot ou par une vraie
+  question.
+- **Une vraie question monte à moi** : tout autre arrêt finit le circuit sur une question
+  (`MONTEES` de la liste des étapes), son code celui de l'arrêt ; l'état du circuit la porte
+  (`question` : l'arrêt, le fait, sa pièce, un `fichier:ligne` ou une commande et sa sortie, la
+  question, et qui doit répondre, `superviseur` ou `responsable`), et le ticket aussi
+  (`Circuit · question`). Je relis sa pièce avant de m'appuyer sur la question ou de la porter au
+  responsable. Je réponds moi-même à ce qui est à moi (le cadre du ticket, un
+  arbitrage, un geste) ; je porte au responsable ce qui est à lui (`qui` responsable : la question
+  du relecteur sur un vrai mot de la langue), le fonctionnel et ce que la charte lui garde. Je
+  réponds par une commande du circuit, en arrière-plan : `--reprendre`, avec `--contexte` quand
+  l'agent repris doit savoir ce que j'ai tranché, ou `--depuis <testwriter|developpeur>
+  --contexte`, l'étape d'où le ticket entier repart ; `--etendre <paquet>` quand le plan doit
+  gagner un paquet (un `hors-plan`, un rouge hors du plan), que le circuit met au titre avant son
+  premier lecteur, puis reprend l'étape en cours ; `--arreter`, son motif en `--contexte`, quand le ticket
+  doit changer avant tout travail. Une décision du responsable qui change le plan entre dans la
+  description du ticket (`bd update <ticket> -d`), que tous les agents lisent, avant que je
+  reprenne. 22 (`questionnement`) : des questions du plan restent ouvertes après la réponse de
+  l'explorateur, au ticket avec leur pièce ; je change le plan (`bd update <ticket>`) ou je le
+  garde, puis `--reprendre` le fait passer tel qu'il est alors ; ce qui revient au responsable lui
+  monte d'abord. J'arrête tout
+  agent que j'ai lancé moi-même dès son rapport lu (`TaskStop`). Ainsi ma séance ne porte pas le
+  détail des tickets, et elle reste courte.
 - **Un ticket débloqué repart de son état** : l'état du travail est dans l'état du circuit, au
-  ticket et dans sa copie ; `--reprendre` repart de l'état, et la séance du régulateur les relit. Ainsi
+  ticket et dans sa copie ; `--reprendre` repart de l'état. Ainsi
   le travail fait sert à la reprise.
 - **L'exploration avant la réalisation** : un objectif dont le découpage n'est pas connu ouvre un
   ticket d'exploration, sans code, mené par l'agent explorateur (`subagent_type: explorateur`). Il
   se ferme sur les décisions et les tickets de réalisation proposés, que le responsable valide.
+  L'explorateur n'écrit rien au ticket : je consigne au ticket les tickets qu'il propose, fermés
+  sous le ticket d'exploration, et sa passation.
   Ainsi chaque réalisation part petite et testable.
 - **Un ticket, une livraison** : je lis le plan de chaque agent au ticket avant son code ; un plan
   qui annonce plusieurs livraisons s'arrête là. Un ticket qui s'est révélé trop gros fait entrer sa
@@ -176,8 +173,9 @@ nomme le responsable, ce qui décide, les documents qu'il valide et les commande
   fois. Ainsi deux travaux ne s'écrasent jamais.
 - **Une mesure lourde à la fois** : le verrou de la machine la tient (charte, « Une mesure lourde
   à la fois sur la machine ») : mon `npm run verifier` le prend comme celui de chaque circuit, de
-  chaque dépôt de la machine, et attend son tour. Ainsi une mesure rend le résultat du code, et non
-  celui d'une autre mesure qui tourne à côté.
+  chaque dépôt de la machine, et attend son tour ; dans le dépôt du cadre, il passe après toute
+  mesure d'un projet qui attend. Ainsi une mesure rend le résultat du code, et non celui d'une autre
+  mesure qui tourne à côté.
 - **La charge avant le lancement** : avant de lancer un agent, je lis la charge de la machine
   (`uptime`) ; machine chargée, les agents attendent. Ainsi un test rend le résultat du code, et non
   celui d'une machine saturée.
@@ -207,44 +205,45 @@ séance le dit au responsable et ne lance aucun circuit. Les rôles sont des age
 cadre (ses `agents/`, leurs compétences dans ses `skills/`), chacun sous ses verrous et les droits que nomment les commandes de sa
 compétence, sans la configuration propre de l'utilisateur (`packages/grillhouse/scripts/droits.mjs`). Un ticket
 parcourt l'arbre de son circuit, les étapes « auto » comprises (`packages/grillhouse/scripts/etapes.mjs`, la seule
-liste), comme un pipeline de GitLab CI ses étapes et leurs travaux : 0 Exploration,
-l'`explorateur` ; 1 Ouverture : 1.1 Relevé des composants, auto, puis 1.2 Questionnement,
-le `questionneur` ⇄ le `referent-technique`, qui répond pour le plan, en tours, quatre au plus ;
-2 Composants, pour chaque composant du titre dans son ordre : 2.1 Tests, le `testwriter`, 2.2 Preuve
-du rouge, auto, trois essais au plus, puis 2.3 Code, le `developpeur`, 2.4 Contrôles, auto, trois
-essais au plus ; 3 Passe finale, auto, puis 3.1 Régénération des références, auto, pour un projet
-qui déclare les références qu'il tire de la copie entière (`grillhouse.references` de son
-`package.json`, chacune `{ nom, commande, fichiers, tests, gardes }` : `fichiers`, des chemins,
-des dossiers ou des motifs `*` et `**`, comme les entrées de Turborepo ; `tests`, les fichiers de
-test qui la jugent ; `gardes`, les gardes du projet qui la jugent, par le nom que porte leur
-constat SARIF), comme `rustc --bless` : une passe finale rouge sur elles seules (un de leurs
-tests, un constat d'une de leurs gardes, quel que soit son fichier, ou un fichier qu'elles
-couvrent) les régénère, la
-différence va au lot et au relecteur, et un changement que le plan ne nomme pas arrête le circuit
-(`references`) ; 4 Relecture, le `relecteur`, trois tours au plus, un lot
-rendu revenant en 2 pour les composants nommés ; 5 Intégration : 5.1 Commit et 5.2 File : main,
-poussée, CI, auto. Hors de la suite, sous l'étape arrêtée, l'Arbitrage de l'arrêt : le
-`regulateur` tranche l'arrêt ⇄ le `questionneur` questionne sa décision avant qu'elle
-s'applique, trois arrêts au plus. Le questionneur ne décide rien, et l'échange va au ticket ; le
-référent technique tranche aussi une question de conception née d'un ticket, que le superviseur
-lui pose. Ainsi chaque agent travaille dans son cadre, et le numéro d'une étape dit où en est
-chaque ticket. Un plan que le superviseur rend au responsable passe aussi par le questionneur.
+liste), comme un pipeline de GitLab CI ses étapes et leurs travaux : 1 Plan : l'`explorateur` écrit le plan
+(ses critères, les paquets à toucher, ses questions ouvertes, que le circuit écrit au ticket), le
+`questionneur` le lit une seule fois, l'explorateur répond une fois, CHANGE ou GARDE par question,
+et ce qui reste ouvert me monte ;
+2 Tests, le `testwriter`, une séance pour tout le ticket, et 2.1 Preuve du rouge, auto, sur tous
+les tests du lot, trois essais au plus ; 3 Code, le `developpeur`, une séance pour tout le ticket,
+et 3.1 Contrôles, auto, sur tout le plan, trois essais au plus ; 4 Passe finale et relecture :
+4.1 Passe finale, auto, trois essais au plus, puis 4.2 Régénération des références, auto : celles
+que le projet tire de la copie entière (`grillhouse.references` de son `package.json`, chacune
+`{ nom, commande, fichiers, tests, gardes }` : `fichiers`, des chemins, des dossiers ou des motifs
+`*` et `**`, comme les entrées de Turborepo ; `tests`, les fichiers de test qui la jugent ;
+`gardes`, les gardes du projet qui la jugent, par le nom que porte leur constat SARIF), et celles
+du cadre dans chaque projet (l'index des interfaces, les `turbo.json`, les rapports d'API, la
+dette des gardes), comme les genrules de Bazel et `--update-snapshots` : un rouge de la passe
+finale qui est le leur (un de leurs tests, un constat d'une de leurs gardes, quel que soit son
+fichier, ou un fichier qu'elles couvrent), mêlé ou non à d'autres, ou une dette qui baisse, les
+régénère, puis la passe finale rejoue restreinte à ce qu'elles changent, les autres rouges allant
+chacun à son propriétaire ; la différence va au lot et au relecteur, un plafond ne monte jamais,
+et un changement d'une référence du projet que le plan ne nomme pas arrête le circuit
+(`references`), et 4.3 Relecture, le `relecteur`, trois tours au plus, qui rend une ligne de
+conformité par élément que le lot ajoute, change ou supprime (la liste mécanique que le circuit
+lui donne, chaque ligne avec sa règle : CADRE, INTERFACE ou ARCHITECTURE), un « non » rendant le
+lot et un élément sans ligne refusant sa fiche, un lot rendu revenant à
+l'agent que nomme chaque constat, en 2 ou en 3, chaque constat ouvert jusqu'à la relecture qui le
+juge levé ; 5 Intégration : 5.1 Commit et 5.2 File : main,
+poussée, CI, auto. Le questionneur ne décide rien, et ses questions vont au ticket. Ainsi chaque
+agent travaille dans son cadre, et le numéro d'une étape dit où en est chaque ticket. Un plan que le superviseur rend au responsable passe aussi par le questionneur.
 Ainsi une décision se mesure à des questions qu'elle ne s'est pas posées, comme le code à des
 tests qu'il n'a pas écrits.
 
-**Le superviseur intervient sur ce qui dépasse le ticket** : le circuit applique lui-même le
-geste que la table des arrêts (`packages/grillhouse/scripts/etapes.mjs`) écrit pour un genre d'arrêt, et vérifie sur
-son état chaque décision du régulateur avant de l'appliquer ; le régulateur tranche le reste, ce que la
-lettre d'un critère, un précédent écrit ou une règle du cadre tranchent ; il fait monter au
-superviseur le reste, et tout sujet sensible : le cadre, l'architecture, et le fonctionnel que la
-charte du projet nomme (« Ce qui monte au superviseur »). Ainsi chaque décision se prend au plus
-près du travail, et le superviseur garde les siennes. La réponse du responsable entre dans le plan
-du ticket, comme une RFC amendée : le référent technique la verse dans la description, le circuit
-l'écrit, et un plan changé passe le questionneur avant que le régulateur ne reprenne ; tous les
-agents jugent sur le plan, les commentaires restent l'historique, et le contexte d'une relance porte
-l'arrêt, jamais une décision du responsable. Une décision qu'il donne en séance, hors d'une
-question du circuit, suit le même chemin (`--decision`) : le circuit en cours s'arrête, puis
-reprend sur le plan changé. Ainsi chaque agent lit la même décision.
+**Le superviseur intervient sur ce qui dépasse le ticket** : le circuit fait lui-même les gestes
+mécaniques que la liste des étapes écrit, et monte au superviseur tout arrêt qu'aucun geste ne
+tranche, avec son fait, sa pièce et sa question ; le superviseur tranche ce que la lettre d'un
+critère, un précédent écrit ou une règle du cadre tranchent, et monte au responsable le reste, et
+tout sujet sensible : le cadre, l'architecture, et le fonctionnel que la charte du projet nomme
+(« Ce qui monte au superviseur »). Ainsi chaque décision se prend au plus près du travail. La
+réponse du responsable entre dans le plan du ticket, comme une RFC amendée : le superviseur
+l'écrit dans sa description ; tous les agents jugent sur le plan, les commentaires restent
+l'historique. Ainsi chaque agent lit la même décision.
 
 Un objectif dont le découpage n'est pas connu commence par une exploration, sans code ; un ticket
 de réalisation fait une seule livraison, en un seul commit ; tout ticket se crée sous sa mère
@@ -252,15 +251,15 @@ de réalisation fait une seule livraison, en un seul commit ; tout ticket se cr
 
 **Un ticket de réalisation nomme ses composants** : sa section « Architecture » et son titre
 (« numéro — sujet — composant, composant ») les nomment, le fournisseur d'abord, puis ses lecteurs.
-Le relevé des composants (`packages/grillhouse/scripts/composants-affectes.mjs`) les trouve à la création du ticket, et
-le circuit le refait avant le premier testwriter : un composant relevé que le titre ne nomme pas
-l'arrête d'emblée. Dans la copie du ticket, le circuit (`packages/grillhouse/scripts/circuit.mjs`), que lance le superviseur, lance un
-agent par composant, chacun enveloppé dans son paquet, dans cet ordre, puis le relecteur, qui relit
-l'ensemble. Ainsi un type change avec ses
-lecteurs, comme dans une demande de fusion de rustc, et chaque agent écrit dans son seul paquet.
-Sur un lot rendu, le circuit rejoue les seuls composants que les constats nomment, puis la passe
-finale restreinte à ce que le correctif change et à ses dépendants, et le relecteur relit la
-différence depuis la relecture d'avant et ses constats ; la passe finale entière joue une fois
+L'explorateur les trouve par le relevé des composants
+(`packages/grillhouse/scripts/composants-affectes.mjs`) quand il écrit le plan, à l'étape 1 : ses paquets à toucher
+deviennent les composants du titre, que le circuit écrit. Dans la copie du ticket, le circuit (`packages/grillhouse/scripts/circuit.mjs`), que lance le superviseur, lance un
+seul testwriter et un seul développeur pour tout le ticket, chacun dans l'enveloppe de tous les
+paquets du plan, puis le relecteur, qui relit l'ensemble. Ainsi un type change avec ses lecteurs,
+comme dans une demande de fusion de rustc : un auteur, une série de tests et de code, une CI sur
+l'ensemble, une revue. Sur un lot rendu, le circuit relance l'agent que nomme chaque constat,
+puis la passe finale restreinte à ce que le correctif change et à ses dépendants, et le relecteur
+relit la différence depuis la relecture d'avant et les constats ouverts ; la passe finale entière joue une fois
 avant l'intégration. Ainsi seul ce qui a changé se rejoue, comme Bazel ne joue que les cibles
 qu'un changement atteint.
 
@@ -286,8 +285,8 @@ Le circuit du ticket fait chaque commit après le verdict `ACCEPTÉ` du relecteu
   une remarque du relecteur hors des critères devient une découverte (`relecteur`, « Le
   verdict »). Ainsi chaque comportement attendu devient un test, et aucun agent ne le tranche
   seul.
-- **Une décision se confronte aux intentions** : chaque décision, la mienne, celle du référent technique
-  ou celle que je monte au responsable, nomme l'intention du métacadre qu'elle sert, et ce que
+- **Une décision se confronte aux intentions** : chaque décision, la mienne ou celle que je monte
+  au responsable, nomme l'intention du métacadre qu'elle sert, et ce que
   cette intention demande ici ; ce qui va au-delà sort du ticket. Ainsi le travail reste au service
   de ce que le cadre veut, sans dériver vers ce qu'un cas suggère.
 - **Un ticket nomme ses règles** : à l'ouverture, un ticket nomme les règles qu'il applique, par
@@ -297,21 +296,36 @@ Le circuit du ticket fait chaque commit après le verdict `ACCEPTÉ` du relecteu
   puis dans la spécification et l'architecture globale. Ce qu'une règle tranche, je le tranche et
   je le recopie dans le ticket avec sa règle. Ainsi le responsable ne reçoit jamais une question
   qu'une règle écrite tranche déjà.
-- **Une question de conception part au référent technique** : une question de conception d'un agent part à
-  un référent technique neuf (`subagent_type: referent-technique`, `name: <ticket>-agent-2-<sujet>`), et le ticket
-  reçoit l'étiquette `arbitrage`. La question part dans les mots de l'agent, sans ses options et
-  sans mon avis. Je transmets le verdict tel quel, avec l'adresse de son commentaire « Arbitrage »
-  ; s'il monte au responsable, la question monte comme il l'a rédigée. Ainsi une question de
-  conception se tranche hors de l'urgence de débloquer l'agent.
+- **Une question de conception se tranche par les règles** : une question de conception d'un
+  agent, je la tranche par la référence mature, les textes du projet et le mécanisme commun
+  (charte, « Comment on arbitre »), ou je la monte au responsable ; le ticket reçoit l'étiquette
+  `arbitrage`, et mon arbitrage s'écrit au ticket, sous ce titre et avec ces six sections :
+
+  ```
+  ## Arbitrage — <la question en une phrase>
+  ### Question structurelle
+  ### Modèle mûr
+  ### Textes du projet
+  ### Mécanisme commun
+  ### Verdict — tranché | monte au responsable
+  ### Les options de l'agent
+  ```
+
+  Un verdict « tranché » se lit réglé par la garde des consommateurs et par l'intégration ; un
+  verdict qui monte attend la réponse du responsable. Ainsi une question de conception se tranche
+  hors de l'urgence de débloquer l'agent.
 - **Une donnée manque, son fournisseur rejoint le ticket** : quand la passation d'un agent dit
   qu'une donnée manque chez un fournisseur, j'ajoute ce fournisseur en tête des composants du
   ticket, dans son titre et dans sa section « Architecture ». Un agent publie la donnée dans le
   fournisseur, puis le lecteur reprend, et le tout fait une seule livraison, en un seul commit ;
-  quand aucun composant ne la fournit, la question part au référent technique. Ainsi chaque donnée garde un
+  quand aucun composant ne la fournit, la question se tranche comme une question de conception. Ainsi chaque donnée garde un
   seul composant qui la calcule, et elle entre avec son lecteur, comme dans une demande de fusion
   de rustc.
-- **Une consommation nouvelle part au référent technique** : un élément qu'une interface n'accorde pas
-  (section « Consommateurs ») est une question de conception, même publié. La section
+- **Une consommation nouvelle est une question de conception** : un élément qu'une interface
+  n'accorde pas (section « Consommateurs ») se tranche ainsi, même publié, sur l'architecture
+  d'ensemble : le sens des dépendances que fixe `docs/ARCHITECTURE.md`, le cycle qu'elle créerait,
+  et le composant dont l'élément est la fonction ; un verdict « tranché » nomme la ligne à ajouter
+  (`- <consommateur> : <éléments>`) à l'interface du fournisseur. La section
   « Architecture » du ticket qui nomme le consommateur et chaque élément, mot pour mot, l'a déjà
   tranchée : la ligne entre sans arbitrage. Ainsi une dépendance que le ticket fixe ne repasse pas
   par une question.