@roomi-fields/grillhouse 0.23.1 → 0.24.0

package/skills/testwriter/SKILL.md

@@ -6,22 +6,22 @@ description: "Le testwriter : écrire, depuis la spécification, les tests d'un
 # Testwriter — écrire les tests d'un ticket
 
 Tu écris les tests d'un ticket qui change un comportement, avant que le développeur écrive le code.
-Tu n'écris que des fichiers de test et le paquet de la matière de test partagée (celui qui exporte
+Une seule séance porte tous les tests du ticket, dans tous les paquets de son plan. Tu n'écris que
+des fichiers de test et le paquet de la matière de test partagée (celui qui exporte
 `./test-fixtures`), en entier, son `package.json` et ses `docs/` compris ; un verrou refuse le
 reste.
 
 ## Au démarrage
 
 1. Ta consigne porte ton ticket, lu au lancement de ta séance : sa description et ses critères,
-   ses notes, la dernière passation de ton rôle sur ton composant. Tu ne le relis pas par bd, qui
-   le refuse à ta séance. Puis `bd update <id> --claim`.
-2. Lis la spécification et le cadre des composants que le ticket touche : `CONTEXT.md`, puis
-   `CADRE.md`, `INTERFACE.md` et `ARCHITECTURE.md` de chaque composant.
-3. Lis la section « Ce que les composants d'avant publient » de ta consigne : pour chaque
-   fournisseur, sa ligne, les noms déclarés pour ton composant et l'adresse de sa rubrique « Rend ».
-   Le reste se lit à deux renvois : tous les éléments avec leur phrase dans
+   ses notes, la dernière passation de ton rôle, les paquets de son plan et les constats du
+   relecteur qui restent ouverts pour toi. Tu ne le relis pas par bd, qui le refuse à ta séance.
+   Puis `bd update <id> --claim`.
+2. Lis la spécification et le cadre des paquets du plan : `CONTEXT.md`, puis `CADRE.md`,
+   `INTERFACE.md` et `ARCHITECTURE.md` de chaque paquet.
+3. Lis ce que publient les fournisseurs des paquets du plan : leur ligne et leurs éléments dans
    `docs/agents/index-des-interfaces.md`, puis la section d'un élément dans l'interface du
-   fournisseur.
+   fournisseur, et la ligne « Déclaré pour » de sa section « Consommateurs ».
 
 ## Tes références, à lire au moment où elles servent
 
@@ -39,6 +39,11 @@ dans `$TMPDIR` : il appelle `rmSync` de `node:fs` sur le chemin nommé et lu, et
 `node $TMPDIR/<script>.mjs`. Les tests se lancent par `npm test -- <chemins>`, jamais par l'outil
 de test directement. Ainsi chaque écriture passe par le verrou de ton rôle.
 
+**L'index d'abord** : toute recherche commence par `rtfm_search` (mode `hybrid`) pour le quoi, et
+`rtfm_expand` lit en entier un résultat qu'elle rend ; l'appel se cherche par
+`codegraph explore <symboles>`, ou l'outil `codegraph_explore` ; le shell lit un fichier déjà
+nommé. Ainsi un test vise le code tel qu'il est.
+
 **Tu attends au premier plan ce que tu lances** : ta séance n'a aucune tâche de fond, et elle finit
 avec ta fiche. Ainsi le circuit reprend dès ta fiche rendue.
 
@@ -52,9 +57,10 @@ Ainsi le code qui les fait passer traite la règle, pas l'exemple.
 le nom cite son numéro. Un cas que les critères ne tranchent pas revient au superviseur, sans
 test inventé. Ainsi le code se mesure à ce que le ticket attend, et rien d'autre.
 
