Roomi's Grillhouse

Roomi’s Grillhouse est le cadre que j’ai construit pour BPscript, FaustScript et Kanopi. Ces projets sont trop complexes pour un vibecoding centré sur la solution : sans structure, des agents de code font le contraire de l’architecture, et un projet complexe finit en plat de spaghettis. Grillhouse pose que l’architecture décide et que le code suit : chaque décision s’écrit dans l’architecture avant d’être codée. BPscript en est le projet pilote : 99 des 163 entrées du journal des versions, de la 0.16.0 à la 0.24.13, citent un incident constaté sur ce projet, ticket à l’appui. Sa limite principale : il suppose Linux, Claude Code, Node.js 22 ou plus récent et un projet TypeScript ou JavaScript, et ses compétences parlent français.

Pas de démo jouable : le cadre tourne dans un terminal, sur la machine du projet.

Le grill d’abord, le code ensuite

Avant le code, une séance interroge le responsable du projet, tour par tour : objectifs, produits matures de référence, consommateurs, axes de changement, composants et interfaces. Elle écrit la charte et les documents de référence du projet. Le grill reste ouvert : toute question de structure posée en cours de route y revient. Ce qu’une règle tranche, la chaîne le tranche ; le responsable ne reçoit que les vraies décisions, avec une recommandation.

Une chaîne d’intégration dont les étapes sont des agents

Le README le compare lui-même à une intégration continue : chaque étape applique ses règles sans demander, et n’appelle une personne que pour ce qu’aucune règle ne tranche. Un ticket passe d’étape en étape : 1 Plan, 2 Tests, 3 Code, 4 Passe finale et relecture, 5 Intégration (packages/grillhouse/scripts/etapes.mjs). Chaque étape est tenue par un agent neuf, une session Claude Code lancée pour ce seul rôle.

Les rôles sont nommés comme une brigade de cuisine. Le superviseur (pitmaster) tient la file des tickets. L’explorateur écrit le plan, le questionneur le conteste une fois. Le testwriter écrit les tests avant le code, le développeur les fait passer sans pouvoir y toucher, le relecteur relit sans rien écrire. Chaque session rend une fiche structurée, validée par un schéma ; la chaîne décide sur ces fiches et sur les rapports des tests, jamais sur le texte libre d’un agent.

Commencer

D’après le README (je n’ai pas relancé ces commandes pour cette fiche) :

npx @roomi-fields/grillhouse init ~/dev/mon-projet [préfixe-des-tickets]
cd ~/dev/mon-projet && claude

init crée le projet depuis le gabarit templates/projet/, installe Beads (le magasin de tickets, rangé dans git) et CodeGraph, indexe le code, pose les crochets git, installe les greffons déclarés et finit sur un commit. Il refuse un dossier qui n’est pas vide. Un projet existant adopte le cadre par npm install -D @roomi-fields/grillhouse puis npx grillhouse maj.

Ce qu’il fait

• Le grill d’initialisation. À chaque ouverture de séance, un crochet liste ce qui reste vide : critères d’arbitrage, champs de la charte, architecture, cadre, interfaces, lexique. La séance propose de les griller, tour par tour : objectifs, produits matures de référence, responsable, consommateurs, représentations des données, axes de changement, composants, interfaces. Chaque question arrive avec sa recommandation et ses pièces. Le grill écrit ensuite CLAUDE.md, docs/ARCHITECTURE.md, docs/CADRE.md, docs/INTERFACE.md et CONTEXT.md (mods/grillhouse/skills/grill/SKILL.md).
• La garde de structure. À chaque message, un crochet renvoie au grill toute question de paquets, de modules, d’interfaces ou de frontières.
• Les verrous. Chaque agent tourne dans une enveloppe bubblewrap : il lit toute la copie et n’écrit que les paquets que son plan nomme. Des crochets de droits interdisent au développeur de modifier les tests.
• La supervision par tickets. Un arrêt de la chaîne se termine sur une question posée au superviseur, avec son fait et sa pièce (fichier et ligne, ou commande et sortie). Le superviseur reprend, étend le plan ou arrête par une commande de la chaîne.
• Le tableau. Le volet /grillhouse, ou npm run tableau, montre où en est chaque ticket, le temps et les jetons de chaque agent.
• La nuit. grillhouse nuit, lancé par la table des tâches, rejoue la passe complète ; chaque tâche rouge complète son ticket ouvert ou en ouvre un.

Un exemple réel, de la version 0.24.12 : la chaîne rangeait chaque découverte d’un agent comme un ticket fermé. BPScript en comptait 161 depuis le 12 octobre, aucune lue une à une ; sur un seul ticket, trois sur neuf disaient la même chose. Depuis, une étape 5.3 trie chaque découverte avec un verdict (traitée, doublon, sans suite, à porter, non confirmée) et sa preuve, rejouée sur la branche principale.

Où il en est

Le paquet npm est @roomi-fields/grillhouse. Il ne tourne que sous Linux : l’enveloppe des agents repose sur bubblewrap.

La vision : un seul cadre, identique dans chaque projet qui l’installe, que chaque projet fait évoluer en proposant ses écarts. Le but est que chaque projet construise un produit mature, sur l’existant et sur ce que font les références de son domaine.

Le tableau calcule le temps et le coût de chaque ticket ; je ne publie pas de chiffre de gain tant qu’aucune mesure comparée n’existe. Les nouveautés sont dans le journal des versions du dépôt.

Dépôt · Paquet npm · RTFM · BPscript

Grillhouse relie des outils existants : Beads, CodeGraph, RTFM, les compétences mattpocock-skills, Turborepo, Vitest. Les passes du relecteur (cas limites, trous de vérification) sont reprises de BMAD-METHOD, sous licence MIT (CREDITS.md).