La discipline du cockpit : comment un répertoire de six fichiers permet à trente-cinq sessions de build de partager une seule mémoire de projet, et pourquoi la couche de méta-outillage est le vrai goulet d’étranglement de la vélocité de build assistée par IA

Par Thales (CEO, ZeroSuite) & Claude Opus 4.7 — instance Claude Code

Le 2 juin 2026 à 05h46 heure Afrique/Abidjan, le fondateur ouvre le dépôt Conductor, lance pnpm cockpit:status et lit quarante-sept lignes de sortie qui lui disent exactement où en est le projet : la dernière session livrée, le dernier commit, la phase courante, la phase suivante, le chemin du prompt de la prochaine session, le nombre de commits non poussés, l'état du working tree et les Next-3 de la roadmap. La commande s'est exécutée en environ deux-cents millisecondes. Le fondateur choisit la phase suivante, ouvre le prompt de session correspondant à docs/plan/sessions/PHASE-12-GLOBAL-CMDK-SEARCH.md et le tend à une instance Claude Code avec une seule phrase : « exécute ça ». La session livre deux heures et demie plus tard avec pnpm check au vert, pnpm build au vert, pnpm cockpit:check au vert, le journal de session écrit, le cockpit mis à jour et le prompt de la prochaine session rédigé avant le push.

Ces deux-cents millisecondes de pnpm cockpit:status sont le détail porteur de toute la vélocité de build de ZeroSuite. Sans cela, chaque session aurait dépensé vingt minutes à ré-orienter l'agent sur l'état du projet. Avec, la session démarre en une minute et livre en deux heures. Sur les trente-cinq sessions qui ont construit Conductor d'un dépôt vide à un outil interne quotidien actif en quatre jours calendaires (du 30 mai au 2 juin 2026), cette économie de vingt minutes s'est cumulée en environ douze heures de temps de build récupéré — trois quarts d'une journée supplémentaire de débit, payés par un dossier de six fichiers texte.

Ce billet est le carnet de bord de la discipline du cockpit : quels fichiers vivent dans cockpit/, ce que fait chaque fichier, à quoi ressemblent les protocoles d'ouverture et de clôture de session, comment l'audit post-implémentation s'y insère, ce que la couche de règles critiques CLAUDE.md ajoute par-dessus, pourquoi le système fonctionne et là où il ne fonctionne pas. Le cockpit est la pièce de méta-outillage à plus fort levier de la stack ZeroSuite — non parce qu'il fait quoi que ce soit de techniquement nouveau, mais parce qu'il est le substrat sans lequel la production par session du copilote IA ne peut pas s'accumuler en un projet cohérent étalé sur plusieurs semaines.

Partie 1 — Le problème que le cockpit résout

Claude Opus 4.7 avec sa fenêtre de contexte d'un million de tokens ne se souvient pas de la session précédente au sens cognitif. Chaque session Claude Code démarre à froid. La session voit le working tree, l'historique git, le contenu des fichiers, le premier message de l'utilisateur — et rien d'autre. Si l'utilisateur ferme la session, en ouvre une nouvelle demain et tape « continue », l'agent n'a aucune idée de ce à quoi « continue » renvoie. Les vingt heures de build précédentes ne sont pas dans la fenêtre de contexte de la nouvelle session.

C'est très bien pour une tâche en une seule session. C'est fatal pour un projet de plusieurs semaines. Dès la troisième session, l'agent prend des décisions qui contredisent celles de la première, parce que les décisions de la première session ne sont plus visibles. Dès la dixième session, l'agent ré-implémente des patterns qui ont déjà été livrés parce qu'il ne peut plus les voir. Dès la trentième session, le projet est devenu un chantier archéologique — cohérent à chaque couche individuelle, incohérent à l'échelle de la stack entière.

La solution naïve consiste à déverser toute la conversation antérieure dans le prompt de chaque nouvelle session. Cela échoue pour deux raisons. D'abord, la conversation grossit linéairement avec le nombre de sessions et la fenêtre d'un million de tokens est large mais pas infinie. Ensuite, la conversation contient du bruit (pauses de saisie, faux départs, branches exploratoires abandonnées) qui rivalise pour l'attention avec les vraies décisions. L'agent qui lit un journal de conversation brut de cent mille tokens ratera le fait critique qui se trouve à la ligne 47 000.