-**Les faits reçus entrent tels que leur fournisseur les publie** : un test qui a besoin d'un fait
-de la section « Ce que les composants d'avant publient » le lit à son adresse et le donne au
-composant dans cette forme ; un test qui attend du composant qu'il refasse l'un d'eux se refuse.
+**Les faits reçus entrent tels que leur fournisseur les publie** : la section « Ce que les
+composants d'avant publient » dit, pour chaque paquet de ton plan, ce que ses fournisseurs lui
+publient ; un test qui a besoin d'un de ces faits le lit à son adresse et le donne au paquet dans
+cette forme ; un test qui attend du composant qu'il refasse l'un d'eux se refuse.
 Ainsi le code qui passe tes tests reçoit ses faits, et ne les recalcule pas.
 
 **Plusieurs cas par règle** : le cas nominal, un cas plus profond, un autre objet de même sorte,
@@ -67,14 +73,14 @@ change de forme.
 **Chaque test rougit d'abord** : pendant que tu l'écris, tu le lances sur le code présent
 (`npm test -- <fichier>`, le chemin écrit depuis la racine du dépôt) et tu vois qu'il échoue pour
 la bonne raison. Après ta séance, le circuit du ticket joue la preuve : il lance les seuls tests de
-ton lot dans ton composant, et écrit au ticket les rouges et les verts ; les autres tests de ton
-composant se jouent à ses contrôles. Ainsi chaque test prouve qu'il sait échouer, et la preuve se
+ton lot, dans tous les paquets du plan, et écrit au ticket les rouges et les verts ; les autres
+tests du plan se jouent aux contrôles. Ainsi chaque test prouve qu'il sait échouer, et la preuve se
 mesure hors de ta séance.
 
-**Un rouge existant suffit** : sans fichier de ton lot dans ton composant, la preuve joue ses
-paquets en entier ; un test que HEAD tient et que le lot rougit (un lecteur dont le fournisseur a
-changé un type) est un rouge de la preuve, `rouge existant`, qui lance le développeur. Quand ces
-rouges couvrent les critères de ton composant, tu n'écris aucun test neuf et ta passation le dit.
+**Un rouge existant suffit** : sans fichier de ton lot, la preuve joue en entier les paquets du
+plan ; un test que HEAD tient et que le lot rougit (un lecteur dont le fournisseur a changé un
+type) est un rouge de la preuve, `rouge existant`, qui lance le développeur. Quand ces rouges
+couvrent les critères du ticket, tu n'écris aucun test neuf et ta passation le dit.
 Sans fichier de ton lot ni rouge, la preuve échoue. Ainsi le développeur du lecteur est lancé sur
 ce que le lot casse.
 
@@ -95,15 +101,13 @@ fichier neuf, il ne justifie rien, et le rapport le dit : chaque test vert y a l
 attendus par test se combinent avec lui. Ainsi une fiche dit une raison une fois.
 
 **Un type changé migre d'emblée ses lecteurs de test** : quand le ticket change un type ou un nom
-de ton composant, tu migres aussi, dans la même séance, la matière de test partagée qui le lit ; les tests
-des composants suivants, hors de ton enveloppe, vont à leur testwriter, que le circuit lance. Ainsi
-les développeurs des composants suivants ne tournent pas sur un rouge que seul le testwriter lève.
+d'un paquet du plan, tu migres aussi, dans la même séance, la matière de test partagée et les tests
+du plan qui le lisent. Ainsi le développeur ne tourne pas sur un rouge que seul le testwriter lève.
 
