@roomi-fields/grillhouse 0.23.1 → 0.24.0

package/.claude-plugin/plugin.json

@@ -5,5 +5,5 @@
   "author": {
     "name": "Romain Peyrichou"
   },
-  "version": "0.23.1"
+  "version": "0.24.0"
 }

package/METACADRE.md

@@ -21,7 +21,7 @@ intentions sort du cadre.
 5. **Des agents cadrés** : chaque ticket part à un agent neuf, dans le cadre écrit, et un autre que
    lui relit sa fermeture. Ainsi le travail des agents reste dans l'architecture ; sans cadre, ils
    font systématiquement le contraire.
-6. **Le responsable tranche l'essentiel** : ce qu'une règle écrite tranche, le régulateur ou
+6. **Le responsable tranche l'essentiel** : ce qu'une règle écrite tranche, le circuit ou
    le superviseur le tranche. Le responsable reçoit les décisions qu'aucune règle ne couvre, avec leur contexte et une
    recommandation. Ainsi son temps va aux vraies décisions.
 

package/agents/explorateur.md

@@ -1,9 +1,11 @@
 ---
 name: explorateur
-description: "Mène un ticket d'exploration : relève l'état réel, liste les décisions à prendre, propose les tickets de réalisation. N'écrit aucun fichier."
+description: "Écrit le plan d'un ticket à l'étape 1 de son circuit (ses critères, les paquets à toucher, ses questions ouvertes) et répond une fois au questionneur ; mène aussi un ticket d'exploration : relève l'état réel, liste les décisions à prendre, propose les tickets de réalisation. N'écrit aucun fichier ni rien au ticket."
 skills:
   - grillhouse:explorateur
+model: sonnet
+effort: medium
 disallowedTools: Write, Edit, MultiEdit, NotebookEdit
 ---
 
-Tu es l'explorateur. Ta compétence `explorateur` est chargée : suis-la.
+Tu es l'explorateur. Au premier tour, charge ta compétence `explorateur` (outil Skill), puis suis-la : ta séance ne la reçoit pas chargée.

package/agents/questionneur.md

@@ -1,6 +1,6 @@
 ---
 name: questionneur
