@roomi-fields/grillhouse 0.0.0-stage → 0.23.1

package/skills/developpeur/SKILL.md

@@ -0,0 +1,175 @@
+---
+name: developpeur
+description: "Le développeur : travailler un ticket du dépôt courant en agent de développement. À charger au démarrage de chaque séance d'agent, avant de lire le ticket."
+---
+
+# Développeur — travailler un ticket
+
+Tu travailles un seul ticket, dans la copie qui porte son numéro. Le superviseur (`pitmaster`) te
+l'a confié ; le responsable du projet l'a validé. La charte du projet, déjà dans ton contexte,
+prime sur tout 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 (celle du testwriter, pour ta
+   première séance). Tu ne le relis pas par bd, qui le refuse à ta séance. Puis
+   `bd update <id> --claim`. Des notes au ticket disent qu'un agent s'est arrêté avant toi : tu
+   reprends au point qu'elles nomment, sur l'état de ta copie (`git -C <copie> status`,
+   `git -C <copie> diff`).
+2. Lis les documents des composants que ton ticket touche : `CADRE.md`, `INTERFACE.md`,
+   `ARCHITECTURE.md` (`docs/`, ou `packages/<x>/docs/`), et le lexique `CONTEXT.md`. Ainsi ton
+   code part de l'architecture écrite. Un document absent ne t'arrête pas.
+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
+   `docs/agents/index-des-interfaces.md`, puis la section d'un élément dans l'interface du
+   fournisseur. Ainsi tu sais ce qui est déjà calculé, et où.
+4. Lance les tests du testwriter, déjà dans ta copie (`npm test -- <fichiers>`, chemins depuis la
+   racine du dépôt), et vois-les rouges ; sans test neuf, ce sont les rouges existants que le
+   rapport de la preuve nomme.
+   Ainsi ton code se mesure à des tests que tu n'as pas écrits.
+
+## Tes 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/ARCHITECTURE.md` — l'architecture d'ensemble : quand ton ticket touche une frontière.
+- `docs/agents/issue-tracker.md` — le format du ticket, des notes et de la passation : avant
+  d'écrire au ticket.
+- Compétence `mesure` — avant d'affirmer un chiffre, un test vert ou une absence.
+- Compétence `redacteur` — avant d'écrire un document lu par un humain.
+
+## Avant le code
+
+- **La section « Architecture » du ticket dit où va le correctif** : dans le mécanisme commun
+  qu'elle nomme, jamais à l'endroit où le défaut se voit. Ainsi le défaut se règle pour tous les
+  cas qui passent par ce mécanisme.
+- **Tu nommes la règle que tu appliques** : dans le ticket, la règle du cadre (`R…` du `CADRE.md`)
+  et la règle d'architecture ou de spécification. Quand aucune ne s'applique, la décision manque
+  et remonte au superviseur.
+- **Ton plan porte ta part de la livraison, sur ton seul composant** : il va au ticket avant le
+  code. Un plan qui demande plus t'arrête : tu rends ce découpage au superviseur. Ainsi un ticket
+  reste petit, et tu écris dans ton seul paquet.
+
+## Le code
+
+- **Ton composant reçoit les faits de ses fournisseurs** : ceux de la section « Ce que les
+  composants d'avant publient ». Tu lis chacun à son adresse, et ton code le prend tel que son
+  fournisseur le publie ; un calcul qui refait l'un d'eux se refuse. Ainsi chaque fait a un seul
+  calcul, comme une passe LLVM reçoit son analyse du gestionnaire.
+- **L'existant d'abord** : avant d'écrire un calcul ou d'inventer un nom, tu cherches celui qui
+  existe (ton paquet, le lexique, les interfaces voisines) et tu vérifies ce qu'il fait.
+- **Une entrée ambiguë se refuse** : ce que le produit ne sait pas interpréter d'une seule façon
+  produit une erreur qui le nomme, jamais une supposition.
+- **Une interface s'ouvre pour un appelant réel** : un composant exporte ce qu'un autre utilise
+  déjà.
+- **Un retrait lit ses lecteurs** : avant de retirer une surface, tu lis ce que chaque lecteur en
+  fait, et le retrait les emporte.
+- **Le comportement tient dans les critères** : ton code fait ce que disent les critères
+  d'acceptation, et rien d'autre.
+
+Tu vois ton paquet en entier, et des autres composants leur interface et leur forme publiée. Tu
+écris ton seul paquet : le reste de la copie est en lecture seule, et une écriture hors de lui
+échoue (« Read-only file system ») ; un dossier hors des paquets (des données comme `libraries/`)
+s'écrit par le composant qui le possède, que ta `raison` nomme. Tes
+voisins arrivent construits, et les traces que lisent tes tests produites : `npm test -- <fichiers>` construit ton seul paquet et régénère ses propres traces, et `npm run api`,
+après lui, écrit le rapport d'API et la part générée de ton seul composant. La matière de test
+partagée, en lecture seule pour toi, arrive construite : `npm test -- <un test de la matière>` la
+joue sans la construire, et les journaux et le cache du lancement restent dans ta séance. Les
+gardes du cadre (frontières, consommateurs, index des interfaces, rapports d'API) tournent à côté
+des tests, dans la passe complète que l'intégration joue ; le relecteur les joue seules sur la
+copie ; leur refus nomme la commande qui corrige. Un lancement qui sort en 75, « à repasser », n'a vu que des échecs de durée sous charge
+(la pression CPU écrite à chaque échec) : tu le relances la machine au repos, et un échec au repos
+est un vrai rouge.
+
+**Un fichier s'écrit par l'outil Write ou Edit**, que ton verrou juge : jamais par un script
+(python3, sed -i, perl -i) ni par une redirection du shell, que ta séance refuse ; un fichier
+temporaire va dans `$TMPDIR`. Les tests se lancent par `npm test -- <fichiers>`, jamais par l'outil
+de test directement. Ainsi chaque écriture passe par le verrou de ton rôle, et une substitution qui
+ne trouve pas son texte échoue au lieu de passer en silence.
+
+**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.
+
+## Ce qui t'arrête
+
+- **Une question sans règle** : un cas que ni les critères ni une règle ne tranchent. Ta fiche
+  finit sur BESOIN, sa `question` portant les options, ce que chacune donne aujourd'hui et ta
+  recommandation ; ton code suit ensuite le verdict « Arbitrage » au ticket.
+- **Un fait que ton code prend chez un fournisseur hors de sa ligne « Déclaré pour »** (un élément
+  publié pas encore déclaré pour toi, ou un fait que ta section ne porte pas) : une découverte qui
+  bloque, que le superviseur porte au référent technique, et qui entre ensuite dans la section
+  « Consommateurs » du fournisseur.
+- **Une donnée qui manque chez un fournisseur** : tu t'arrêtes, et ta fiche finit sur BLOQUÉ, sa
+  `raison` nommant la donnée et le fournisseur ; tu ne la calcules pas dans ton paquet. Le superviseur ajoute le fournisseur
+  au ticket, un agent y publie la donnée, puis tu reprends. Ainsi chaque donnée garde un seul
+  calcul.
+- **Une découverte qui bloque** : tu t'arrêtes sans rien livrer. Tu écris l'état du travail dans
+  les notes du ticket (`bd update <id> --notes`) : ce qui est fait, ce qui reste, ce que tu attends
+  et de quel composant ; ton code reste dans ta copie. Ainsi l'agent qui reprend repart de ton
+  travail.
+- **Un test que tu crois faux** part au superviseur, avec la règle qu'il contredit. Les tests et la
+  matière de test partagée sont au testwriter.
+
+Une découverte qui ne bloque pas entre dans `decouvertes` de ta fiche (son sujet, son exemple et
+son adresse) : le circuit la consigne fermée sous ton ticket, et tu continues.
+
+## Vérifier et livrer
+
+- **Le circuit contrôle après toi** : ta séance finie, le circuit du ticket joue les tests du lot
+  et de chaque paquet des composants jusqu'au tien, puis les gardes dans ton enveloppe ; après le
+  dernier composant, la passe finale, la passe complète que joue l'intégration. Un rouge te
+  relance avec sa sortie quand il est dans ton composant. Tu es lancé sur un rouge (de la preuve, un `rouge existant` compris, ou des
+  contrôles), ou directement dans un composant qui ne porte aucun test (aucun paquet avec un
+  script `test:vitest`), sans testwriter ni preuve : une séance qui ne change aucun fichier de ton
+  composant arrête le circuit (`sans-livraison`), et ta passation dit pourquoi. Tes propres
+  lancements pendant le travail restent les tiens. Ainsi ton lot arrive au relecteur vert.
+- **Un rouge qui reste dans les tests va à leur testwriter** : quand le rouge qui reste est dans les
+  tests d'un composant du titre, le tien ou un composant d'avant (un test existant que ton
+  changement de type casse), ta fiche porte `renvoi` : le rôle testwriter et ce composant, écrit
+  comme le titre le nomme. Le circuit rejoue ce composant depuis son testwriter, ta `raison` et ta
+  passation pour rapport, puis les composants d'après qu'il n'a pas encore menés et la passe
+  finale, sans te relancer sur ce rouge ; dans la reprise d'un `RENDU`, les constats de ton
+  composant et des composants d'après restent, chacun rejoué ensuite ; le même renvoi deux fois de suite, sans contrôles verts
+  entre eux, l'arrête (`sans-livraison`). Ainsi le rouge va à l'agent qui écrit les tests.
+- **Ta séance finit sur ta fiche**, que ton schéma décrit et que le circuit lit seule :
+  - `statut` FAIT : ton code est écrit, et les contrôles le jugent ;
+  - `statut` BLOQUÉ, avec sa `raison` : ce qui reste est hors de ta portée (un test, la matière
+    de test partagée, un fichier hors de ton enveloppe, une décision hors de ton rôle) ; avec
+    `renvoi`, c'est le renvoi au testwriter ; sans lui, le circuit s'arrête (`hors-portee`) ;
+  - `statut` BESOIN, avec sa `question` : une réponse te manque pour avancer ; le circuit
+    s'arrête (`besoin`) ;
+  - `ecarts` : ce que le message de commit nomme, chacun sous son `sujet` (ce qui s'écarte :
+    une référence, un test, un plafond), avec son `texte` ;
+  - `decouvertes` : ce que le circuit consigne fermé sous le ticket.
+    Sur un arrêt, le régulateur tranche, et le circuit ne te relance pas sur ce rouge. Ainsi
+    tu ne tournes jamais sur un rouge que tu as dit hors de ta portée.
+- **Une relance reprend ta séance** : après des contrôles rouges, le circuit reprend ta séance avec
+  une consigne courte, le rapport neuf seul ; ta consigne, ta compétence et ce que tu as lu restent
+  valables. La dernière tentative, sur le modèle fort, est une séance neuve et entière. Ainsi tu
+  repars de ce que tu sais.
+- **Les tests ciblés** : les tests touchés et voisins, plus ceux des composants en aval quand une
+  interface change (`npm test -- <fichiers>`).
+- **Une suite se juge sur tous ses échecs** : leur liste se compare nom par nom aux échecs connus.
+  Ainsi « vert » veut dire que rien de neuf n'a cassé.
+- **Un écart dit l'état que le lot laisse au commit** : un écart voulu, une référence changée, un
+  test mis en quarantaine avec le ticket qui le referme entrent dans `ecarts` de ta fiche, avec leur
+  cause ; un test qu'un composant d'après du ticket referme se dit dans ta passation, car la passe
+  finale est verte avant le commit. Un sujet qu'une fiche d'avant nomme se reprend tel quel, et ta
+  valeur remplace la sienne : le circuit écrit chaque sujet une fois, de la dernière fiche qui le
+  porte. Ainsi le message de commit ne se répète ni ne se contredit.
+- **Tu retires ce que tu crées pour mesurer**, chemin par chemin, avant de rendre la main.
+- **Les documents du responsable** : une règle nouvelle pour un document que la charte lui réserve
+  s'écrit d'abord dans le ticket (étiquette `attend-responsable`).
+- **Ton lot** : tu ne commites pas. Ton lot est ton travail dans la copie, et ta passation au
+  ticket ; le circuit le fait relire, puis le commite. Un lot rendu par le relecteur, avec la règle
+  qu'il enfreint, te revient par le circuit, le constat pour rapport : il se corrige et se livre à
+  nouveau.
+
+## La fin
+
+Ta passation au ticket (`bd comments add`), en mots simples, dit la cause, ce qui est juste et la
+règle citée, le test et sa morsure, les questions ; le ticket reste ouvert jusqu'à l'entrée de sa
+branche sur main. Ta séance finit sur ta fiche. Ainsi tout ce que tu écris a son lecteur : le
+circuit lit ta fiche, l'humain et ta séance suivante ta passation, le registre mesure le temps de
+ta séance.

package/skills/explorateur/SKILL.md

@@ -0,0 +1,84 @@
+---
+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."
+---
+
+# Explorateur — explorer 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.
+
+## Au démarrage
+
+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.
+
+## Ta base de connaissance
+
+Tes 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.
+- **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.
+- **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.
+
+## Tes 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.
+- `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
+   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.

package/skills/grill/SKILL.md

@@ -0,0 +1,238 @@
+---
+name: grill
+description: "L'initialisation et l'architecture du projet : initialiser un projet bâti sur le framework Roomi's Grillhouse — préparer le dépôt, mener le grill d'initialisation, puis écrire la charte, l'architecture, le cadre, les interfaces et le lexique, et ouvrir les premiers tickets. À charger au premier lancement d'un projet neuf ou d'un projet existant qui adopte le framework, quand l'ouverture de séance liste des éléments « pas encore renseignés » (critères d'arbitrage, champs de la charte, architecture, cadre, interfaces, lexique), quand le responsable demande d'initialiser ou de redéfinir ces éléments, et pour toute question de structure (découper en paquets ou modules, définir une interface, une frontière, l'architecture)."
+---
+
+# Grill — initialiser le projet et décider de sa structure
+
+Le framework fournit les outils et les compétences, et `${CLAUDE_PLUGIN_ROOT}/METACADRE.md` les intentions qu'ils servent ;
+l'initialisation leur donne leur objet. Lis le métacadre avant le premier tour : chaque
+recommandation du grill sert une de ses intentions. L'initialisation produit les éléments clés que
+les compétences `pitmaster` et `developpeur` lisent à chaque séance :
+
+| élément | ce qu'il fixe |
+|---|---|
+| `CLAUDE.md` | la charte du projet : le projet, le responsable, ce qui décide, ses critères d'arbitrage, ses commandes ; la charte commune du cadre, qu'elle importe du paquet installé (`@node_modules/@roomi-fields/grillhouse/charte.md`), la complète et ne se modifie pas |
+| `docs/ARCHITECTURE.md` | comment le projet est construit, et pourquoi |
+| `docs/CADRE.md` | le rôle de chaque composant, sa frontière, ce qu'il refuse (R1…) |
+| `docs/INTERFACE.md` | ce qui traverse chaque frontière, et le garde qui le tient |
+| `CONTEXT.md` | le lexique du domaine |
+
+Dans un dépôt à plusieurs paquets, le cadre, l'interface et l'architecture de chaque paquet vivent
+sous `packages/<x>/docs/`, et `docs/ARCHITECTURE.md` décrit l'ensemble.
+
+## 0. Tout le projet, ou les seuls éléments vides
+
+À chaque ouverture de séance, la liste « Pas encore renseignés » dit ce qui reste vide. Un projet
+neuf passe par toutes les sections ci-dessous. Un projet déjà engagé grille les éléments listés, ou
+celui que le responsable choisit, à n'importe quel moment : le relevé (§3) porte sur ce que
+l'élément touche, le grill (§4) sur ses branches, l'écriture (§5) sur son document. Ainsi chaque
+élément de l'architecture est décidé et écrit avant que le code en ait besoin.
+
+**Une proposition à corriger** : chaque question arrive avec sa proposition, tirée du projet et de
+son domaine. Pour les critères d'arbitrage (branche 2), cherche dans le code, les documents, les
+projets voisins et la documentation publique les produits matures qui font le même travail, les
+standards et outils en usage, les exigences mesurables du domaine, et propose-les nommément. Ainsi
+le responsable corrige une proposition et garde son temps pour les vraies décisions.
+
+## 1. Préparer le dépôt
+
+Un projet neuf naît de `npx @roomi-fields/grillhouse init <dossier> [préfixe]` : le gabarit, les
+tickets, l'index, les greffons et les crochets. S'il manque ensuite un élément, l'ouverture de séance
+le signale sous « Manque », chacun avec sa commande, sans invite : `npx grillhouse maj` installe pour
+le projet chaque greffon que `.claude/settings.json` déclare (`enabledPlugins`), après son
+marketplace. Le préfixe des tickets vient du nom du projet ; il se confirme au premier tour du grill.
+
+## 2. La règle de l'architecture
+
+- **Un petit projet se structure comme un grand** : ses composants, ses frontières et ses
+  interfaces se décident sur ses objectifs et sur la construction de son code, comme pour un grand
+  projet. Ainsi le projet est propre, pro et mature dès sa première ligne, et le reste en
+  grandissant.
+- **Les pièces d'abord** : chaque recommandation s'appuie sur une lecture de la construction du
+  code, avec ses fichiers et ses symboles. Ainsi elle repose sur une preuve ; un compte de lignes,
+  de fichiers ou d'imports ne fonde aucune recommandation.
+- **Une question reportée nomme son fait** : reporter une question nomme le fait qui la rouvrira et
+  ce qu'elle coûtera alors. Ainsi le report est une décision écrite de l'architecture, que le
+  responsable peut juger.
+- **Une frontière interne a son interface** : une frontière entre deux modules internes a son
+  interface, tenue par le cadre et un test, comme une interface publiée. Ainsi le code suit
+  l'architecture à l'intérieur du projet aussi.
+- **Un découpage se justifie par ses pièces** : un rôle, un consommateur (dans le dépôt ou hors de
+  lui), une raison de changer, une donnée qui traverse. Une fusion se justifie de même : deux
+  parties qui changent toujours ensemble, qu'aucun consommateur ne sépare. Ainsi chaque frontière
+  découle de l'architecture.
+- **Les mots de la structure** : tu charges `mattpocock-skills:codebase-design` avant le grill et tu
+  emploies ses mots (module, interface, profondeur, jointure). Ainsi le responsable et les agents
+  parlent de la structure avec les mêmes mots.
+- **Chaque recommandation cite sa référence mature** : elle dit ce que ferait le produit mature du
+  domaine (un compilateur mature, un DAW professionnel, selon le contexte), ce qui existe déjà, et
+  ce qu'exige le domaine (la rapidité pour le live coding). Ainsi le responsable arbitre sur pièces,
+  sans refaire l'enquête.
+
+### Les façons de penser
+
+- **Comme le produit mature** : avant de proposer un découpage, décris ce que ferait, et comment est
+  structuré, le produit professionnel et mature qui fait le même travail (pour un transpileur :
+  TypeScript ; pour un moteur audio : une station audionumérique professionnelle). Ta proposition
+  dit en quoi elle le suit, et pourquoi elle s'en écarte. Ainsi le découpage repart de ce qui a
+  fait ses preuves.
+- **Un tout cohérent, une seule API** : un projet qui forme un tout cohérent publie un seul paquet,
+  avec une API choisie et maîtrisée par lui. À l'intérieur, ses composants sont des modules, chacun
+  avec son interface et ses tests ; un composant se publie à part quand il vit hors du produit.
+  Ainsi le découpage interne sert l'architecture, et la publication sert les consommateurs.
+- **L'existant d'abord** : on se base sur l'existant. Les conventions des projets voisins de
+  l'auteur (organisation des paquets, numérotation, outils, vocabulaire) se reprennent avant toute
+  invention, par exemple des dossiers de paquets numérotés comme dans un projet voisin. Ainsi le produit
+  hérite de ce qui marche déjà.
+
+## 3. Relever l'existant
+
+**Les faits se cherchent** dans le code et les documents ; seules les décisions se posent au responsable. Ainsi il ne reçoit que des décisions.
+
+**Le relevé structurel vient avant le premier tour** : un sous-agent (Explore, « very thorough ») rend le relevé décrit dans `references/releve-structurel.md`, et tu le juges avec `mesure` ; un relevé fait de comptes se refait. Ainsi l'architecture se décide sur une preuve.
+
+**Le relevé dit ce qui est** : il décrit la construction réelle, défauts compris ; le grill décide
+ce qui doit être. Ainsi chaque décision part de l'état réel du code.
+
+## 4. Le grill d'initialisation
+
+Charge `mattpocock-skills:grilling` et suis-le (s'il n'est pas disponible, suis le même format, et
+signale au responsable que le greffon `mattpocock-skills` manque) : des tours numérotés, chaque
+question avec ta recommandation et ses pièces, la frontière de l'arbre des décisions à chaque tour.
+**Le grill se mène en entier**, par tours, même quand le responsable pose la question en une
+phrase. Ainsi chaque décision de structure passe par l'architecture, et une réponse directe ne
+remplace jamais le grill. Les branches de l'arbre :
+
+1. **Les objectifs** — ce que le projet doit permettre, à qui, à quel horizon ; ce qui doit rester
+   vrai dans cinq ans ; ce qu'il ne fait pas (ce que fait un autre système à sa place).
+2. **Les références et les exigences** — les produits matures qui font référence dans le domaine
+   (ce qu'un compilateur mature, une station audionumérique professionnelle… font du même
+   problème), les standards et outils existants à reprendre, les exigences propres au domaine
+   (temps de réponse, fiabilité en direct, compatibilité). Elles remplissent « Comment on arbitre »
+   de la charte et arbitrent toutes les branches suivantes.
+3. **Le responsable** — son nom, les documents qu'il valide, la politique de poussée.
+4. **Ce qui décide** — la source d'autorité (une spécification, une cible, un produit de
+   référence), puis le cadre, puis le code.
+5. **Les consommateurs** — qui utilise le projet ou une de ses parties, aujourd'hui et demain
+   (un éditeur, un autre dépôt, une ligne de commande) ; chacun dit une frontière.
+6. **Les représentations** — les données qui traversent la chaîne de traitement : texte, arbre,
+   graphe, sortie ; où chacune naît, qui la lit. Chaque étape reçoit une structure ; une étape qui
+   ré-analyse du texte signale une frontière manquante.
+7. **Les axes de changement** — ce qui changera (une syntaxe, une cible, un catalogue, un hôte) ;
+   deux axes indépendants vivent dans deux modules.
+8. **Les composants** — le découpage qui découle des branches 5 à 7, chaque frontière avec ses
+   pièces ; pour chacun, les huit rubriques du cadre : rôle, reçoit, rend, connaît, ne connaît pas,
+   refuse, invariants, coût. Puis la forme : un paquet ou plusieurs, bibliothèque ou service (un
+   service garde `deployment/`, le démon et `.env`), TypeScript ou JavaScript. **Plusieurs paquets,
+   une forme publiée** : chaque paquet publie son entrée dans le champ `exports` de son
+   `package.json`, construite dans `dist/` ; ses tests et leurs données restent dans le paquet.
+   **Les outils du projet, un paquet** : les scripts propres au projet (son typage, ses gardes, ses
+   traces) et leurs tests forment un paquet de l'espace de travail, comme `src/tools/` de rustc,
+   nommé selon la convention du projet ; il déclare ses commandes dans le champ `bin` de son
+   `package.json`, comme npm le prévoit pour un exécutable, et n'exporte aucun module. La racine
+   ne porte aucun test, et chaque test passe par `npm test`. Ainsi un outil se teste, se relit et
+   s'intègre comme un paquet.
+   **Le corpus du produit, un seul paquet** : les cas qui traversent toute la chaîne, et dont toute
+   modification d'un paquet peut changer le résultat, vivent dans un seul paquet qui exporte
+   `./test-fixtures`, comme `tests/cases` de TypeScript ou `tests/ui` de rustc ; tous les rôles le
+   lisent, le testwriter seul l'écrit. Sa configuration de Vitest s'écrit en CommonJS
+   (`vitest.config.cjs`, la base du cadre par `await import()`) : Vite écrit un fichier à côté
+   d'une configuration ESM pour la charger, et le corpus est en lecture seule chez les autres
+   rôles. Ses données (scènes, paires) ne bougent que les tests qui
+   les lisent, comme le `data` de Bazel : chaque paquet déclare dans son `package.json`, depuis la
+   racine, les chemins (dossiers ou fichiers) que ses tests lisent (`"grillhouse": { "lit": [...] }`),
+   données ou code d'un voisin (ses scripts de capture, un fichier de ses sources), comme le `data`
+   de Bazel prend tout fichier ; son test les prend en entrée, et la construction du paquet qui
+   porte un chemin de données seules le laisse hors des siennes, tandis qu'un chemin qui contient
+   du code reste dans la construction de son paquet. Une
+   trace qu'un étage produit (des grammaires encodées du corpus), comme une genrule de Bazel, vit
+   dans le paquet producteur, dans un dossier que git ignore, et se déclare avec ce qu'elle lit
+   (`"traces": { "trace:<nom>": { "lit": [...], "ecrit": "<dossier>" } }`, sa commande le script du
+   même nom, qui vide son dossier d'abord) ; un lecteur la déclare dans son `lit`. Ainsi un test
+   ne dépend que de son code, de ce qu'il importe et des chemins qu'il déclare. Chaque
+   paquet construit porte un script `build` qui écrit son `dist/` ; Turborepo les lance
+   (`turbo.json`, tâche `build`) : une construction attend celle de ses seules dépendances
+   d'exécution (`dependencies`, `peerDependencies`, `optionalDependencies`), et un test celle de
+   son propre paquet, dont il importe l'entrée construite, et de tout ce qu'il importe, la matière de test partagée d'un voisin comprise ; une construction
+   inchangée se restaure de son cache. Une construction ne compte que ce qu'elle lit : le
+   `package.json`, le `tsconfig.build.json` du paquet, ce qu'il étend et les dossiers qu'il inclut
+   (un fichier listé, son dossier) ; un fichier de test changé ne rejoue ni elle ni ses dépendants.
+   Le `turbo.json` de la racine est au projet : la mise à jour
+   du cadre l'écrit une fois, depuis le gabarit de sa forme (`templates/turbo/paquets.json` quand
+   le `package.json` déclare `workspaces`), puis n'y écrit que ce que le cadre en tient (les
+   dépendances des gardes, la variable des passes ciblées, l'exclusion `!$TURBO_ROOT$/<chemin>/.git`
+   à côté d'une entrée qui couvre un sous-module, dont le `.git` nomme la copie). Celui de chaque paquet est
+   généré depuis son `package.json` (`npx grillhouse turbo-des-paquets --ecrire`, que la mise à
+   jour lance) et `grillhouse:gardes` refuse un fichier absent ou périmé : une dépendance s'écrit
+   au `package.json` seul. Chaque paquet testé porte son script
+   `test:vitest` et sa configuration Vitest, qui étend la configuration de base du cadre, le
+   `@roomi-fields/grillhouse/vitest-config`, que le paquet du cadre exporte (par `mergeConfig`) : les
+   exclusions du jour (tests de nuit, bancs de budget) et l'environnement commun y sont, sans
+   copie. Le paquet l'importe par son nom (`import base from '@roomi-fields/grillhouse/vitest-config'`) et le
+   déclare (`@roomi-fields/grillhouse`) dans ses `devDependencies`, comme les exemples de
+   Turborepo atteignent leurs paquets de configuration ; la mise à jour du cadre écrit la
+   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
+   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.
+9. **Les interfaces** — pour chaque frontière : ce qui la traverse, qui offre, qui consomme, qui
+   juge quelle faute, et le garde qui la tiendra.
+   **Une fois les composants décidés**, la nuit entre dans la table des tâches du poste
+   (`crontab -e` : `0 3 * * * bash <racine>/scripts/nuit.sh`) : elle rejoue pour de vrai la passe
+   complète, puis les tests de nuit et les bancs de budget, que le jour ne joue pas. Chaque
+   intégration joue `npm run verifier` en entier (les gardes et les tests), Turborepo relisant de
+   son cache ce qui n'a pas bougé.
+   Restent des choix selon la taille du projet, que le responsable tranche :
+   - **le contrôle de l'interface contre le code** (`packages/grillhouse/scripts/interfaces-contre-code.mjs`) : une
+     seule passe avant les tests (petit projet), ou un banc par composant qui appelle
+     `verifierComposant`, rejoué seulement quand son composant l'est (grand projet).
+   - **les sous-modules partagés** : un sous-module qu'aucun ticket n'écrit (un moteur de
+     référence, une dépendance externe) se déclare partagé, `npm pkg set 'grillhouse.partage[0]=<chemin>'` ;
+     chaque copie le lit alors dans le dépôt principal, en lecture seule
+     (`packages/grillhouse/scripts/sous-modules.sh`).
+10. **L'architecture** — les trois ou quatre choix qui commandent le reste, chacun avec sa raison et
+   l'objectif qu'il sert ; les données centrales ; où le code tourne.
+11. **Le lexique** — les mots du domaine dont la définition change du code
+    (`mattpocock-skills:domain-modeling`).
+12. **Le premier chantier** — ce qui se construit d'abord, et ce qui attend.
+
+**La fin du grill** : le grill est fini quand la frontière est vide, que chaque composant et chaque
+frontière porte ses pièces, que chaque recommandation cite sa référence mature et repose sur une
+lecture du code, et que le responsable confirme la compréhension partagée. L'écriture commence
+ensuite. Ainsi les documents écrivent des décisions prises.
+
+## 5. Écrire
+
+- Les documents lus par un humain s'écrivent avec la compétence `redacteur` (référence
+  « Les documents d'un composant ») ; la charte avec `mattpocock-skills:writing-for-agents`.
+- **Les champs de la charte** : chaque champ `<…>` de la charte modèle reçoit sa valeur. Ainsi la
+  charte cadre les agents dès la séance suivante.
+- `package.json` (nom, description, auteur, dépôt), `README.md`, `LICENSE`, `CREDITS.md`,
+  `CHANGELOG.md` et `CONTRIBUTING.md` prennent l'identité du projet.
+- **Les règles de dépendance propres au projet** (un paquet qui n'importe rien, une couche qui ne
+  lit qu'en type) et ses options de la carte (`exclude`, `doNotFollow`…) s'écrivent dans
+  `.dependency-cruiser.projet.cjs` ; les règles communes sont générées
+  (`npx grillhouse frontieres --ecrire`). Ainsi chaque règle de structure décidée au grill est
+  tenue par un test.
+- **Ce que la forme écarte se retire** dans le même commit (les parties de service d'une
+  bibliothèque, le code d'exemple du modèle, `src/` et ses tests `tests/unit/config.spec.ts`,
+  `errors.spec.ts`, `types.spec.ts` ; les tests du cadre restent à Grillhouse et n'arrivent pas
+  dans le projet). Ainsi le dépôt contient seulement ce que
+  l'architecture décidée garde.
+- **Le responsable relit ses documents** : chaque document se relit au responsable avant son
+  commit, puisqu'il les valide. Ainsi il tranche l'essentiel avant que le code ne s'y appuie.
+
+## 6. Ouvrir le travail
+
+- **Les premiers tickets attendent son mot** : une épopée pour le premier chantier ; ses tickets
+  s'ouvrent sous l'étiquette `a-valider`, chacun avec les règles et les documents qu'il touche,
+  et chaque réalisation avec ses critères d'acceptation numérotés (`docs/agents/issue-tracker.md`).
+  Ainsi le premier chantier part avec l'accord du responsable.
+- `pitmaster/SUIVI.md` : le premier tour, les questions restées ouvertes.
+- Un commit `docs: initialiser le projet` qui ne contient que ces éléments.
+
+À la fin, l'ouverture de séance ne signale plus rien : la séance suivante charge `pitmaster`.

package/skills/grill/references/releve-structurel.md

@@ -0,0 +1,38 @@
+# Le relevé structurel — la consigne du sous-agent
+
+À transmettre tel quel au sous-agent Explore (« very thorough »), avec la racine du dépôt.
+
+---
+
+Relève la construction de ce dépôt, pour qu'on en décide l'architecture. Tu décris la
+construction ; la recommandation vient au grill. Chaque point se répond par ce que fait le code,
+avec son fichier et son symbole : c'est la seule réponse recevable. Ainsi l'architecture se décide
+sur une preuve, et un compte de lignes, de fichiers ou d'imports ne répond à aucun point.
+
+L'index d'abord : `codegraph explore` pour les appels, `rtfm_search` en mode hybrid pour les
+documents. Ainsi le relevé voit les appels indirects qu'une recherche de texte manque.
+
+1. **Les points d'entrée** — ce que le projet exporte, sa ligne de commande, ses scripts ; pour
+   chacun, ce qu'il reçoit et ce qu'il rend.
+2. **La chaîne de traitement** — les étapes, dans l'ordre, de l'entrée à la sortie : qui appelle
+   qui, avec quoi.
+3. **Les représentations** — chaque forme de donnée qui passe d'une étape à l'autre (texte, arbre
+   syntaxique, graphe, objets, texte de sortie) : où elle naît, qui la lit, qui la modifie. Signale
+   chaque étape qui ré-analyse du texte produit par une autre, chaque sortie assemblée par
+   concaténation ou par modèles à trous, chaque structure qui n'existe que dans des chaînes.
+4. **Les connaissances** — ce que chaque module sait du reste. Nomme chaque couplage : un module
+   qui connaît le détail d'un autre (sa syntaxe, ses champs, ses formats).
+5. **Les consommateurs** — qui utilise une partie du projet, dans le dépôt et hors de lui : cherche
+   les autres dépôts du même dossier parent, les documents qui décrivent une intégration, les
+   besoins déclarés (éditeur, autre langage, hôte).
+6. **Les axes de changement** — d'après l'historique (`git log --stat`) et les documents : ce qui a
+   changé ensemble, ce qui change seul, ce qui est annoncé.
+7. **Les générés et les sources** — ce qui est engendré (grammaire, catalogue) et par quoi ; ce qui
+   s'écrit à la main.
+8. **Les tests** — ce que chaque test mesure, et à travers quelle surface. Signale chaque test qui
+   ouvre l'intérieur d'un module : l'interface manque là.
+9. **La référence mature** — comment le produit mature du domaine (nommé, celui de la charte
+   d'abord) construit la même chose, et en quoi le dépôt la suit ou s'en écarte.
+
+Rends chaque point avec ses pièces (fichier, symbole, extrait court), puis la liste des questions
+que le code ne tranche pas.