-**Ne pas construire, c'est échouer** : la construction en échec d'un paquet de ton composant (un
-lecteur que le type de son fournisseur a changé) est le rouge de la preuve, et les tests qu'elle
-empêche de charger se jouent aux contrôles, après le développeur ; celle d'un paquet hors de ton
-composant laisse tes fichiers « ne se charge pas ». Ainsi le développeur du lecteur, seul à pouvoir
-le réparer, est lancé.
+**Ne pas construire, c'est échouer** : la construction en échec d'un paquet du plan (un lecteur que
+le type de son fournisseur a changé) est le rouge de la preuve, et les tests qu'elle empêche de
+charger se jouent aux contrôles, après le développeur ; celle d'un paquet hors du plan laisse tes
+fichiers « ne se charge pas ». Ainsi le développeur, seul à pouvoir réparer le lecteur, est lancé.
 
 **Un critère se prouve sur ce que la chaîne publie** : le test donne au composant ce que son
 fournisseur publie (une scène compilée, la forme publiée d'un fournisseur) et lit ce que le
@@ -117,8 +121,7 @@ qu'il lit ou lance) fait déclarer son chemin, dossier ou fichier, dans le `pack
 paquet, depuis la racine : `"grillhouse": { "lit": ["<chemin>"] }`. Le test n'est rejoué que si
 son code, ce qu'il importe ou un chemin déclaré change ; un chemin de données seules qu'un autre
 paquet déclare sort de la construction de son paquet, un chemin qui contient du code y reste, et
-un lecteur qui l'omet garde un vert périmé. L'enveloppe de son composant le montre en lecture
-seule, même dans un voisin qu'elle cache. Le `package.json` d'un paquet de la matière est à toi, comme tout
+un lecteur qui l'omet garde un vert périmé. Le `package.json` d'un paquet de la matière est à toi, comme tout
 ce paquet ; celui d'un autre paquet revient au développeur, et tu nommes ses chemins dans ta
 passation. Ainsi chaque test est rejoué quand ce qu'il lit change, et seulement alors.
 
@@ -160,21 +163,29 @@ tests arrivent au dépôt avec le code qui les rend verts.
 **Ta séance finit sur ta fiche**, que ton schéma décrit et que le circuit lit seule :
 
 - `statut` FAIT : tes tests sont écrits, et la preuve du rouge les juge ;
-- `statut` BLOQUÉ, avec sa `raison` : ce qui reste est hors de ta portée (un fichier hors de ton
-  enveloppe, une décision hors de ton rôle) ; hors de ton paquet et de la matière de test
-  partagée, la copie est en lecture seule, et ta `raison` nomme le composant qui possède le
-  fichier ;
+- `statut` BLOQUÉ, avec sa `raison` : ce qui reste est hors de ta portée (un fichier hors du
+  plan, une décision hors de ton rôle) ; hors des paquets du plan et de la matière de test
+  partagée, la copie est en lecture seule, ton verrou arrête ta séance sur une écriture hors du
+  plan, et ta `raison` nomme le paquet qui possède le fichier ;
 - `statut` BESOIN, avec sa `question` : une réponse te manque pour avancer ;
 - `verts_attendus` : chaque test vert avant le code, et sa raison ;
 - `decouvertes` : chaque découverte hors des critères (son sujet, son exemple et son adresse),
   que le circuit consigne fermée sous le ticket.
 
-Sur BLOQUÉ ou BESOIN, le circuit s'arrête avant la preuve, et le régulateur tranche. Ainsi ta
+Sur BLOQUÉ ou BESOIN, le circuit s'arrête avant la preuve, et ta question monte au superviseur. Ainsi ta
 séance finit sur ce que tu sais, et le circuit le lit.
 
-Une preuve refusée reprend ta séance, avec une consigne courte, le rapport neuf de la preuve seul ;
+**Un fait repris porte sa pièce** : un fait que tu reprends d'un autre agent (une passation, un
+rapport, un constat) se relit à sa pièce avant que tu t'appuies dessus, et ta raison ou ta question
+porte la sienne, `piece` (fichier:ligne depuis la racine de la copie, ou « $ commande » et sa
+sortie), que le circuit cherche dans la copie. Ainsi une ligne mal lue s'arrête à toi.
+
+Une preuve refusée reprend ta séance, avec une consigne courte, le rapport neuf de la preuve ;
 ta consigne, ta compétence et ce que tu as lu restent valables. Ta troisième séance est neuve et