-description: Questionne une proposition qu'il n'a pas écrite (le plan d'un ticket, une décision du régulateur, un plan du superviseur) là où elle lui paraît floue, à la lumière du cadre ; ne décide rien, ne propose pas sa solution, n'écrit aucun fichier ni rien au ticket.
+description: Questionne une proposition qu'il n'a pas écrite (le plan d'un ticket, un plan du superviseur) là où elle lui paraît floue, à la lumière du cadre ; ne décide rien, ne propose pas sa solution, n'écrit aucun fichier ni rien au ticket.
 skills:
   - grillhouse:questionneur
 model: sonnet

package/bin/grillhouse.mjs

@@ -9,10 +9,7 @@
 //   after it): no second Node starts, which a hook of Claude Code called at each tool pays. A `.sh`
 //   runs by bash, its standard streams this process's, its exit code this command's, and a script
 //   ended by a signal gives 128 plus the signal's number, as a shell gives it.
-// - A subcommand is named after its script, without directory nor extension (`verifier`,
-//   `circuit`, `tableau`); `maj` runs `grillhouse-maj.mjs`, whose name already says the frame's;
-//   `hooks` (`crochets.mjs`, which places the git hooks) and `hook` (`crochet.mjs`, which runs one)
-//   take Husky's names, which a project's `prepare` and its git hooks call.
+// - The subcommands and their scripts are the table of scripts/sous-commandes.mjs.
 // - A subcommand missing or unknown writes the usage and the list of the subcommands on the error
 //   stream, and the exit code is 2.
 // - A script finds its neighbours by its own directory, and the project by the working directory
@@ -20,60 +17,8 @@
 import { spawn } from 'node:child_process';
 import { realpathSync } from 'node:fs';
 import { constants } from 'node:os';
-import path from 'node:path';
-import { fileURLToPath, pathToFileURL } from 'node:url';
-
-const SCRIPTS = path.join(path.dirname(fileURLToPath(import.meta.url)), '..', 'scripts');
-
-// Each subcommand and its script, under `scripts/`.
-export const SOUS_COMMANDES = {
-  bilan: 'bilan.mjs',
-  circuit: 'circuit.mjs',
-  'code-mort': 'code-mort.mjs',
-  commande: 'verrous/commande.mjs',
-  'composants-affectes': 'composants-affectes.mjs',
-  consommateurs: 'consommateurs.mjs',
-  'consommateurs-arbitres': 'consommateurs-arbitres.mjs',
-  droits: 'droits.mjs',
-  enveloppe: 'enveloppe/enveloppe.mjs',
-  'etat-du-circuit': 'etat-du-circuit.mjs',
-  file: 'integration/file.mjs',
-  frontieres: 'frontieres.mjs',
-  'gardes-du-cadre': 'gardes-du-cadre.mjs',
-  greffons: 'greffons.mjs',
-  hook: 'crochet.mjs',
-  hooks: 'crochets.mjs',
-  'index-interfaces': 'index-interfaces.mjs',
-  init: 'init.mjs',
-  integrer: 'integration/integrer.mjs',
-  'interfaces-contre-code': 'interfaces-contre-code.mjs',
-  lancer: 'enveloppe/lancer.sh',
-  'ligne-etat': 'ligne-etat/ligne-etat.mjs',
-  maj: 'grillhouse-maj.mjs',
-  nuit: 'nuit.sh',
-  pression: 'vitest-config/pression.mjs',
-  registre: 'registre.mjs',
-  resultats: 'resultats.mjs',
-  resumes: 'resumes.mjs',
-  'retirer-copie': 'retirer-copie.sh',
-  'session-start': 'session-start.sh',
-  sortie: 'sortie.mjs',
-  'sous-modules': 'sous-modules.sh',
-  'structure-guard': 'structure-guard.sh',
-  superviseur: 'superviseur.mjs',
-  tableau: 'tableau.mjs',
-  tests: 'tests.mjs',
-  ticket: 'ticket.sh',
-  'ticket-du-sous-agent': 'verrous/ticket-du-sous-agent.mjs',
-  'turbo-des-paquets': 'turbo-des-paquets.mjs',
-  verifier: 'verifier.mjs',
-  verrou: 'verrous/verrou.mjs',
-};
-
-// The absolute path of the script of the subcommand <nom>; null for a name the table lacks.
-export function scriptDe(nom) {
-  return Object.hasOwn(SOUS_COMMANDES, nom) ? path.join(SCRIPTS, SOUS_COMMANDES[nom]) : null;
-}
+import { pathToFileURL } from 'node:url';
+import { scriptDe, SOUS_COMMANDES } from '../scripts/sous-commandes.mjs';
 
 // The usage and the list of the subcommands, as the error stream receives them.
 const usage = () =>

package/cadre/templates/projet/CLAUDE.md

@@ -31,7 +31,8 @@ d'abord », « une personne maintient le projet »…).
 
 ## Ce qui monte au superviseur
 
-Le fonctionnel que le régulateur ne tranche jamais seul : <le langage, le moteur audio, une
+Une question qu'aucun geste du circuit ne tranche monte au superviseur, avec sa pièce. Il monte au
+responsable le fonctionnel, qu'il ne tranche jamais seul : <le langage, le moteur audio, une
 interface publiée…>. Le cadre et l'architecture montent toujours (charte commune).
 
 ## Commandes
@@ -44,3 +45,6 @@ interface publiée…>. Le cadre et l'architecture montent toujours (charte comm
 - Les sous-modules partagés : la clé `grillhouse.partage` du `package.json` (les chemins des
   sous-modules qu'aucun ticket n'écrit ; chaque copie les lit dans le dépôt principal, en lecture
   seule, au lieu d'en recevoir un exemplaire).
+- La plage de nuit : la clé `grillhouse.plageDeNuit` du `package.json` (`{ "debut": 23, "fin": 8 }`
+  par défaut : les heures, à l'heure locale, où l'attente d'une réponse compte au bilan comme nuit,
+  à part de l'attente du superviseur et de celle du responsable).

package/cadre/templates/projet/docs/agents/issue-tracker.md

@@ -11,16 +11,16 @@ Issues for this repo live in Beads, a git-backed tracker: data under `.beads/`,
 - One ticket, one delivery: a goal whose split is unknown opens an exploration ticket (no code, agent `explorateur`), which closes on the realisation tickets it proposes, recorded closed and labelled `decouverte`; the supervisor reopens those the owner validates. A realisation ticket names the components it touches (« Numéros et titres ») and enters in one commit, under its own number alone; the `commit-msg` hook refuses a second commit for a closed ticket whose delivery stands, and lets a ticket reopened after its delivery (open in Beads) take correction commits; a revert (`Revert "…"`, `Reapply "…"`) passes and withdraws the delivery it names.
 - An open ticket is born of the owner's word, or of a direct need of a project that uses the frame (a defect it meets). A discovery during work is recorded, with its example and address, in a closed ticket under the ticket that found it, labelled `decouverte` (see « Numéros et titres »); it reopens on the owner's word. A discovery that blocks stops the agent, and its handoff names it. The supervisor brings to the owner the discoveries that touch a real use.
 - Types: `epic` (a chantier, always at the root: an epic has no mother), `task`, `bug`, `decision`. A mother under a chantier is a `task`; the session start lists an epic that has a mother. Priority `0`-`4`, 0 highest.
-- Comments carry progress and handoffs: `bd comments add <id> "<text>"`. In a ticket's circuit, each comment carries its author: the circuit launches each session with `BEADS_ACTOR` naming its role (`testwriter <composant>`, `developpeur <composant>`, `relecteur`, `regulateur`), writes its own lines (`Circuit · …`) as `circuit` and the reviewer's verdict as `relecteur`; the queue (`packages/grillhouse/scripts/integration/file.mjs`) writes as `file`; a verdict is a comment of the author `relecteur` whose first word is `ACCEPTÉ` or `RENDU`. An agent does not change its author: its rights refuse bd's `--actor`, `-a`/`--author` and the variable `BEADS_ACTOR`.
-- Labels used by the skills: `a-valider` (proposed, waits for the owner), `decouverte` (a discovery recorded closed; it reopens on the owner's word), `circuit` (the owner said to launch it: the ticket is in the flow, and only such a ticket waits in the pane's AGENTS), `attend-responsable` (a rule waits for the owner's word), `arbitrage` (a design question went to the `referent-technique` agent; the lot enters only with its verdict).
+- Comments carry progress and handoffs: `bd comments add <id> "<text>"`. In a ticket's circuit, each comment carries its author: the circuit launches each session with `BEADS_ACTOR` naming its role (`explorateur`, `questionneur`, `testwriter`, `developpeur`, `relecteur`), writes its own lines (`Circuit · …`) as `circuit` and the reviewer's verdict as `relecteur`; the queue (`packages/grillhouse/scripts/integration/file.mjs`) writes as `file`; a verdict is a comment of the author `relecteur` whose first word is `ACCEPTÉ` or `RENDU`. An agent does not change its author: its rights refuse bd's `--actor`, `-a`/`--author` and the variable `BEADS_ACTOR`.
+- Labels used by the skills: `a-valider` (proposed, waits for the owner), `decouverte` (a discovery recorded closed; it reopens on the owner's word), `circuit` (the owner said to launch it: the ticket is in the flow, and only such a ticket waits in the pane's AGENTS), `attend-responsable` (a rule waits for the owner's word), `arbitrage` (a design question the supervisor settles, his « ## Arbitrage » comment at the ticket; the lot enters only with its verdict).
 
 ## Numéros et titres
 
 - A chantier is an `epic` at the root; under it, every subject has a mother ticket (a `task`), open while work remains under it. Every ticket is created under its mother, so Beads numbers it natively: `320.1`, `320.2`, `320.2.1`.
-- The title reads `<number> — <subject> — <components>`, the number being the id without the whole prefix of the project (`bd config get issue_prefix`, which may hold dashes: `bp-mono-`). The components are the ones the ticket touches, separated by commas, the provider first, then its readers (charte, « Un ticket de réalisation nomme ses composants »): `320.5.2 — Publie l'objet de la scène — 020-loader, 050-emitter`. A mother takes `parent` as its component. The survey of the components (`npx grillhouse composants-affectes --description <file>` on a draft, `npx grillhouse composants-affectes <id>` on a ticket) gives that list from the elements the Architecture section and the criteria name: for each, its provider and its readers (the consumers its INTERFACE.md declares, the packages that import it, the tests of other packages that name it). A component it finds that the ticket does not change is admitted out of the title, with its reason, once the ticket exists: `npx grillhouse composants-affectes <id> --admettre <component> --raison "<reason>"`, a line at the ticket. The circuit runs the survey again before the first testwriter, and stops at `composants-manquants` (21) on a component it finds that the title misses and no admission covers.
+- The title reads `<number> — <subject> — <components>`, the number being the id without the whole prefix of the project (`bd config get issue_prefix`, which may hold dashes: `bp-mono-`). The components are the ones the ticket touches, separated by commas, the provider first, then its readers (charte, « Un ticket de réalisation nomme ses composants »): `320.5.2 — Publie l'objet de la scène — 020-loader, 050-emitter`. A mother takes `parent` as its component. The survey of the components (`npx grillhouse composants-affectes --description <file>` on a draft, `npx grillhouse composants-affectes <id>` on a ticket) gives that list from the elements the Architecture section and the criteria name: for each, its provider and its readers (the consumers its INTERFACE.md declares, the packages that import it, the tests of other packages that name it). The title names the readers the ticket changes. In a ticket's circuit, the explorer runs the survey when it writes the plan (1 Plan), and the circuit writes the packages of its plan as the title's components.
 - Creating one: `npx grillhouse ticket <mother> <subject> <components> <body> [label]` prints its id; the label is `a-valider` by default, and `decouverte` creates it closed (« découverte consignée »).
 
-- A ticket goes through the tree of its circuit, the « auto » steps included (`packages/grillhouse/scripts/etapes.mjs`, the one list): 0 Exploration (`explorateur`); 1 Ouverture: 1.1 Relevé des composants, 1.2 Questionnement (`questionneur` ⇄ `referent-technique`); 2 Composants, for each component: 2.1 Tests (`testwriter`), 2.2 Preuve du rouge, 2.3 Code (`developpeur`), 2.4 Contrôles; 3 Passe finale; 4 Relecture (`relecteur`); 5 Intégration: 5.1 Commit, 5.2 File : main, poussée, CI. Out of the sequence, under the stopped step, the Arbitrage de l'arrêt (`regulateur` ⇄ `questionneur`). The `referent-technique` also settles a design question the supervisor asks him. One says « 320.2.1, step 2.3 »; the pane shows each ticket at its step.
+- A ticket goes through the tree of its circuit, the « auto » steps included (`packages/grillhouse/scripts/etapes.mjs`, the one list): 1 Plan (`explorateur` writes the plan, `questionneur` reads it once, the explorer answers once); 2 Tests (`testwriter`), 2.1 Preuve du rouge; 3 Code (`developpeur`), 3.1 Contrôles; 4 Passe finale et relecture: 4.1 Passe finale, 4.2 Régénération des références, 4.3 Relecture (`relecteur`); 5 Intégration: 5.1 Commit, 5.2 File : main, poussée, CI. Every step is one for the whole ticket: one testwriter and one developpeur, each on every package of its plan. The circuit makes its mechanical gestures itself; any other stop goes up to the supervisor, its question in the circuit's state. One says « 320.2.1, step 3 »; the pane shows each ticket at its step.
 
 ## When a skill says "publish to the issue tracker"
 

package/charte.md

@@ -29,7 +29,9 @@ professionnel.
    le correctif va dans ce mécanisme. Ainsi tout correctif passe par l'architecture.
 3. Une décision reste à prendre : `mattpocock-skills:grilling` avant d'écrire, ses questions dans
    le ticket. Ainsi la décision est prise et écrite avant le code.
-4. Le plan va dans le ticket (`bd update <id> -d`). Un travail qui change un comportement est un
+4. Le plan va dans le ticket : dans le circuit, l'explorateur l'écrit (ses critères, les paquets à
+   toucher, ses questions ouvertes), le questionneur le lit une fois, l'explorateur répond une
+   fois, et ce qui reste ouvert monte au superviseur. Un travail qui change un comportement est un
    seul ticket : les tests d'abord (agent `testwriter`), puis le code qui les rend verts (agent
    `developpeur`). Ainsi le code se mesure à des tests qu'il n'a pas écrits. Un critère répond à
    un besoin réel de l'usage actuel. Ainsi le ticket garde la taille du besoin.
@@ -42,13 +44,26 @@ professionnel.
    la fiche le circuit.
 
 Un ticket parcourt les étapes de son circuit (`etapes.mjs`, la seule liste), chacune tenue par un
-rôle, agent du cadre, sous ses droits. Ainsi chaque agent travaille dans son cadre, et le numéro
-d'une étape dit où en est chaque ticket.
+rôle, agent du cadre, sous ses droits : 1 Plan, l'explorateur puis le questionneur ; 2 Tests, une
+séance du testwriter, et 2.1 Preuve du rouge ; 3 Code, une séance du développeur, et
+3.1 Contrôles ; 4 Passe finale et relecture : la passe finale, la régénération des références,
+puis le relecteur, qui rend une ligne de conformité par élément que le lot ajoute, change ou
+supprime ; 5 Intégration. Ainsi chaque agent travaille dans son cadre,
+et le numéro d'une étape dit où en est chaque ticket.
+
+**Le circuit fait les gestes, une vraie question monte** : le circuit fait lui-même les gestes
+mécaniques que la liste des étapes écrit (rejouer, régénérer, juger un lot sans rien à livrer) ;
+tout autre arrêt monte au superviseur avec sa pièce, et il monte au responsable ce qui lui
+revient. Ainsi aucune séance ne juge ce qu'une règle tranche.
 
 **Tous les agents jugent sur le plan** : une décision du responsable entre dans la description du
 ticket, comme une RFC amendée ; les commentaires restent l'historique. Ainsi chaque agent lit la
 même décision.
 
+**Un fait repris se relit à sa pièce** (fichier:ligne depuis la racine de la copie, ou
+« $ commande » et sa sortie) avant qu'un agent s'appuie dessus, et un fait transmis porte la
+sienne. Ainsi une ligne mal lue s'arrête au premier qui la relit.
+
 **Un ticket de réalisation nomme ses composants** dans son titre (« numéro — sujet — composant,
 composant ») et sa section « Architecture », le fournisseur d'abord ; il fait une seule livraison,
 en un seul commit, et se crée sous sa mère (`docs/agents/issue-tracker.md`). Un objectif dont le
@@ -98,9 +113,11 @@ Une découverte d'agent se consigne dans un ticket fermé, sous le ticket qui l'
   Ainsi chaque rouge a son ticket.
 - **L'index d'abord** : toute recherche commence par `rtfm_search` (mode `hybrid`) pour le quoi, et
   par `codegraph explore` (ou l'outil `codegraph_explore`) pour l'appel ; le shell lit un fichier
-  déjà nommé. Dans son enveloppe, un agent lit son paquet, les interfaces de ses voisins, la
-  matière de test partagée et ce que ses tests déclarent lire (`grillhouse.lit`). Ainsi une
-  affirmation sur le code repose sur ce que le code contient.
+  déjà nommé. Ainsi une affirmation sur le code repose sur ce que le code contient.
+- **Tout se lit, le plan s'écrit** : dans son enveloppe, un agent lit tout le dépôt, index compris,
+  et n'écrit que les paquets que le plan de son ticket nomme. Une écriture hors du plan l'arrête,
+  et le superviseur étend le plan ou refuse. Ainsi l'agent lit ce dont il a besoin, et les gardes
+  tiennent l'architecture.
 - Tickets : Beads (`bd`), sous le préfixe du projet, voir `docs/agents/issue-tracker.md`.
 - Le greffon `mattpocock-skills` s'appelle avec son préfixe ; un document pour un agent s'écrit
   avec `mattpocock-skills:writing-for-agents`.

package/docs/ARCHITECTURE.md

@@ -29,6 +29,112 @@ chemin que ses tests déclarent lire, `grillhouse.lit`) ; sans vert connu, la pa
 complète, et `npm run verifier -- --tout` la joue pour de vrai, comme la nuit. Ainsi un test ne
 tourne qu'une fois tant que rien ne change, et corriger un test ne rejoue que lui.
 
+**Tout se lit, le plan s'écrit** : un agent de rôle travaille dans l'enveloppe de sa copie
+(`packages/grillhouse/scripts/enveloppe/`, un bac à sable bubblewrap) ; il lit toute la copie,
+index compris (`.codegraph`, `.rtfm`), et n'écrit que les paquets que le plan de son ticket nomme
+(les paquets du titre), la base des tickets et le cache de Turborepo ; `.git` reste en lecture
+seule, et la matière de test partagée s'écrit par le seul testwriter. Un chemin du plan hors des
+paquets écrit la racine, toute la copie. `GRILLHOUSE_ENVELOPPE` porte la liste aux commandes du
+cadre, qui construisent, jugent et écrivent ses seuls paquets. Une écriture hors du plan échoue
+au montage, et le verrou de l'agent arrête sa séance en nommant le paquet ; le circuit s'arrête à
+« hors-plan », une question pour le superviseur, qui étend le plan (`--etendre`) ou refuse. Comme la visibilité de Bazel et
+les frontières de modules de Nx, la règle refuse et le code reste lisible ; comme
+`bwrap --ro-bind / --bind`, le bac à sable n'ouvre en écriture que ce qu'il lie. Ainsi l'agent
+lit ce dont il a besoin, et les gardes tiennent l'architecture (BP 320.9 : la lecture cloisonnée
+causait l'essentiel des pertes).
+
+**Le circuit fait les gestes, une vraie question monte** : comme une CI applique ses règles
+(rejouer, régénérer, sauter une tâche sans objet) sans demander et n'appelle une personne que pour
+ce qu'aucune règle ne tranche (l'approbation d'une revue), le circuit d'un ticket
+(`packages/grillhouse/scripts/circuit.mjs`) fait lui-même, sans séance, les gestes que la liste des
+étapes écrit (`GESTES` de `packages/grillhouse/scripts/etapes.mjs`) : une commande à 75 rejouée une
+fois, la fin à 75, le renvoi au testwriter que la fiche du développeur nomme, la régénération des
+références, un développeur sans rien à livrer jugé par les contrôles ; chaque geste s'écrit au ticket et au
+journal avec sa règle. Tout autre arrêt finit le circuit sur une question au superviseur (`MONTEES`),
+que l'état du circuit porte : le fait, sa pièce (`fichier:ligne`, ou la commande et sa sortie), la
+question, et qui doit répondre, le superviseur ou le responsable ; le superviseur répond par une
+commande du circuit (`--reprendre`, `--depuis`, `--etendre <paquet>`, `--arreter`). Ainsi aucune
+séance ne juge un geste qu'une règle tranche (BP 320.9 : 67 séances d'arbitrage et de réponse
+au plan, 14 montées qui étaient des gestes).
+
+**La régénération d'office** : comme les genrules de Bazel et `--update-snapshots`, un fichier
+engendré se réécrit par sa commande, puis le circuit rejoue seulement ce qui en dépend. Une passe
+finale dont un rouge est celui d'une référence, mêlé ou non à d'autres, régénère les références
+qu'il nomme (4.2), puis rejoue la passe finale restreinte à ce que la régénération change ; les
+autres rouges restent, chacun à son propriétaire. Les références sont celles que le projet déclare
+(`grillhouse.references`) et celles du cadre, dans chaque projet (`REFERENCES_DU_CADRE` de
+`circuit.mjs`) : l'index des interfaces, les `turbo.json` des paquets et les rapports d'API, chacun
+réécrit par son générateur sans que le plan le nomme, et la dette des gardes. Le circuit ne lit pas
+le code de sortie d'un générateur du cadre, qui juge aussi les rouges qu'il laisse (`npm run api`
+refuse à côté d'eux) : il juge la régénération sur ce qu'elle écrit, puis sur la passe restreinte
+qui suit, et seule une vraie panne l'arrête (la commande introuvable, ou tuée par un signal). La dette s'abaisse depuis les notes de la passe finale (une note
+`a-elaguer` du SARIF d'une garde, chaque clé inscrite au-dessus de ce qu'elle trouve), par
+`dette.mjs --abaisser`, sans rejouer les gardes. Un plafond ne monte jamais : un lot qui le dépasse
+reste rouge. Ainsi aucun fichier engendré n'attend une main (BP 320.9 : 292 min autour des
+références, dont 163 d'attente).
+
+**L'explorateur écrit le plan, questionné une fois** : comme l'auteur d'une RFC l'écrit après
+avoir relevé l'existant, qu'une revue la lit une fois, que l'auteur répond une fois et que ce qui
+reste ouvert va à qui décide, l'étape 1 du circuit (1 Plan) lance l'explorateur hors de
+l'enveloppe ; il relève les composants (`npx grillhouse composants-affectes <ticket>`) et finit sur
+sa fiche : les critères, les paquets à toucher, ses questions ouvertes avec leur pièce. Le circuit
+écrit le plan au ticket : les paquets finissent son titre, la seule liste que lit l'enveloppe de
+chaque séance d'après. Le questionneur le lit une fois ; l'explorateur, sa séance
+reprise, répond une fois, CHANGE ou GARDE par question ; ce qui reste ouvert monte au superviseur
+(« questionnement »), sinon le circuit passe aux tests. Ainsi les questions utiles se posent avant
+le plan, et le plan ne tourne pas en rond (BP 320.9 : 132 tours de questions, 29 critères dont 2
+utiles).
+
+**Le relecteur juge chaque élément qui change** : comme API Extractor fait relire son rapport
+ligne par ligne et qu'une revue mûre exige un avis par fichier changé, le circuit donne au
+relecteur la liste de chaque fonction, classe, type, interface, constante de tête et export que
+le lot ajoute, change ou supprime (`scripts/elements-du-lot.mjs`), avec son paquet, son
+`fichier:ligne` et s'il est exporté : le service de langage de `references-par-les-types.mjs` lit
+les déclarations et les exports, le texte de chaque déclaration avant et après le lot dit ce qui
+change, le diff des rapports d'API (`docs/INTERFACE.api.md`) les exports qui changent. Sa fiche
+rend une ligne par élément (`conformite`), conforme ou non, la règle citée (`document` CADRE,
+INTERFACE ou ARCHITECTURE, et sa `reference`) ; un export neuf cite son entrée dans l'INTERFACE.
+Le schéma de la fiche refuse une ligne sans document ni référence (`resultats.mjs`), et le
+circuit une fiche à laquelle il manque un élément (`conformiteDuLot`) ; un « non » rend le lot à
+son destinataire. En relecture bornée, comme une revue ne décoche « vu » que sur les fichiers
+changés depuis, la consigne marque chaque élément : à rejuger quand la différence le touche,
+repris sinon avec sa ligne d'avant, que la fiche porte encore. Ainsi rien de neuf n'entre sans
+avoir été jugé contre l'architecture (Romain, 2026-10-23 : « il faut que le relecteur valide
+vraiment la conformité à l'architecture de tout ce qu'il y a de nouveau/changé »).
+
+**Un circuit par ticket** : comme une demande de fusion (un auteur, une série de tests et de
+code, une CI sur l'ensemble, une revue), le circuit lance un seul testwriter et un seul
+développeur pour tout le ticket, chacun dans l'enveloppe de tous les paquets du plan, puis la
+passe finale et le relecteur sur l'ensemble ; aucun composant n'est une unité du circuit. Les
+étapes (`packages/grillhouse/scripts/etapes.mjs`) : 1 Plan · 2 Tests · 2.1 Preuve du rouge ·
+3 Code · 3.1 Contrôles · 4 Passe finale et relecture (4.1 Passe finale, 4.2 Régénération des
+références, 4.3 Relecture) · 5 Intégration. `--depuis <testwriter|developpeur>` rejoue le
+ticket entier depuis cette étape ; `--etendre <paquet>` ajoute un paquet au plan, puis reprend
+l'étape en cours. Un constat bloquant du relecteur va droit à l'agent qu'il nomme et reste ouvert
+d'une relance à l'autre, comme un fil de revue non résolu, jusqu'à ce que le relecteur le dise
+levé ou accepte le lot. Le bilan compte par étape et par rôle. Ainsi un type change avec ses
+lecteurs en une seule séance, et un constat n'est jamais perdu (BP 320.9 : seize composants
+joués l'un après l'autre, 118 min d'étapes vertes rejouées, un constat sur `exemplar` perdu six
+fois).
+
+**Le bilan sépare les attentes** : comme le « lead time » de DORA sépare l'attente de revue du
+temps de travail, chaque montée dit qui doit répondre, et le bilan répartit l'attente entre celle
+du superviseur, celle du responsable et la nuit, la plage horaire que le projet déclare
+(`grillhouse.plageDeNuit` de son `package.json`, 23 h – 8 h par défaut). Son texte donne le mur,
+le mur hors nuit d'attente (une nuit de travail y reste) et le perdu hors attentes. Ainsi le temps perdu se lit sans la nuit ni l'attente
+d'une réponse (BP 320.9 : 500 min de nuit mêlées à l'attente du responsable et à celle du
+superviseur).
+
+**Un fait porte sa pièce** : comme une revue de code cite la ligne qu'elle juge, chaque constat,
+question ou montée d'une fiche porte sa `piece`, un seul format (`lirePiece` de `resultats.mjs`) :
+`fichier:ligne` ou `fichier:ligne-ligne` depuis la racine de la copie, ou `$ commande` et sa
+sortie. Le circuit cherche chaque pièce `fichier:ligne` dans la copie, le fichier présent et sa
+ligne (ou la fin de l'intervalle) dedans ; une pièce
+introuvable refuse la fiche, redemandée une fois comme tout autre manque. L'agent qui reprend le
+fait relit sa pièce avant de s'appuyer dessus. Ainsi une ligne mal lue s'arrête au premier qui la
+relit (BP 320.9 : une question née d'une ligne mal lue, `native.ts:234`, recopiée par cinq agents
+jusqu'au responsable).
+
 **Une passe écrit sous sa base** : chaque lancement de Vitest, `npm test`, `npm run verifier`,
 un circuit, une intégration et une enveloppe ouvrent leur base dans le dossier temporaire, la
 nomment dans `TMPDIR` à ce qu'ils lancent (les dossiers d'essai des tests, celui de Vitest, celui
@@ -60,6 +166,13 @@ celui qui attend est un blocage : l'attente le dit tout de suite et s'arrête, r
 borne ses tâches côte à côte à la moitié des cœurs. Ainsi une mesure rend le résultat du code, et
 non celui d'une autre mesure à côté, et aucune passe ne reste figée sans le dire.
 
+**Le projet passe avant le cadre** : une mesure jouée dans le dépôt du cadre lui-même (le paquet
+en développement, ses copies d'agents comprises) est de second rang ; celle d'un projet, de
+premier rang. Une mesure de second rang ne prend pas le verrou, même libre, tant qu'une mesure de
+premier rang attend ; l'attente dit son rang et qui elle attend, sous la même borne. Ainsi le
+circuit d'un projet n'attend pas les vérifications du cadre, comme le serveur de tâches de GNU
+make sert sa construction et Bazel ordonne ses tests par priorité.
+
 **Une passe automatique montre son avancement** : chaque passe automatique écrit ses fichiers
 de tests faits sur prévus (la file, les étapes de sa CI), que le panneau affiche avec le temps
 depuis son dernier signe, « ⚠ figée » au-delà de 5 min, comme le compteur d'actions de Bazel.
@@ -83,8 +196,21 @@ comme un paquet d'ESLint porte son greffon. La place de marché `roomi-fields`
 `grillhouse@roomi-fields` (`npx grillhouse maj`). Ce qui est propre à un projet (sa charte, ses
 réglages, sa version du paquet) vit dans le projet, jamais dans ce qui se publie. Une version de
 npm vaut pour les deux ; l'ouverture de séance nomme un greffon chargé à une autre version que
-le paquet du projet, avec la commande qui les remet d'accord. Un projet n'en garde aucune copie ; sans le paquet installé, l'ouverture de séance dit « lance `npm install` », et les autres crochets
+le paquet du projet, avec la commande qui les remet d'accord. Un projet n'en garde aucune copie
+(`npx grillhouse maj` retire, à leur empreinte, celles que posait la 0.22) ; sans le paquet installé, l'ouverture de séance dit « lance `npm install` », et les autres crochets
 sortent sans effet. Les crochets git du cadre suivent le modèle de Husky : le `prepare` du
 projet lance `grillhouse hooks`, qui les pose à côté des sections de Beads, et chacun appelle
 `grillhouse hook <nom>`, sans effet sans le paquet. Ainsi chaque projet suit la version du cadre qu'il installe, sans fichier à
 recopier.
+
+**Le paquet publie ses entrées nommées, son interface** : un projet importe le paquet par son
+nom et l'une de ses entrées (le champ `exports`), jamais par l'adresse d'un fichier, comme
+`eslint/use-at-your-own-risk` publie les outils d'ESLint. Chaque entrée sort du module qui porte
+la fonction, sans réexport, avec sa déclaration de types à côté (`scripts/<module>.d.ts`) :
+`@roomi-fields/grillhouse/dette` (`trancher`, la dette connue d'une garde du projet),
+`@roomi-fields/grillhouse/consommateurs` (`matieres`, les paquets de la matière de test
+partagée), `@roomi-fields/grillhouse/paquets` (`horsCadre`, les paquets hors cadre), et la
+configuration de base de Vitest, `@roomi-fields/grillhouse/vitest-config` et
+`@roomi-fields/grillhouse/vitest-config/mesure`. Une entrée s'ajoute ou se retire avec ce
+paragraphe, que `tests/unit/paquet-publie.spec.ts` confronte au champ `exports`. Ainsi une
+version du paquet dit ce qu'un projet peut importer, et ce qu'elle lui retire.

package/hooks/register.tsx

@@ -170,12 +170,6 @@ export const ouvrirGroupe = (s: Etat, groupe: string | undefined): Etat =>
       ? { ...s, vue: 'groupe', groupe, element: null, grand: false }
       : s
 
-// A line's text and its other text (`alterne`) take turns, ALTERNANCE ms each: the text shown at
-// the turn `tour` of the pane's clock (its other text at an odd turn), its text when it has no other.
-export const ALTERNANCE = 5_000
-export const texteDe = (l: Ligne, tour: number) =>
-  l.alterne !== undefined && tour % 2 === 1 ? l.alterne : l.texte
-
 // While the board shows a line of progress (`avancement`: an automatic pass, « il y a 8 s »), it is
 // measured again every AVANCEMENT ms instead of every PERIODE: `aMesurer` says when, at the pane's
 // clock.
@@ -190,8 +184,6 @@ export const couleur = (ton: Ligne['ton']) =>
 // The session's project, and whether the board applies to it.
 let cwd = ''
 let actif = false
-// The turns of the alternation of the lines' texts, one per ALTERNANCE.
-let tour = 0
 // The pane's window: its first line, the element it last followed, and the rows and focus it was
 // last drawn with. The wheel moves it; the ring moving to another line makes it follow.
 let fenetre = 0
@@ -314,11 +306,9 @@ export const register: Register = on => {
     })
     void rafraichir($)
     $.clock.every(PERIODE, () => void rafraichir($))
-    // A line with another text turns at each ALTERNANCE: the pane is drawn again, while one shows.
-    $.clock.every(ALTERNANCE, () => {
-      tour++
+    // A line of progress has the board measured again, by the clock of half its period.
+    $.clock.every(AVANCEMENT / 2, () => {
       void read($, etat).then(s => {
-        if (lignesDe(s).some(l => l.alterne !== undefined)) $.ui.invalidate('ui.render')
         if (aMesurer(s, Date.now())) void rafraichir($)
       })
     })
@@ -508,7 +498,7 @@ export const register: Register = on => {
           {liste.slice(premier, premier + rangs).map(({ l, cle }) => {
             const texte = (
               <Text bold={l.ton === 'titre'} dimColor={l.ton === 'discret'} color={couleur(l.ton)} wrap="truncate-end">
-                {texteDe(l, tour) || ' '}
+                {l.texte || ' '}
               </Text>
             )
             if (cle && l.groupe) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@roomi-fields/grillhouse",
-  "version": "0.23.1",
+  "version": "0.24.0",
   "description": "Roomi's Grillhouse: the frame's scripts, called by one command, grillhouse <sous-commande>",
   "license": "MIT",
   "type": "module",
@@ -30,6 +30,18 @@
   },
   "exports": {
     "./package.json": "./package.json",
+    "./consommateurs": {
+      "types": "./scripts/consommateurs.d.ts",
+      "default": "./scripts/consommateurs.mjs"
+    },
+    "./dette": {
+      "types": "./scripts/dette.d.ts",
+      "default": "./scripts/dette.mjs"
+    },
+    "./paquets": {
+      "types": "./scripts/paquets.d.ts",
+      "default": "./scripts/paquets.mjs"
+    },
     "./vitest-config": {
       "types": "./scripts/vitest-config/base.d.ts",
       "default": "./scripts/vitest-config/base.mjs"