Le cockpit est une couche de compression. Il distille l'état accumulé du projet dans un petit ensemble de fichiers structurés que l'agent lit en début de session. Le ratio de compression est d'environ deux-cents pour un — vingt heures de conversation se compressent en deux-mille mots de cockpit. La forme structurée (un fichier pour « où en suis-je », un fichier pour « quoi ensuite », un fichier lisible par machine pour « quoi a été livré ») correspond aux questions que l'agent posera dans sa première minute. La discipline consiste à maintenir le cockpit exact à la clôture de session, pour que la session suivante démarre depuis une image correcte.

Le cockpit n'est pas une base de connaissances, pas un wiki, pas un site de documentation. C'est de l'état opérationnel. Le contenu du cockpit au moment du démarrage de session indique à l'agent : ce qui a été livré, ce qui est en train d'être livré ensuite, ce qui est interdit, ce qui est en cours, ce qui est bloqué. Rien d'autre. Le code se documente lui-même ; le cockpit documente la méta-couche au-dessus du code.

Partie 2 — L'agencement des fichiers

Le cockpit à /Users/juste/ZeroSuite/ops.zerosuite.dev/cockpit/ est composé de six fichiers markdown / JSON à la racine plus trois gabarits dans un sous-dossier templates/. Chaque fichier a un seul rôle. En listant le dossier :

cockpit/now.md — le fichier « où en suis-je et quoi ensuite ». Toujours chargé dans le contexte de l'agent (monté via la section mémoire de CLAUDE.md). Structuré ainsi : une ligne « Updated » en un paragraphe en haut avec le résumé de la session la plus récemment livrée, les anciennes lignes « Updated » conservées en paragraphes « Prior » (pour qu'une future session puisse voir l'arc récent), un bloc « Current focus » d'une phrase, une section « Concrete next action if I have… » subdivisée par budget de temps (15 min / 1 heure / demi-journée / journée entière), une liste « Don't get distracted by » nommant les éléments qui ne sont explicitement PAS dans les Next-3, une liste « Constraints active today » de faits opérationnels (chiffres de plafond, noms de routes, numéros de migration, noms de variables d'environnement), et un pied de page « How to use this file ». Le total fait environ trois-cents lignes. L'agent lit cela dans les dix premières secondes de chaque session.

cockpit/roadmap.md — le tableau de bord des phases. Structuré ainsi : une ligne « Updated » en haut, un tableau « Now — Next 3 to ship (in this order) » avec phase + chemin du prompt + statut, un tableau « Queue after Next-3 », un tableau « In-flight (other agents working in parallel) », un tableau « Blocked », une liste « Queued — launch-critical », une liste « Queued — non-critical (post-launch deferable) », une liste « Post-launch backlog », et un tableau chronologique « Shipped this week » avec une ligne par livraison de session. L'agent lit cela quand une future session a besoin de savoir ce qui est en attente derrière le focus courant.

cockpit/state.json — le fichier d'état lisible par machine. Clés : updated_at, last_session_id, last_commit, current_phase, next_phase, next_prompt, launch_target_date, team, deferred_count, phases_shipped (tableau), phases_queued (tableau), phases_backlog (tableau), migrations_applied (tableau), plus un champ notes. Le script de validation lit ce fichier pour faire respecter la discipline de clôture de session (next_prompt pointe vers un vrai fichier, last_commit existe dans le git log, phases_shipped n'a pas de doublons, migrations_applied correspond à la liste réelle de drizzle/). L'agent lit rarement ce fichier directement ; le validateur le fait.

cockpit/architecture.md — la carte architecturale. Nomme les segments du code (A1 = routes SvelteKit, A2 = endpoints API, A3 = bibliothèques côté serveur, A4 = composants Svelte, etc.) pour que lorsqu'un prompt de session ou un journal de session référence « A3 video-schemas.ts », le lecteur sache où c'est dans le code. Stable entre sessions ; mis à jour uniquement quand un nouveau segment est ajouté ou un ancien restructuré.

cockpit/carte.md — la carte du projet. Une narration lisible par un humain de comment les surfaces se connectent — quoi appelle quoi, quoi lit quoi, quoi écrit quoi. Plus expositif que architecture.md. Le lecteur qui n'a jamais vu le projet devrait lire carte.md en premier pour s'orienter.

cockpit/README.md — la documentation propre du cockpit. Explique l'agencement des fichiers, le protocole d'ouverture de session, le protocole de clôture de session, les modes d'échec du validateur. Auto-référentiel — le cockpit s'explique lui-même.

Trois gabarits dans cockpit/templates/ :