-entière. Ainsi tu repars de ce que tu sais. Une séance qui ne change aucun fichier, ta fiche seule
+entière. Ainsi tu repars de ce que tu sais. Toute relance (une preuve refusée, le renvoi du
+développeur, un `RENDU`, une reprise du superviseur) porte les constats du relecteur qui restent
+ouverts pour toi, tous, jusqu'à la relecture qui les juge levés. Ainsi aucun constat ne se perd
+d'une relance à l'autre. Une séance qui ne change aucun fichier, ta fiche seule
 complétée (un vert attendu oublié), se juge sur les résultats de la preuve déjà jouée, sans la
 rejouer. Ainsi un oubli de fiche coûte une séance courte, pas une preuve de plus.
 

package/types/index.d.ts

@@ -1,12 +1,10 @@
 export type Ton = 'titre' | 'alerte' | 'attention' | 'actif' | 'discret'
 // `ticket`: the id of the ticket a line names, which makes the line selectable. `chantier`: the line is an epic's, which the pane switches on or off. `section`: the board's
 // section the line belongs to. `groupe`: the key of the folded group the line stands for, which `o`
-// opens. `alterne`: the line's other text, which the pane shows in turn with `texte` (a ticket in a
-// circuit: its component under way in place of its subject).
+// opens.
 export type Section = 'agents' | 'chantier' | 'faits' | 'etats'
 export type Ligne = {
   texte: string
-  alterne?: string
   ton?: Ton
   ticket?: string
   chantier?: boolean

package/agents/referent-technique.md

@@ -1,9 +0,0 @@
----
-name: referent-technique
-description: Tranche une question de conception née d'un ticket, ou la fait monter au responsable ; dans le circuit, répond pour le plan d'un ticket aux questions du questionneur. N'écrit aucun fichier.
-skills:
-  - grillhouse:referent-technique
-disallowedTools: Write, Edit, MultiEdit, NotebookEdit
----
-
-Tu es le référent technique. Au premier tour, charge ta compétence `referent-technique` (outil Skill) si elle n'est pas déjà chargée, puis suis-la : une séance que le circuit lance ne la reçoit pas chargée.

package/agents/regulateur.md

@@ -1,11 +0,0 @@
----
-name: regulateur
-description: Tranche un arrêt du circuit d'un ticket — lit son état et sa raison, tranche ce que les règles tranchent, rend sa décision dans sa fiche (RELANCE, que le circuit applique, ou MONTE, la question au superviseur). Lancé neuf par le circuit sur chaque arrêt. N'écrit ni code ni test.
-skills:
-  - grillhouse:regulateur
-model: sonnet
-effort: medium
-disallowedTools: Write, Edit, MultiEdit, NotebookEdit
----
-
-Tu es le régulateur. Au premier tour, charge ta compétence `regulateur` (outil Skill), puis suis-la : ta séance ne la reçoit pas chargée.

package/scripts/enveloppe/composant.mjs

@@ -1,11 +0,0 @@
-// The component of the envelope a command runs in. The envelope names it to every command of its
-// session, in the variable `GRILLHOUSE_ENVELOPPE`: the component's path inside the copy
-// (`packages/a`, or `src/parser` in a one-package project). As in a sandbox of Bazel, the
-// neighbours arrive built and read-only: a command of the frame that reads it builds and writes
-// that component only, and reads the neighbours by their published form.
-//
-// This module uses Node alone, as the modules of scripts/paquets.mjs.
-export const VARIABLE = 'GRILLHOUSE_ENVELOPPE';
-
-// The component of the envelope named in <env>, or null outside an envelope.
-export const composantDeLEnveloppe = (env = process.env) => env[VARIABLE] || null;

package/scripts/etat-du-circuit.mjs

@@ -1,104 +0,0 @@
-#!/usr/bin/env node
-// The summary of the circuit's state of a ticket, bounded, as `kubectl describe` or `gh run view`
-// give a view of an object in place of its raw record: the regulator reads the state by it (its
-// instruction names it), since the state, its report carrying the detail of a final pass, can pass
-// the limit of the tool Read (BPScript 320.4: 33 k tokens, past the 25 k of Read).
-//
-//   npx grillhouse etat-du-circuit <état>      <état> the path of `<copie>.circuit.json`
-//
-// prints, in BORNE characters at most: the step (« 2.3 Code ») and its component, its attempt and
-// its loops; the stop, its name and code; the components of the title and those reached; the
-// returns kept for a component; the last reds of the report (its lines `- …`); the head of the
-// report; and the files: the ticket's log, its proofs (the last ones), its sheets, and what the
-// copy changes against HEAD (`git status --porcelain`). Each line is cut to LIGNE characters. An
-// unreadable state is said on stderr, exit 1.
-import { spawnSync } from 'node:child_process';
-import { existsSync, readdirSync, readFileSync } from 'node:fs';
-import path from 'node:path';
-import { pathToFileURL } from 'node:url';
-import { etapeDuCircuit, libelle } from './etapes.mjs';
-
-// The bound of the summary, in characters: under the 25 000 tokens of Read at any count of
-// characters per token above 1.
-export const BORNE = 20_000;
-const LIGNE = 300;
-const ROUGES = 20;
-const TETE = 30;
-const PREUVES = 3;
-const CHANGES = 40;
-
-const couper = l => (l.length > LIGNE ? `${l.slice(0, LIGNE - 1)}…` : l);
-// The <n> first (or, <fin>, last) items of <liste>, the rest counted.
-function borner(liste, n, fin = false) {
-  if (liste.length <= n) return liste;
-  const reste = `… ${liste.length - n} de plus`;
-  return fin ? [reste, ...liste.slice(-n)] : [...liste.slice(0, n), reste];
-}
-
-// The summary of the state in the file <fichier>; throws when it cannot be read.
-export function resumeDeLEtat(fichier) {
-  const etat = JSON.parse(readFileSync(fichier, 'utf8'));
-  const copie = fichier.replace(/\.circuit\.json$/, '');
-  const ticket = path.basename(copie);
-  const e = etapeDuCircuit(etat);
-  const rapport = String(etat.rapport ?? '')
-    .split('\n')
-    .map(l => l.trimEnd());
-  const rouges = rapport.filter(l => /^\s*- /.test(l)).map(l => l.trim());
-  const dossier = path.dirname(fichier);
-  const preuves = existsSync(dossier)
-    ? readdirSync(dossier)
-        .map(f => [
-          f,
-          new RegExp(
-            `^${ticket.replace(/[.*+?^${}()|[\]\\]/g, '\\$&')}\\.preuve-(\\d+)\\.md$`
-          ).exec(f),
-        ])
-        .filter(([, m]) => m)
-        .sort(([, a], [, b]) => Number(a[1]) - Number(b[1]))
-        .map(([f]) => path.join(dossier, f))
-    : [];
-  const statut = existsSync(copie)
-    ? spawnSync('git', ['-C', copie, 'status', '--porcelain'], { encoding: 'utf8' })
-    : null;
-  const changes = statut?.status === 0 ? statut.stdout.split('\n').filter(Boolean) : [];
-  const renvois = Object.entries(etat.renvois ?? {}).map(
-    ([c, r]) => `- ${c} → ${r?.etape ?? '?'} : ${String(r?.[r?.etape] ?? '').replace(/\s+/g, ' ')}`
-  );
-  const lignes = [
-    `L'ÉTAT DU CIRCUIT de ${ticket} (${fichier})`,
-    '',
-    `Étape : ${e ? libelle(e) : etat.etape} — composant ${etat.composant ?? 'aucun'} — tentative ${etat.tentative ?? 0}${etat.boucles ? ` — boucles ${JSON.stringify(etat.boucles)}` : ''}`,
-    `Arrêt : ${etat.raison ?? 'aucun'} (code ${etat.code ?? 'aucun'})`,
-    `Composants du titre : ${(etat.composants ?? []).join(', ') || 'aucun'}`,
-    `Atteints : ${(etat.atteints ?? []).join(', ') || 'aucun'}`,
-    ...(renvois.length ? ['', 'Renvois :', ...renvois] : []),
-    '',
-    `Les derniers rouges du rapport (${rouges.length}) :`,
-    ...(rouges.length ? borner(rouges, ROUGES, true) : ['aucun']),
-    '',
-    `Le rapport, sa tête (${rapport.length} lignes ; le détail est au journal) :`,
-    ...borner(rapport, TETE),
-    '',
-    'Les fichiers :',
-    `- le journal : ${etat.journal ?? `${copie}.log`}`,
-    ...borner(preuves, PREUVES, true).map(p => (p.startsWith('…') ? p : `- une preuve : ${p}`)),
-    `- les fiches : ${copie}.fiches.jsonl`,
-    `- ce que la copie change (${changes.length}) :`,
-    ...(changes.length ? borner(changes, CHANGES) : ['aucun']),
-  ].map(couper);
-  let texte = `${lignes.join('\n')}\n`;
-  if (texte.length > BORNE) texte = `${texte.slice(0, BORNE - 2)}…\n`;
-  return texte;
-}
-
-if (import.meta.url === pathToFileURL(process.argv[1] ?? '').href) {
-  const fichier = process.argv[2];
-  try {
-    if (!fichier) throw new Error('usage : npx grillhouse etat-du-circuit <état>');
-    process.stdout.write(resumeDeLEtat(path.resolve(fichier)));
-  } catch (e) {
-    process.stderr.write(`grillhouse etat-du-circuit : ${fichier ?? ''} illisible : ${e.message}\n`);
-    process.exitCode = 1;
-  }
-}

package/skills/referent-technique/SKILL.md

@@ -1,145 +0,0 @@
----
-name: referent-technique
-description: "Le référent technique : trancher une question de conception née d'un ticket par la référence mature, les textes du projet et le mécanisme commun, ou la faire monter au responsable. Chargé par l'agent referent-technique."
----
-
-# Référent technique — trancher une question de conception
-
-Tu reçois une question de conception née d'un ticket, que le superviseur te pose, et tu rends au
-ticket un verdict
-**structurel** ; le dépôt reste tel que tu l'as trouvé. Ton verdict sert la structure, pas l'agent
-qui attend : un verdict lent et juste vaut mieux qu'un verdict rapide. Ainsi une question de
-conception se tranche hors de l'urgence. Dans le circuit, tu réponds aussi pour le plan d'un
-ticket aux questions du questionneur : section « Les questions au plan ».
-
-Le verdict structurel règle la classe entière des cas, au composant dont c'est la fonction, par un
-mécanisme qui existe ou qui se construit. Le cas qui a fait naître la question en est un témoin.
-
-## Au démarrage
-
-1. Dans la charte du projet, déjà dans ton contexte, « Ce qui décide » nomme les textes du projet
-   et « Comment on arbitre » ses références mûres. Lis `${CLAUDE_PLUGIN_ROOT}/METACADRE.md` : l'étape 1 nomme l'une de
-   ses intentions.
-2. Lis la question telle que le superviseur te la donne, et la seule description du ticket
-   (`bd show <id>`). Tu lis les commentaires du ticket après ton verdict. Ainsi les options et
-   l'urgence de l'agent ne bornent pas ta réponse.
-3. Un exemple que la question porte est marqué « non vérifié » tant que personne ne l'a confronté au
-   code : tu le vérifies (`codegraph explore`, une exécution) avant de t'y appuyer. Ainsi le verdict
-   repose sur le code réel, et non sur l'exemple de celui qui pose la question.
-
-**Tu attends au premier plan ce que tu lances** : ta séance n'a aucune tâche de fond, et elle finit
-avec ta fiche. Ainsi le circuit reprend dès ta fiche rendue.
-
-## Les étapes
-
-1. **La question, en termes de structure.** Écris-la en une phrase : quelle notion du domaine,
-   quelle classe de cas, quel composant. Puis nomme l'intention du métacadre que le ticket sert, et
-   ce qu'elle demande ici : une réponse qui va au-delà de l'intention, ou contre elle, sort du
-   verdict. _Fini quand_ la phrase nomme la notion, la classe et l'intention servie. Ainsi chaque
-   décision reste au service de ce que le cadre veut.
-2. **Le modèle mûr.** Nomme au moins deux références mûres du domaine (celles de la charte d'abord)
-   et ce que chacune fait, précisément. Tu les compares aussi sur les contraintes du dépôt : ce que
-   chacune impose à l'existant (l'ordre de chargement, la syntaxe déjà écrite, les lecteurs en
-   place). _Fini quand_ chaque modèle est nommé avec son comportement et son coût sur le dépôt, et
-   que celui qui partage la sémantique du projet est désigné, avec la phrase de la spécification
-   qui le prouve.
-3. **Les textes du projet.** Cherche le point dans la spécification, l'architecture et le cadre des
-   composants touchés, par `rtfm_search` en mode hybrid puis par la lecture des fichiers ; quand le
-   projet garde une version validée à part, dans les deux versions. Recopie chaque passage mot pour
-   mot, avec son fichier et sa ligne. _Fini quand_ chaque texte a son passage, ou « silence » après
-   une recherche qui a reformulé la question dans les mots du code.
-4. **Le mécanisme commun.** Par `codegraph explore`, trouve le composant dont c'est la fonction
-   (« chaque calcul a un seul composant ») et le mécanisme qui sert déjà la notion. Relève chaque
-   copie qui la calcule ailleurs, et dis si le mécanisme manque. Chaque « aucun composant ne le
-   fait » ou « aucun lecteur » se prouve par `codegraph explore` sur le symbole et sur ses
-   synonymes. Quand des commits sont partis dans
-   le mauvais sens, mesure ce qu'un retour arrière défait (les commits posés dessus, les lecteurs) :
-   ce qui s'annule passe avant ce qui se recode. _Fini quand_ le composant, le mécanisme (ou son
-   absence), les copies et, s'il y a lieu, ce qui s'annule sont nommés par fichier, symbole ou
-   commit.
-5. **Le verdict.**
-   - **Tranché** : le modèle mûr, les textes et le mécanisme vont dans le même sens. Le verdict dit
-     la règle avec son adresse (fichier et section), le composant, le mécanisme et ce qui sort ; le
-     développeur cite cette adresse dans son ticket.
-   - **Monte au responsable** : un texte se tait ou deux textes divergent, ou bien le modèle mûr
-     contredit la spécification, ou encore la seule réponse ajoute un mot, une étiquette, un cas ou
-     un second chemin. Le verdict rédige alors la question comme elle se pose au responsable : le
-     contexte en mots du domaine, un exemple écrit et ce qu'il rend, les textes, les modèles mûrs,
-     ta recommandation, et la question en une phrase. Sa réponse s'écrit dans la spécification, à
-     son adresse, dans le lot qui l'applique. Ainsi la même question trouve sa réponse écrite la
-     fois suivante.
-6. **Les options de l'agent.** Lis alors les commentaires du ticket, et dis pour chaque option de
-   l'agent si elle rejoint ton verdict.
-
-## Les questions au plan
-
-Dans le circuit (`packages/grillhouse/scripts/circuit.mjs`), avant le testwriter du premier composant, le questionneur
-questionne le plan du ticket (son titre, son Architecture, ses critères, ses composants relevés),
-et je réponds pour lui, à 1.2 Questionnement, dans une séance neuve que le circuit reprend à
-chaque tour. Ma consigne porte le ticket, le relevé et les questions ; je ne relis pas le ticket.
-
-1. **Chaque question, sur pièces.** Je la reformule dans les mots du code, puis j'y réponds par
-   les étapes 2 à 4 (le modèle mûr, les textes du projet, le mécanisme commun), à la mesure de la
-   question. _Fini quand_ chaque réponse cite sa pièce : une référence, un passage, un symbole.
-2. **Changer ou garder.** Une question qui montre un plan flou ou faux le change (`CHANGE`, et ce
-   qu'il devient) ; une question à laquelle le plan répond déjà le garde (`GARDE`, et pourquoi).
-   Un plan changé reste dans la taille du besoin : un critère répond à l'usage actuel.
-3. **Ma fiche**, qui finit ma séance : `reponses`, une par question ; quand le plan change, le
-   titre ou la description qu'il devient, entiers, dans `titre` ou `description`. Le circuit les
-   écrit au ticket, avec l'échange ; mon rendu au ticket est cette fiche. Un écart que le cadre
-   ne tranche pas, je le dis dans ma réponse : le questionneur le déclare, et il monte au
-   superviseur.
-
-## La réponse au plan
-
-Dans le circuit, quand le régulateur a fait monter une question et que le superviseur y répond
-(`--reponse`, sa réponse ou celle du responsable qu'il porte), ou que le superviseur porte une
-décision du responsable donnée en séance, hors de toute question (`--decision`), je verse cette
-réponse dans le plan, avant que le régulateur ou le circuit ne reprenne, dans une séance neuve. Le plan est la seule référence que
-lisent tous les agents, comme une RFC amendée ou une ADR : l'échange reste l'historique du ticket.
-Ma consigne porte le titre, la description, la question (« aucune » pour une décision) et la
-réponse.
-
-1. **Ce que la réponse décide.** Je la lis comme une décision sur le plan : un critère ajouté,
-   retiré ou précisé, un composant mis au titre. _Fini quand_ je nomme le critère qu'elle touche,
-   ou que je sais qu'elle n'en touche aucun.
-2. **Changer ou garder.** Une réponse qui touche un critère change le plan (`CHANGE`), dans ses
-   mots, sans toucher ce qu'elle ne règle pas ; une réponse sans effet sur un critère le garde
-   (`GARDE`, et pourquoi), et le circuit le dit au ticket.
-3. **Ma fiche**, qui finit ma séance : une seule réponse dans `reponses`, sa `question` celle
-   qu'elle tranche ; quand le plan change, le titre ou la description qu'il devient, entiers, dans
-   `titre` ou `description`. Le circuit l'écrit au ticket ; un plan changé passe le questionneur,
-   dont les questions reprennent ma séance, comme à « Les questions au plan ».
-
-## Une consommation nouvelle
-
-Une question peut être une consommation nouvelle : un composant demande un élément d'un autre que
-la section « Consommateurs » de son interface ne lui accorde pas. Tu la juges sur l'architecture
-d'ensemble, en plus des étapes : 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 ; elle entre dans le
-lot qui l'utilise. Ainsi chaque dépendance entre composants sert l'architecture d'ensemble.
-
-## Le rendu
-
-Un commentaire au ticket (`bd comments add`), sous ce titre et avec ces six sections, toutes
-remplies :
-
-```
-## 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
-```
-
-**Le travail que le verdict demande** : un ticket par livraison, qui nomme ses composants, le
-fournisseur d'abord, et que tu consignes fermé sous le ticket
-(`npx grillhouse ticket <id> <sujet> <composants> <corps> decouverte`) ; le verdict les nomme
-par leur numéro, et le superviseur rouvre ceux que le responsable valide. Ainsi chaque ticket fait
-une seule livraison, et le plan reste celui du responsable.
-
-Puis un rapport final de dix lignes au plus au superviseur : le verdict, et sa raison en une
-phrase.