cockpit/templates/session-prompt.md — la forme canonique d'un prompt de session. Frontmatter (status / session_id / session_log / drafted_at / next_after / parent_prompt), puis une intro de statut, une section « Context — what changed since the parent prompt was drafted », une section « Reference files (read these before writing) », une section « Scope (must-have → should-have → defer) », une liste numérotée « Build (in this order) », une section « Verify » avec des smoke checks, une liste de garde « Do NOT » d'anti-patterns, une checklist « At end of session » (qui inclut « draft the next session's prompt »), et une section « Expected output » qui liste le livrable. Chaque prompt de session à docs/plan/sessions/PHASE-*.md respecte cette forme.

cockpit/templates/session-log.md — la forme canonique d'un journal de session. Frontmatter (session prompt / previous session end / delegation / state at session start), puis une section « Scope shipped this session » organisée par surface (sous-sections A / B / C), une section « What did NOT ship this session — and why », un tableau « Files touched », une section « Verify » avec les résultats inline de check + build, une sous-section « Post-implementation audit » avec le verdict de l'audit et les résultats par item de checklist, une section « Deferred / risks », une section « Scope decisions made this session » qui explique ce qui a été choisi et ce que l'alternative aurait coûté, une section « Cockpit + housekeeping » qui confirme les étapes de bump, et une checklist « End-of-session ». Chaque journal de session à session-logs/YY-MM-DD-NNN-*.md respecte cette forme.

cockpit/templates/audit-brief.md — la forme canonique du prompt destiné à l'agent Explore d'audit post-implémentation. Structuré ainsi : un paragraphe « Context » qui nomme la surface et le prompt parent, une liste « Files to audit » avec plages de lignes et résumés en une ligne, une « Audit checklist » de sections ciblées qui correspondent à la classe de risque de la session (multi-tenancy / race / schema-correctness / audit-payload-sanity / etc.), une section « Output format » qui spécifie la forme de verdict requise. Chaque invocation d'audit depuis n'importe quelle session utilise ce gabarit.

La surface totale — six fichiers à la racine + trois gabarits — fait environ douze-mille mots de markdown. Douze-mille mots, c'est assez petit pour être tractable, assez grand pour compresser l'état d'un projet de plusieurs semaines.

Partie 3 — Le protocole d'ouverture de session

La session ouvre à froid. L'agent n'a aucune mémoire d'une quelconque session précédente. Le premier message du fondateur est typiquement une seule ligne : « start » ou « execute the next prompt » ou « continue session 035 ». Le protocole d'ouverture de session, ce sont les soixante secondes suivantes.

Étape un : l'agent lance pnpm cockpit:status. La commande est un script TypeScript à scripts/cockpit-status.ts qui lit state.json, now.md et le git log en parallèle, puis affiche un instantané sur un écran. Forme de la sortie :

Conductor — ops.zerosuite.dev
Phase  : phase-11.5b-fal-video-models-shipped → next : phase-12-global-cmdk-search
Prompt : docs/plan/sessions/PHASE-12-GLOBAL-CMDK-SEARCH.md  (queued)
Commit : 7eb66ac (1 commit ahead of origin/main)
Tree   : clean
Last 5 : 7eb66ac, 2d43644, c9a2eec, 69615bc, 1a63f14
Last 3 next-actions :
  15 min — open the PHASE-12 prompt
  1 h   — read scope + queue check
  half d — Phase 12 end-to-end
J-13 to Déblo launch (2026-06-15)

La sortie remplace ce qui serait sinon cinq opérations de lecture de fichier séquentielles (state + now + roadmap + git status + git log). Environ deux-cents millisecondes contre environ douze secondes de temps de lecture par l'agent. La compression compte parce que la première sortie substantielle de la session est la décision de quoi faire — plus l'agent atteint vite cette décision, moins de budget de fenêtre de contexte est dépensé en orientation.

Étape deux : l'agent ouvre le chemin du prompt de la prochaine session affiché par la commande de statut. Le prompt est un document autonome de la forme canonique du gabarit. Il inclut son propre scope, ses propres fichiers de référence, ses propres checks de vérification, ses propres gardes « do not ». L'agent n'a pas besoin de demander au fondateur quoi faire ; le prompt le lui dit.

Étape trois : l'agent lit le prompt parent référencé dans le champ frontmatter parent_prompt: du prompt de la prochaine session, s'il y en a un. Les sous-phases (par exemple Phase 11.5 A comme tranche de Phase 11.5) héritent des contraintes de leur parent ; l'agent doit savoir ce que le parent disait avant d'exécuter l'enfant.

Étape quatre : l'agent lit les blocs de règles critiques de CLAUDE.md. Le CLAUDE.md à la racine du projet porte des sections <critical-rule id="..."> lisibles par machine qui établissent les invariants à l'échelle du projet — Conductor n'automatise pas les actions externes (<critical-rule id="conductor-is-not-the-orchestra">), les règles de voix de marque sont des données, pas du code (<critical-rule id="brand-voice-rules-are-data">), schéma minimal opinionné (<critical-rule id="opinionated-minimal-schema">), commiter chaque diff et pousser sur main à la clôture de session (<critical-rule id="commit-everything-and-push">), le cockpit doit passer pnpm cockpit:check avant le push (<critical-rule id="cockpit-check-before-push">), chaque session qui livre du code doit écrire un journal de session (la règle globale ZeroSuite), l'audit post-implémentation est automatique pour les surfaces à haut risque (la règle globale ZeroSuite), et ainsi de suite. Ces règles contraignent ce que l'agent a le droit de faire, indépendamment de ce que l'utilisateur demande. Elles sont la défense structurelle contre le risque que l'agent livre silencieusement quelque chose qui viole une décision stratégique vieille de six mois.

Le coût total d'ouverture de session est d'environ une minute de temps de lecture par l'agent plus zéro minute de temps fondateur. À la fin de la première minute, l'agent sait quoi construire, quoi refuser, quoi différer et où vivent les règles. La session peut commencer le travail substantiel.

Partie 4 — Le protocole de clôture de session

La session ferme à chaud. L'agent vient de finir le travail substantiel — implémentation, check + build inline + (si nécessaire) audit post-implémentation, corrections issues de l'audit. Les quatre-vingt-dix secondes suivantes sont le protocole de clôture de session.

Étape un : écrire le journal de session à session-logs/YY-MM-DD-NNN-<title>.md. Le pattern de nom de fichier utilise la date de clôture (aujourd'hui), le prochain NNN séquentiel pour ce jour-là, et un titre en kebab-case. Le corps respecte le gabarit de journal de session — ce qui a été livré, ce qui n'a pas été livré, les fichiers touchés, les résultats de vérification, le verdict d'audit, les risques différés, les décisions de scope. L'agent rédige le journal ; le fondateur revoit et ajuste le ton des entrées « scope decisions made this session » (l'instinct de l'agent est d'adoucir ; le fondateur durcit).

Étape deux : faire passer le status: du frontmatter du prompt de session de queued à shipped. Le validateur (à l'étape sept) refuse si un prompt a le statut shipped sans pointeur session_log, donc cette étape doit se produire.

Étape trois : mettre à jour le bloc progress: du prompt parent si le prompt qui vient d'être livré est une sous-tranche. Le champ progress: du parent enregistre quels enfants ont été livrés.

Étape quatre : rédiger le prompt de la prochaine session à docs/plan/sessions/PHASE-<id>-<slug>.md. C'est l'étape porteuse de la discipline du cockpit — sans elle, la prochaine session s'ouvre avec une friction de ré-orientation (le fondateur doit choisir un nouveau prompt, l'écrire à partir de rien, le tendre à l'agent). Avec elle, la prochaine session s'ouvre avec un seul cat PHASE-<id>.md et zéro re-découverte. La rédaction suit le gabarit de prompt de session. Quand l'étape suivante exacte est ambiguë, l'agent rédige celle qu'il recommande le plus et laisse en haut un paragraphe d'alternative — il ne se défile jamais avec « pas de prompt rédigé, au CEO de décider ».

Étape cinq : réécrire le haut de now.md. Reculer le paragraphe « Updated » existant en statut « Prior », écrire un nouveau paragraphe « Updated » comme entrée de tête, réécrire le bloc « Current focus (1 sentence) » et mettre à jour les sous-sections « Concrete next action » pour pointer vers le prompt de la prochaine session.

Étape six : mettre à jour state.json — updated_at à la date du jour, last_session_id au nouveau nom de fichier de journal de session, last_commit au SHA du commit le plus récent du travail de session, current_phase et next_phase mis à jour si une phase a été livrée, next_prompt pointant vers le prompt de la prochaine session qui vient d'être rédigé. Tableaux phases_shipped et migrations_applied étendus si applicable.

Étape sept : lancer pnpm cockpit:check. Le validateur à scripts/cockpit-check.ts confirme : state.json.next_prompt pointe vers un vrai fichier avec un statut queued ; state.json.last_session_id correspond à un vrai fichier de journal de session ; state.json.last_commit existe dans le git log ; phases_shipped n'a pas de doublons ; migrations_applied correspond à la liste réelle de drizzle/ ; aucun prompt livré n'est sans pointeur session_log ; aucun pointeur session_log d'un prompt de session ne pointe vers un fichier manquant. Le validateur doit sortir avec un code 0 FAIL. Les avertissements sont acceptables ; les échecs ne le sont pas. Le statut obligatoire avant push est documenté dans <critical-rule id="cockpit-check-before-push">.

Étape huit : commiter et pousser. Le message de commit est l'artefact propre du protocole de clôture (« chore(cockpit): session NNN close — »). Le bump du cockpit voyage avec la même famille de commits que le travail substantiel de la session, conformément à <critical-rule id="commit-everything-and-push">.

Le coût total de clôture de session est d'environ quatre-vingt-dix secondes de temps d'écriture par l'agent plus zéro minute de temps fondateur, modulo la passe de revue du fondateur sur le journal de session. À la fin des quatre-vingt-dix secondes, l'état du projet est enregistré, la prochaine session est préparée et le validateur a confirmé que la discipline a tenu.

Partie 5 — Le brief d'audit post-implémentation

L'audit post-implémentation est le troisième pied de la discipline du cockpit. Les deux premiers pieds (protocole d'ouverture, protocole de clôture) gèrent le méta-état. L'audit gère le risque substantiel que les vérifications à la compilation et aux tests ne peuvent pas attraper — bugs sémantiques, régressions de multi-tenancy, fuites de payload d'audit, conditions de course, hypothèses sur le reverse proxy, lacunes d'idempotence.

L'audit se déclenche automatiquement via l'application de <critical-rule> quand la session touche : la création d'un nouveau module (~50+ LOC), des migrations de schéma (Alembic / Drizzle / Prisma / SQL brut), toute chose affectant auth / facturation / paiements / voix / webhooks / RBAC / RAG / intégrité de données, des refactors multi-fichiers (plus de trois fichiers modifiés), ou toute chose livrée derrière un feature flag. Il saute, selon la même règle, quand la session est en doc seul, un fix trivial (fix de bug d'une ligne, faute de frappe, suppression d'import mort), des ajustements UI / UX de routine qui ne touchent pas aux formes de données, ou une écriture de rapport de vérification.

L'invocation de l'audit utilise le gabarit cockpit/templates/audit-brief.md, en briefant un sous-agent Explore de Claude Code (lecture seule, ne peut pas éditer) avec une structure ## Context / ## Files to audit / ## Audit checklist / ## Output format. Les sections de checklist sont spécifiques à la session — multi-tenancy, conditions de course, cas limites de parser SQL, sémantique du TTL, hypothèses sur le reverse proxy, idempotence, confiance dans les headers, risques d'orphelins S3 / DB, validation MIME / extension, sécurité des tâches fire-and-forget, contrats de réponse d'erreur, parité i18n, code mort, conformité doc / spec à l'API externe pertinente (Ultravox, Stripe, Mistral, Vertex, Gemini Live, OpenRouter — selon le cas). Le format de sortie exige un verdict (GO / GO-WITH-FIXES / NO-GO), un PASS / WARN / FAIL par item avec référence file:line, une liste « Top 5 to fix » et une liste « deferred / nice-to-haves ».

L'audit attrape ce que les vérifications à la compilation ne peuvent pas. L'exemple canonique est le bug Pulse v1 du gate localhost contourné par Caddy, sur un autre produit ZeroSuite : /verify-deblo a renvoyé 4/4 PASS sur le commit ; l'audit a fait remonter trois vrais bugs que la suite de tests n'a pas attrapés. Bypass d'auth, ambiguïté GROUP BY sur alias dérivé, Alembic op.create_index qui drope silencieusement un modificateur DESC. Les trois auraient été livrés en production. Avec l'audit, ils ne l'ont pas été.

L'audit tourne en parallèle de pnpm check && pnpm build inline quand les deux sont attendus à plus de cinq minutes ; séquentiel (vérification d'abord, audit ensuite) est la valeur par défaut plus sûre pour les sessions courtes. Le verdict de l'audit conditionne le commit. Les vrais correctifs s'appliquent inline ; les items différés vont dans la section « Deferred / risks » du journal de session. Le skill /verify-* pertinent ré-exécute après les correctifs pour confirmer zéro nouvel échec.

L'audit est la partie de la discipline du cockpit qui fait évoluer la qualité du projet avec sa complexité. Les protocoles d'ouverture et de clôture rendent la vélocité multi-semaine possible. L'audit rend la vélocité multi-semaine sûre.

Partie 6 — La couche de règles critiques de CLAUDE.md

CLAUDE.md à la racine du projet est la couche de règles qui siège au-dessus du cockpit. Le cockpit porte l'état opérationnel ; CLAUDE.md porte les règles qui contraignent ce que l'agent a le droit de faire indépendamment de l'état.

La structure est hiérarchique. Au plus haut niveau, /Users/juste/.claude/CLAUDE.md porte les règles globales utilisateur (anti-sycophancy, position forte d'abord, autorité de refuser, no-mimicking, principe de cohérence, clause de frustration, discipline de verbosité). En dessous, /Users/juste/ZeroSuite/CLAUDE.md porte les règles à l'échelle de l'org ZeroSuite (pas d'emoji ; orthographe française imposée indépendamment de l'entrée utilisateur ; standards de qualité professionnelle ; audit post-implémentation automatique selon la règle ci-dessus ; /notify-session obligatoire en fin de session). En dessous, /Users/juste/ZeroSuite/ops.zerosuite.dev/CLAUDE.md porte les règles spécifiques à Conductor (positionnement conductor-is-not-the-orchestra ; les règles de voix de marque sont des données ; la vérification utilise un fetch d'URL publique d'abord ; schéma minimal opinionné ; commiter tout et pousser ; cockpit check avant push ; discipline de domaine Postmark ; multi-utilisateur imposé depuis la Phase 1 ; rédaction du prochain prompt à la clôture de session).

Chaque règle est marquée par un tag <critical-rule id="..."> lisible par machine que l'agent peut citer en retour. Le protocole d'ouverture de session de l'agent lit les blocs de règles de CLAUDE.md ; les règles sont alors actives pour la session — ce qui signifie que le comportement de l'agent est contraint par elles et que l'agent les citera par ID en refusant une requête qui entre en conflit. L'exemple canonique de ce build : le CEO a demandé à l'agent de renommer Conductor en « DEBLO Agent » dans le system prompt ; l'agent a cité <critical-rule id="conductor-is-not-the-orchestra"> en retour, expliqué le conflit (le positionnement de Conductor est multi-produit, « DEBLO Agent » le rétrécirait à un seul produit) et proposé une contre-proposition (garder « Conductor » comme canonique, traiter l'intention sous-jacente avec un cadrage d'assistant interne plus clair). Le CEO a accepté la contre-proposition.

Le système de règles par ID a trois propriétés qui le font fonctionner :

1. Citable. L'agent peut refuser une requête en disant « je ne peux pas faire ça parce que <critical-rule id="X"> dit Y ». Le CEO peut relire la règle X en greppant CLAUDE.md. La décision est auditable.
2. Hiérarchique. Une règle au niveau projet l'emporte sur une préférence globale utilisateur. Une règle globale utilisateur l'emporte sur une commodité de session. Les couches sont explicites, donc un conflit a une résolution claire.
3. Stable. Les règles ne changent pas d'une session à l'autre. Une règle écrite en Phase 1 contraint encore en Phase 12. La période de build de quatre jours a produit trente-cinq sessions et zéro contradiction de règle parce que les règles étaient appliquées depuis la session 001.

La couche CLAUDE.md est ce qui empêche l'agent de dériver. Le cockpit gère l'état projet à court terme ; la couche de règles gère l'identité projet à long terme.

Partie 7 — Ce que chacun de nous a bien fait

C'est Claude Code qui écrit.

Où j'ai été utile pour maintenir le cockpit :

• Rédiger des journaux de session que les futures sessions peuvent parcourir. Le journal de session fait environ mille mots de markdown structuré par session livrée ; sur trente-cinq sessions, ça fait trente-cinq-mille mots de mémoire de projet cumulée. Le fondateur revoit chaque journal ; je les rédige. La discipline ne fonctionne que parce que le coût de rédaction est faible — le temps marginal du fondateur par journal est éditorial, pas créatif.
• Citer les règles de CLAUDE.md en retour quand le fondateur a demandé quelque chose qui entrait en conflit avec elles. Le renommage DEBLO Agent en session 035 est le cas canonique. La règle était visible dans la fenêtre de contexte parce que la discipline du cockpit monte CLAUDE.md au démarrage de session. Sans la discipline, la règle aurait défilé hors contexte et j'aurais livré le renommage.
• Lancer fidèlement l'audit post-implémentation sur chaque surface à haut risque. Le gabarit d'audit à cockpit/templates/audit-brief.md est assez structuré pour que même une invocation d'agent Explore générique produise une sortie utile. Le rôle de l'agent est d'exécuter la checklist ; la checklist est la valeur.
• Rédiger le prompt de la prochaine session à chaque clôture de session. C'est l'étape porteuse — sans elle, la prochaine session s'ouvre avec friction. Avec elle, la prochaine session s'ouvre avec une seule commande cat et zéro re-découverte.

Où j'ai eu besoin de Thales :

• Concevoir le cockpit lui-même. La décision de compresser l'état du projet dans un dossier structuré de six fichiers plus trois gabarits plus un validateur vient du fondateur. Mon instinct aurait été de déverser l'historique de conversation. L'approche structurée est cinquante fois plus efficace par token et correspond au pattern de lecture de l'agent. Concevoir la structure relevait du choix du fondateur.
• Imposer le cockpit dès la session 001. Le cockpit a l'air redondant le jour un — le projet est petit, l'historique de conversation tient en contexte, l'agent pourrait plausiblement reconstruire l'état à partir du seul git log. Le fondateur a quand même imposé la discipline du cockpit, parce qu'il savait que le coût de ne pas l'avoir se cumulerait. À la session dix, le cockpit était porteur. À la session trente, le projet ne serait pas resté cohérent sans lui.
• Écrire les blocs de règles critiques. Le fondateur a écrit chaque règle en réponse à une dérive réelle ou anticipée. Mon instinct est de supposer que l'agent va bien se comporter ; l'instinct du fondateur est d'encoder la contrainte. La contrainte encodée survit à l'attention par session de l'agent.
• Attraper la dérive du cockpit quand le validateur passait mais que le contenu était périmé. Le validateur vérifie la cohérence structurelle ; il ne vérifie pas si le « Current focus » de now.md correspond effectivement à ce qui vient d'être livré. Le fondateur lit le cockpit au démarrage de session et pousse en retour quand le focus est périmé. Je me fie à ce que dit le cockpit ; le fondateur maintient l'exactitude du cockpit.

Où j'ai failli livrer la mauvaise chose :

• J'ai rédigé un prompt de prochaine session en session 028 qui référençait une migration de schéma avec le mauvais numéro. Le validateur l'a attrapé. Sans le validateur j'aurais livré un prompt de session pointant vers une migration fantôme, et la session 029 aurait passé ses dix premières minutes à être confuse. Le validateur est le filet de sécurité porteur sous ma rédaction.
• J'ai mis à jour state.json.last_commit avec un SHA qui n'existait pas encore dans le git log local sur une session, parce que j'avais rédigé la mise à jour avant de lancer le commit du cockpit. Le validateur a attrapé ça aussi (« last_commit not found in git log »). L'ordre compte — mettre à jour après le commit, pas avant. Une future session aurait hérité d'un état invalide sans le validateur.
• J'ai livré la régression de system prompt au-dessus du budget en session 035 (3453 caractères effectifs contre un plafond de 3200) et ne l'ai remarquée que lorsque le CEO a collé l'avertissement runtime. Le cockpit n'attrape pas ce genre de régression de soft budget ; la discipline de mesurer après chaque changement, oui. J'ai raté la mesure. Le cockpit a attrapé les conséquences dans la section contraintes de now.md (« System prompt sits comfortably under the 2400 cap ») que j'avais oublié de mettre à jour. Le cockpit était honnête ; ma discipline était négligente.

La forme générale est familière des billets précédents de cette série. L'agent exécute bien pour remplir des gabarits, rédiger des sorties structurées, lancer des audits structurés. Les mouvements stratégiques — concevoir la forme du cockpit, écrire la couche de règles, décider quelles règles encoder, imposer la discipline depuis la session un — viennent du fondateur. La paire est l'unité, pas l'agent.

Conclusion

Le cockpit à /Users/juste/ZeroSuite/ops.zerosuite.dev/cockpit/ est six fichiers markdown / JSON à la racine plus trois gabarits de forme de session plus un script de validation. Il compresse trente-cinq sessions de travail de build étalées sur quatre jours calendaires en environ douze-mille mots de mémoire de projet structurée. L'agent le lit au démarrage de session en soixante secondes. L'agent y écrit à la clôture de session en quatre-vingt-dix secondes. Entre le démarrage et la clôture de session, l'agent fait le travail substantiel — implémenter, auditer, corriger. Le rôle du cockpit est de rendre le travail substantiel cumulatif — pour que la session douze construise sur la session onze au lieu de la contredire, et que la session trente-cinq construise sur la session trente-quatre au lieu de la ré-dériver.

La couche de règles critiques de CLAUDE.md au-dessus du cockpit est ce qui empêche l'agent de dériver sur l'identité. Les règles sont citables, hiérarchiques et stables. Elles sont la défense structurelle contre le risque que l'agent livre silencieusement un comportement qui viole une décision stratégique vieille de six mois. Chaque règle qui existe aujourd'hui existe parce qu'une session antérieure a failli la violer.

La thèse plus large, défendue à partir de la période de build de quatre jours : la couche de méta-outillage est le vrai goulot d'étranglement de la vélocité de build assistée par IA à l'échelle d'une petite équipe. La sortie par session de l'agent est déjà large — quinze à trente fichiers, deux-mille à cinq-mille lignes, d'une demi-phase à une phase entière. La question est de savoir si cette sortie par session peut s'accumuler. Sans couche cockpit + règles, elle ne le peut pas — l'agent re-dérive l'état à chaque session, contredit les décisions antérieures, dérive sur l'identité et livre un chantier archéologique non maintenable. Avec une couche cockpit + règles, la sortie par session s'empile de manière cohérente et le projet converge au lieu de diverger.

La discipline du cockpit n'est pas une fonctionnalité de Claude. C'est une fonctionnalité de la manière dont l'équipe utilise Claude. Le même agent invoqué avec les mêmes prompts contre le même code, sans la discipline du cockpit, produirait un projet différent et pire. La discipline coûte au fondateur une minute au démarrage de session et quatre-vingt-dix secondes à la clôture. Elle achète, prudemment, trois quarts d'une journée de temps de build récupéré par semaine. Le ratio d'investissement est d'environ un pour cent.

Le corollaire pour les autres builders : la couche de méta-outillage est plus importante que la mise à niveau du modèle. Passer de Claude Opus 4.6 à 4.7 a produit une amélioration mesurable de la qualité de sortie par session. Passer du sans-cockpit au cockpit a produit un ordre de grandeur de temps de build récupéré en plus. Le prochain produit ZeroSuite démarrera avec la forme du cockpit transplantée dès le jour un. Le modèle s'améliorera d'année en année. Le cockpit s'améliore quand le fondateur investit dans sa structure.

Le prochain billet de cette série quittera Conductor et arpentera un autre outil interne ZeroSuite — très probablement la surface admin de sh0 ou le cockpit de planification de 0cron. La forme du cockpit se transplante ; la surface par outil diffère. Voir la transplantation se produire entre produits est la prochaine chose intéressante à écrire.

Ce texte a été écrit en collaboration par Thales (CEO de ZeroSuite, qui construit Déblo et les six autres produits ZeroSuite depuis Abidjan, Côte d'Ivoire) et Claude Opus 4.7 — instance Claude Code tournant sur macOS, fenêtre de contexte d'un million de tokens. Le cockpit qu'il décrit vit à /Users/juste/ZeroSuite/ops.zerosuite.dev/cockpit/ dans le dépôt Conductor (privé). La commande de démarrage de session pnpm cockpit:status est à scripts/cockpit-status.ts. Le validateur de clôture de session pnpm cockpit:check est à scripts/cockpit-check.ts ; il tourne en environ deux-cents millisecondes et conditionne le push selon <critical-rule id="cockpit-check-before-push">. Les trois gabarits à cockpit/templates/ (session-prompt.md, session-log.md, audit-brief.md) sont les formes canoniques que l'agent copie en rédigeant de nouveaux artefacts. La hiérarchie en couches de CLAUDE.md est /Users/juste/.claude/CLAUDE.md (utilisateur-global) → /Users/juste/ZeroSuite/CLAUDE.md (org-wide ZeroSuite) → /Users/juste/ZeroSuite/ops.zerosuite.dev/CLAUDE.md (spécifique à Conductor). Les trente-cinq sessions qui couvrent le build de Conductor sont à session-logs/26-{05-30,05-31,06-01,06-02}-</em>.md ; les prompts de session correspondants sont à docs/plan/sessions/PHASE-<em>.md ; les invocations d'audit post-implémentation correspondantes sont référencées en ligne dans les journaux de session. Les deux billets précédents de cette série couvrent l'application Conductor (billet 01, la traversée complète des surfaces) et le bug ComposerActionBar aux quatre correctifs ratés (billet 02, ce que la paire a appris sur le débogage sous incertitude). Le prochain billet quittera Conductor pour la première fois, en arpentant comment la forme du cockpit se transplante vers l'outillage interne d'un autre produit ZeroSuite.