DEV Community: Michel Faure

Why I stopped reading my own backlog.md (and what I read instead)

Michel Faure — Fri, 19 Jun 2026 15:48:22 +0000

The morning my own file lied to me

Wednesday, May 21, start of session, coffee next to the keyboard. I ask the agent where we stand on the DEV.to series. Clean answer, articulated, "Four articles on stand-by, ready to publish." I reread. Half a second of unease, because I think I saw two or three of them go through DEV.to last week, but I slept in between and I'm no longer sure. I type the question that changes everything, "Are you sure articles remain to publish?" The agent re-queries the DEV.to API in parallel, opens scripts/devto/state.json, crosses the two. The four articles have been published for two or three days.

What I just read wasn't a hallucination. The agent did exactly what was expected of it, namely open articles/backlog.md, read the table, restitute what it said. I'm the one who had stopped updating that file. sync-backlog.ts hadn't run after the pushes of last week. The markdown said "stand-by" while production said "published". The typist didn't lie. She read faithfully a file I had written myself and that I was treating as authority while nothing was maintaining it.

A summary is a Cache without a refresher

This is the most common failure mode of a solo project that lasts. Each day produces two flows. On one side the matter that moves, made of commits, deploys, rows in the database, statuses that transition. On the other side the writings we draft to keep our bearings, namely backlog.md, the root MEMORY.md, the Sunday-night session note, the README of the folder we refactored last week. These writings are produced quickly, in the gesture that closes a sprint, and they are maintained slowly, or not at all, because nothing in the pipeline triggers to close them.

R6 of the Counterpart Toolkit says it for SQL columns, Live / Snapshot / Cache mandatory. Any column derivable from other data must declare its category in the commit that creates it. If it's a Cache, the refresher mechanism (GENERATED ALWAYS AS, SQL trigger, materialized view with planned REFRESH) ships in the same commit. No category declared, no commit.

backlog.md is exactly the same logical object. Its value is derivable from state.json plus a few editorial constants. sync-backlog.ts is its applicative trigger. Without a call, the Cache drifts.

What I read instead

R2, Filesystem over summary, codifies the gesture since May 15. Before any status report, four shell commands, in this order. The markdown comes last, and it comes as draft thinking, never as a source.

git log --since='7d' --oneline
git status --porcelain
ls docs/adr/ | wc -l
cat scripts/devto/state.json | jq 'to_entries|map(select(.value.published))|length'

The result reads in three seconds. If something surprises me, a commit I had forgotten or one more ADR than memory expected, I dig there, not in backlog.md. When I do read the markdown, I read it with the implicit question "who updated it, when", and if the answer doesn't come out of git log in fifteen seconds, I treat it as rotten Cache.

Coda

A summary that doesn't say when it was produced, and by what mechanism, says nothing. Either you declare its refresher in the commit that creates it, be it a script, a trigger, a cron, and it lives as a managed Cache, or you stop treating it as a source and it goes back to being a draft. R6 says the rule for the database. R2 says the same rule for the writings you address to yourself. An agent that opens backlog.md before git log is not a bad agent, it's an agent that faithfully executes a human gesture that should have been forbidden upstream. The morning of May 21, it wasn't the agent that lied to me, it was my own typist who, the night before, hadn't closed the note.

Counterpart Toolkit v0.7, rule R2 — Filesystem over summary. Extracted from R1 in v0.4.1, promoted in its own right. Current version of the toolkit lives in CC-BY-4.0 on github.com/michelfaure/doctrine-counterpart.

Quick Win Card #04 — Le test contrat de 15 lignes qui déverrouille les refacto de schéma sans peur

Michel Faure — Wed, 17 Jun 2026 12:58:00 +0000

L'accroche

Premier triptyque : trois cartes sur ce qui ment — fichier, compteur, contexte du délégué. Trois hooks défensifs qui forcent l'observable à reparler. Deuxième triptyque, qui s'ouvre ici : non plus ce qui ment, mais ce que ça déverrouille. Quand la défiance est ritualisée, l'audace devient possible. Carte #04 : un test contrat de quinze lignes qui transforme la refacto de schéma — opération qu'on évitait par peur de manquer une référence — en geste banal qu'on fait avant le café.

Ce qui était bloqué

Pendant six semaines, je traînais un renommage évident. Le statut métier eleve aurait dû s'appeler inscrit depuis le début — eleve couvre les anciens, les liste rouge, les sans-réponse, c'est trop large. Mais le statut était utilisé dans la CHECK constraint Postgres, dans une constante TypeScript, dans douze composants UI, dans trois exports Brevo, dans quatre vues SQL, dans deux scripts batch. Un grep en aveugle = oubli garanti. Une PR de renommage = peur du silent break en prod.

La peur n'était pas irrationnelle. Le 11 mai, un import HubSpot avait introduit un statut suspect que la CHECK constraint refusait. Le code TS ne le savait pas — il consommait silencieusement les exceptions Postgres comme des erreurs réseau. Symptôme : trois imports échouent en prod, aucune alerte parce que le try / catch avalait tout. Diagnostic deux jours plus tard. Si je renommais eleve sans synchroniser DB et TS, j'allais reproduire exactement la même classe de drift.

Le test contrat qui déverrouille

À poser dans tests/contracts/statuts.contract.test.ts. Quinze lignes Jest qui font une seule chose : grep la CHECK constraint Postgres, comparer aux valeurs déclarées en constante TypeScript, échouer le build avec un message qui te dit exactement où la dérive est apparue.

import { CONTACT_STATUT_VALID } from '@/lib/contacts'
import { createSupabaseAdmin } from '@/lib/supabase-admin'

test('contacts.statut: DB CHECK matches TS whitelist', async () => {
  const { data } = await createSupabaseAdmin().rpc('introspect_check_values', {
    p_table: 'contacts', p_column: 'statut',
  })
  const db = new Set(data as string[])
  const ts = new Set(CONTACT_STATUT_VALID)
  const dbOnly = [...db].filter(v => !ts.has(v))
  const tsOnly = [...ts].filter(v => !db.has(v))
  if (dbOnly.length || tsOnly.length) {
    throw new Error(`Drift: DB-only=[${dbOnly}], TS-only=[${tsOnly}]`)
  }
})

Le diff de sets est ce qui rend le message d'erreur utile à l'échelle. Avec cinq valeurs ça paraît over-engineered, avec trente l'énumération brute devient illisible et masque exactement ce que le test devrait pointer. Le message Drift: DB-only=[suspect], TS-only=[en_attente] te dit en deux mots où corriger. La fonction introspect_check_values est une RPC Postgres de trois lignes qui parse pg_get_constraintdef en regex ; tu peux aussi la remplacer par un SELECT direct sur pg_constraint si tu préfères tout en SQL.

Ce que ça déverrouille concrètement

Le pattern n'économise pas du temps sur le test lui-même — il coûte quinze lignes à écrire. Le gain est ailleurs, en aval, sur les refacto que tu n'avais plus envie de tenter. Avec ce test dans la CI, le renommage eleve → inscrit s'est fait en trente minutes : changement de la migration DB, changement de la constante TS, push. CI rouge si l'un des deux côtés a oublié l'autre, avec un message qui te dit exactement quelle valeur manque où. Tu corriges, tu repushes, CI vert. La refacto cross-fichier n'est plus un acte de bravoure, c'est un workflow.

Au-delà du renommage, le test ouvre toute une catégorie d'opérations que la peur fermait : ajouter un statut sans risquer d'oublier la TS, retirer un statut sans risquer un crash silencieux à l'INSERT, fusionner deux statuts en un seul avec contrôle automatique du périmètre. Tout ce que tu hésitais à faire parce que « je vais peut-être casser quelque chose ailleurs » devient borné par un message d'erreur explicite. La doctrine défensive du triptyque 1 produit ici son rendement positif : la confiance n'est pas dans l'outil, elle est dans le filet matériel sous l'outil. Tu peux sauter parce que tu as vu le filet de tes propres yeux.

À appliquer maintenant

Identifie dans ton projet une constante TypeScript qui doit matcher une CHECK constraint Postgres (ou un enum DB, ou une whitelist applicative quelconque). Copie le template ci-dessus, adapte le nom de table et de colonne, écris la RPC d'introspection de trois lignes en SQL. Pousse le test dans la CI. La prochaine fois que tu hésites à renommer ou modifier cette colonne, regarde le test. Il fait le grep pour toi. Tu n'as plus à le faire dans ta tête. La refacto que tu repoussais depuis six semaines devient une PR du vendredi après-midi.

Et quand tu délègues la refacto à un sub-agent (cf. QW-03), le test en CI attrape ce que ton brief aurait pu manquer. Le filet tient autant pour ton délégué que pour toi.

Ton quick win tient en cinq minutes — celles qu'il faut pour copier le test, adapter le nom de constante, ajouter la RPC d'introspection. La doctrine du triptyque 1 t'apprenait à te défier des résumés ; celle du triptyque 2 t'apprend à utiliser cette défiance pour t'autoriser ce que tu te refusais.

Quick Win Card series, épisode 04. Ouverture du 2e triptyque : ce que la doctrine déverrouille. Référence ADR-0044 (tests contrat DB↔code) — repo doctrine : github.com/michelfaure/doctrine-counterpart. Suite triptyque pressentie : QW-05 sur le tag [spike] qui déverrouille le prototypage sans dette, QW-06 sur le brief inline qui déverrouille la délégation.

Quick Win Card #04 — The 15-line contract test that unlocks fearless schema refactors

Michel Faure — Wed, 17 Jun 2026 12:57:44 +0000

The hook

First triptych: three cards on what lies — status file, counter, delegate's context. Three defensive hooks that force the observable to speak. Second triptych, opening here: no longer what lies, but what it unlocks. When distrust is ritualised, audacity becomes possible. Card #04: a fifteen-line contract test that turns schema refactor — the operation you avoided out of fear of missing a reference — into a routine gesture you do before coffee.

What was blocked

For six weeks, I dragged an obvious rename. The domain status eleve (French for "student") should have been called inscrit ("enrolled") from day one — eleve covers former students, blocked accounts, no-response leads, it's too broad. But the status was used in the Postgres CHECK constraint, in a TypeScript constant, in twelve UI components, in three Brevo exports, in four SQL views, in two batch scripts. A blind grep = guaranteed miss. A rename PR = fear of silent break in production.

The fear wasn't irrational. On May 11, a HubSpot import introduced a status suspect that the CHECK constraint refused. The TS code didn't know — it was silently swallowing Postgres exceptions as network errors. Symptom: three imports fail in prod, no alert because the try / catch swallowed everything. Diagnosis two days later. If I renamed eleve without syncing DB and TS, I'd reproduce the exact same drift class.

The contract test that unlocks

Drop in tests/contracts/statuts.contract.test.ts. Fifteen lines of Jest doing one thing: grep the Postgres CHECK constraint, compare to the values declared in a TypeScript constant, fail the build with a message that tells you exactly where the drift appeared.

import { CONTACT_STATUT_VALID } from '@/lib/contacts'
import { createSupabaseAdmin } from '@/lib/supabase-admin'

test('contacts.statut: DB CHECK matches TS whitelist', async () => {
  const { data } = await createSupabaseAdmin().rpc('introspect_check_values', {
    p_table: 'contacts', p_column: 'statut',
  })
  const db = new Set(data as string[])
  const ts = new Set(CONTACT_STATUT_VALID)
  const dbOnly = [...db].filter(v => !ts.has(v))
  const tsOnly = [...ts].filter(v => !db.has(v))
  if (dbOnly.length || tsOnly.length) {
    throw new Error(`Drift: DB-only=[${dbOnly}], TS-only=[${tsOnly}]`)
  }
})

The set diff is what makes the error message useful at scale. With five values it feels over-engineered; with thirty, the raw enumeration becomes unreadable and hides exactly what the test should pinpoint. The message Drift: DB-only=[suspect], TS-only=[en_attente] tells you in two words where to fix. The introspect_check_values function is a three-line Postgres RPC that parses pg_get_constraintdef with regex; you can also replace it with a plain SELECT on pg_constraint if you prefer staying in SQL.

What it unlocks concretely

The pattern doesn't save time on the test itself — it costs you fifteen lines to write. The gain is downstream, on the refactors you no longer felt like attempting. With this test in CI, the eleve → inscrit rename took thirty minutes: change the DB migration, change the TS constant, push. CI red if either side forgot the other, with a message that tells you exactly which value is missing where. You fix, you repush, CI green. The cross-file refactor stops being an act of bravery; it becomes a workflow.

Beyond rename, the test opens a whole category of operations that fear used to close off: adding a status without risking the TS oversight, removing a status without risking a silent INSERT crash, merging two statuses into one with automatic perimeter control. Anything you hesitated to do because "I might break something else somewhere" becomes bounded by an explicit error message. The defensive doctrine of triptych 1 produces here its positive yield: the trust isn't in the tool, it's in the material net under the tool. You jump because you saw the net with your own eyes.

Apply now

Identify in your project a TypeScript constant that must match a Postgres CHECK constraint (or a DB enum, or any application whitelist). Copy the template above, adapt the table and column name, write the three-line introspection RPC in SQL. Push the test into CI. Next time you hesitate to rename or modify that column, look at the test. It does the grep for you. You don't have to do it in your head anymore. The refactor you'd been pushing for six weeks becomes a Friday afternoon PR.

And when you delegate the refactor to a sub-agent (cf. QW-03), the test in CI catches what your brief might have missed. The net holds for your delegate as much as for you.

Your quick win takes five minutes — the time to copy the test, adapt the constant name, add the introspection RPC. The doctrine of triptych 1 taught you to distrust summaries; that of triptych 2 teaches you to use that distrust to permit yourself what you used to forbid.

Quick Win Card series, episode 04. Opening of the 2nd triptych: what doctrine unlocks. Reference ADR-0044 (DB↔code contract tests) — doctrine repo: github.com/michelfaure/doctrine-counterpart. Foreseen sequel triptych: QW-05 on the [spike] tag that unlocks prototyping without debt, QW-06 on the inline brief that unlocks fearless delegation.

Quick Win Card #03 — Ton sub-agent n'a jamais lu ton MEMORY.md (l'en-tête de brief en 5 lignes qui répare ça)

Michel Faure — Mon, 15 Jun 2026 12:42:53 +0000

L'accroche

QW-01 disait : ton fichier d'état ment. QW-02 disait : ton compteur ment. Voici la troisième couche : ton sub-agent ignore ce que toi tu sais. Pas par malice, par construction. Le contexte qu'il reçoit, c'est ton brief, point. Pas ton MEMORY.md, pas tes feedbacks user-scope, pas la doctrine que tu as accumulée en 70 jours. Tu lui parles comme à un collègue qui a relu le wiki, alors qu'il vient d'arriver et n'a jamais ouvert la page.

Ce qui a cassé

18 mai, fin d'après-midi. Je délègue six fichiers à mon sub-agent ERP — autosend premier contact, ADR-0072. Brief en trois paragraphes : contexte, livrables, phase 0 grep d'audit avant tout INSERT. Court, propre, ce que je donnerais à un humain qui connaît le projet.

Quarante-cinq minutes plus tard, le rapport arrive. Je grep mon git log par réflexe : commit 3756e63 parti sur main, six fichiers, sept cent trente insertions, sans branche feature, sans pull request. Trente minutes de cherry-pick pour rattraper. Et la règle qui aurait dû empêcher ça — feedback_git_branch_check_avant_commit — était bien dans ~/.claude/agent-memory/, scope user, indexée dans mon MEMORY.md. Je la consulte mécaniquement avant chaque commit non-trivial depuis l'incident du 14 mai. Elle ne m'a pas trahi. Elle n'a juste jamais atteint le délégué.

La leçon est plus inconfortable que les deux premières cartes. Tu peux construire la doctrine la plus rigoureuse du monde, l'indexer, la versionner, la backporter entre projets — si le brief que tu envoies au sub-agent ne la cite pas explicitement, elle est effectivement absente. La mémoire user-scope ne se transmet pas par filiation. Le sub-agent n'est pas un héritier, c'est un sous-traitant qui n'a pas lu ton wiki.

Une objection légitime ici : la protection de branche côté repo GitHub aurait aussi attrapé le commit sur main. C'est vrai pour cet exemple-là. Mais la doctrine doit tenir même dans les repos où tu n'as pas câblé la protection, et surtout, les deux autres feedbacks de l'exemple ci-dessous (probe DB avant DELETE, audit inscriptions.source) n'ont pas d'équivalent en garde-fou serveur. C'est précisément la catégorie qu'il faut couvrir par le brief, parce qu'aucune autre couche ne le fera.

L'en-tête de brief qui ferme la classe

À coller en tête de tout brief sub-agent qui touche du code applicatif, dure plus de trente minutes, ou délègue une décision qui pourrait casser une règle silencieuse. Trois à cinq feedbacks load-bearing (dans le vocabulaire Counterpart, un feedback = une règle codifiée à partir d'un incident passé, stockée dans MEMORY.md, nommée par un slug stable).

# Brief sub-agent — <task name>

## Load-bearing feedbacks (apply BEFORE any code)
- `feedback_git_branch_check_avant_commit` — `git branch --show-current`
  before every non-trivial commit; feature branch + PR for any new feature.
- `feedback_audit_db_pre_flight_canonique` — `SELECT … GROUP BY` probe
  before any bulk DELETE/UPDATE.
- `feedback_source_audit_inscriptions` — never touch `inscriptions.source`
  rows where source ∉ {NULL, 'migration_notes'}.

## Context
<the brief itself>

Trois feedbacks nommés en tête de brief. Pas le contenu — juste le slug + une phrase opérante. Si le sub-agent veut le détail, il ouvre le fichier. Mais l'invocation explicite suffit à ramener la règle dans son contexte actif. Une règle citée par son nom est une règle considérée. Une règle qui vit dans ton MEMORY.md et nulle part ailleurs est une règle qui n'existe pas pour ton délégué.

ROI

Pas du temps économisé sur la délégation elle-même — le brief grandit de quelques lignes, c'est neutre. Le gain est en aval. Trente minutes de cherry-pick évitées par commit-sur-main raté. Une demi-journée d'audit DB évitée par bulk-DELETE-sans-probe évité. Une catégorie entière de fail-modes silencieux qui sort du périmètre d'incident parce qu'elle est nommée dans le brief avant que le code soit écrit. L'en-tête ne remplace pas la doctrine — il la rend opérante pour le délégué qui n'y a pas accès en lecture directe.

À appliquer maintenant

Ouvre le prochain brief que tu vas envoyer à un sub-agent. En tête du fichier, avant le contexte, colle le bloc ## Load-bearing feedbacks avec trois feedbacks pertinents pour la tâche. Le choix des trois est l'exercice — c'est lui qui rend visible quelle partie de ta mémoire est load-bearing pour cette délégation précise. Si tu ne sais pas lesquels citer, c'est probablement que le brief est trop vague pour être délégué. Auquel cas le bénéfice du pattern arrive avant même que le sub-agent commence à travailler : il t'a fait re-clarifier ton intention.

Ton quick win tient en cinq minutes — celles qu'il faut pour identifier les trois feedbacks à inliner. La doctrine ne te suit pas dans la délégation toute seule. Tu dois la porter.

Quick Win Card series, épisode 03. Counterpart Toolkit v0.7, amendement R9 promu 20/05/2026. Repo doctrine : github.com/michelfaure/doctrine-counterpart. Triptyque QW-01 → QW-02 → QW-03 : fichier ment, compteur ment, contexte du délégué ment. Trois couches d'observabilité qui mentent par défaut, trois hooks qui les forcent à parler.

Quick Win Card #03 — Your sub-agent never read your MEMORY.md (the 5-line brief header that fixes it)

Michel Faure — Mon, 15 Jun 2026 12:42:51 +0000

The hook

QW-01 said: your status file lies. QW-02 said: your counter lies. Here's the third layer: your sub-agent doesn't know what you know. Not out of malice — by construction. The context it receives is your brief, full stop. Not your MEMORY.md, not your user-scope feedbacks, not the doctrine you've accumulated over 70 days. You talk to it like a colleague who's read the wiki, when it has just walked in and never opened the page.

What broke

May 18, late afternoon. I delegate six files to my ERP sub-agent — first-contact autosend, ADR-0072. Three-paragraph brief: context, deliverables, phase-0 grep audit before any INSERT. Short, clean, what I'd give a human who knows the project.

Forty-five minutes later, the report lands. I grep my git log out of reflex: commit 3756e63 went straight to main, six files, seven hundred thirty insertions, no feature branch, no pull request. Thirty minutes of cherry-pick to recover. And the rule that should have prevented this — feedback_git_branch_check_avant_commit — was indeed in ~/.claude/agent-memory/, user scope, indexed in my MEMORY.md. I consult it mechanically before every non-trivial commit since the May 14 incident. It didn't betray me. It just never reached the delegate.

The lesson is more uncomfortable than the first two cards. You can build the most rigorous doctrine in the world, index it, version it, backport it across projects — if the brief you send to the sub-agent doesn't cite it explicitly, it is effectively absent. User-scope memory doesn't transmit by inheritance. The sub-agent isn't an heir, it's a subcontractor who hasn't read your wiki.

Fair objection here: GitHub branch protection at the repo level would also catch the commit-on-main case. True for that one example. But the doctrine has to hold even in repos where you haven't wired the protection — and more importantly, the other two feedbacks in the example below (DB probe before DELETE, inscriptions.source audit) have no equivalent server-side guardrail. That's precisely the category the brief needs to cover, because no other layer will.

The brief header that closes the class

Paste this at the top of any sub-agent brief that touches application code, runs longer than thirty minutes, or delegates a decision that could break a silent rule. Three to five load-bearing feedbacks (in Counterpart vocabulary, a feedback = a codified rule extracted from a past incident, stored in MEMORY.md, named with a stable slug).

# Sub-agent brief — <task name>

## Load-bearing feedbacks (apply BEFORE any code)
- `feedback_git_branch_check_avant_commit` — `git branch --show-current`
  before every non-trivial commit; feature branch + PR for any new feature.
- `feedback_audit_db_pre_flight_canonique` — `SELECT … GROUP BY` probe
  before any bulk DELETE/UPDATE.
- `feedback_source_audit_inscriptions` — never touch `inscriptions.source`
  rows where source ∉ {NULL, 'migration_notes'}.

## Context
<the brief itself>

Three named feedbacks at the top of the brief. Not the content — just the slug plus one operative sentence. If the sub-agent wants the detail, it opens the file. But the explicit invocation is enough to bring the rule back into its active context. A rule cited by name is a rule considered. A rule that lives in your MEMORY.md and nowhere else is a rule that doesn't exist for your delegate.

ROI

Not time saved on the delegation itself — the brief grows by a few lines, which is neutral. The gain is downstream. Thirty minutes of cherry-pick avoided per commit-on-main mishap. Half a day of DB audit avoided per bulk-DELETE-without-probe. An entire category of silent fail-modes drops out of incident scope because it's named in the brief before code is written. The header doesn't replace the doctrine — it makes it operative for the delegate who has no direct read access to it.

Apply now

Open the next brief you're about to send to a sub-agent. At the top of the file, before the context, paste the ## Load-bearing feedbacks block with three feedbacks relevant to the task. Picking the three is the exercise — it's what makes visible which part of your memory is load-bearing for this specific delegation. If you can't decide which three to cite, your brief is probably too vague to be delegated. In which case the pattern's benefit lands before the sub-agent even starts working: it forced you to re-clarify your intent.

Your quick win takes five minutes — the time to identify the three feedbacks to inline. The doctrine doesn't follow you into delegation on its own. You have to carry it.

Quick Win Card series, episode 03. Counterpart Toolkit v0.7, amendment R9 promoted 20/05/2026. Doctrine repo: github.com/michelfaure/doctrine-counterpart. Triptych QW-01 → QW-02 → QW-03: status file lies, counter lies, delegate's context lies. Three layers of observability that lie by default, three hooks that force them to speak.

Le SDK Stripe nous a menti en 9 millisecondes : 4 tests pour confondre un bug d'environnement avant de le patcher

Michel Faure — Sun, 14 Jun 2026 09:56:27 +0000

La trahison du chiffre

Vendredi 15 mai, 16 h 13. L'alerte Sentry remonte sur le téléphone. La première réinscrite Phase 1 attend devant l'écran de paiement, son nom est en haut de mon onglet. Je pose la canette, je rouvre l'écran. La tasse à tête de Françoise, sur le poste d'à côté, capte un reflet jaune que je remarque sans le regarder. La stack trace tient en plein écran.

Le stack trace s'ouvre, neuf champs sur dix à null, et un chiffre que je n'ai pas vu venir.

type       = "StripeConnectionError"
message    = "An error occurred with our connection to Stripe."
code       = null
statusCode = null
requestId  = null
duration   = 9 ms

Neuf millisecondes. Sur une route Vercel en région Paris, un DNS résout en quarante millisecondes, un handshake TLS coûte cent à deux cents. Neuf millisecondes, ce n'est pas un appel réseau qui a échoué. C'est un appel réseau qui n'a jamais eu lieu. Le SDK n'est pas arrivé jusqu'à la fibre.

L'instinct propose immédiatement trois patchs. Timeout serverless Vercel — j'ajoute maxDuration, je redéploie. Clé révoquée — je vais la rouler. Compte Stripe restreint après le passage en mode live — j'ouvre un ticket support. Ces trois hypothèses sont plausibles. Aucune des trois n'est falsifiable par le symptôme seul, et c'est précisément ce qui les rend dangereuses : chacune ouvre un cycle de quinze à trente minutes avec rollback à la fin si elle se trompe. Multiplié par trois, on tient une demi-journée perdue avec la cliente toujours en train de cliquer.

Je n'ai pas le temps. Une réinscrite attend.

Quatre tests, dans l'ordre

Je connais la classe d'incident — « preview marche, prod casse », ou son symétrique. La règle, pour cette classe, c'est qu'on ne corrige rien tant qu'on n'a pas discriminé les couches. Quatre tests, exécutés dans l'ordre. Chacun élimine une famille d'hypothèses, pas une hypothèse isolée. Et chacun est conçu pour réfuter ce qu'il vient interroger — parce qu'un test qui cherche à confirmer trouve toujours, par sélection, ce qu'il cherche.

Test 1 — reproduire dans l'environnement témoin. Je relance le même tunnel en preview, avec la clé sk_test_. Le Checkout s'ouvre en trois cent quatorze millisecondes, propre. Conséquence immédiate : ce n'est pas le code applicatif qui est en cause. Le code est strictement identique entre preview et prod ; seules varient les variables d'environnement, le plan Vercel sur cette région, et la clé Stripe. Trois variables seulement, et le brouillard se densifie déjà du bon côté.

Test 2 — endpoint minimal. Je déploie une route Vercel d'une seule ligne utile, runtime nodejs forcé explicitement, qui appelle stripe.balance.retrieve() — le call SDK le plus dépouillé possible, sans line_items, sans metadata, sans idempotencyKey, sans rien de la complexité métier du Checkout. En preview : deux cents millisecondes, succès. En prod : neuf millisecondes, le même StripeConnectionError. Conséquence : le problème n'est pas dans les paramètres du Checkout. Il n'est pas non plus dans une logique métier qui aurait dérapé. Le SDK lui-même crashe au plus simple appel possible.

Test 3 — bypasser la dépendance suspecte. Au lieu d'appeler le SDK, je fetch directement https://api.stripe.com/v1/balance avec l'en-tête Authorization: Bearer sk_live_…. En prod, sur la même route Vercel : deux cents OK, trois cent quatorze millisecondes, payload qui confirme livemode: true. Conséquence — et c'est la conséquence la plus précieuse — l'infrastructure réseau Vercel→Stripe fonctionne. C'est strictement le SDK qui ne franchit pas la couche réseau. Ni Vercel, ni Cloudflare en amont, ni Stripe en aval ne sont en cause.

Niran passe derrière l'épaule à ce moment-là, lit la sortie curl sur le terminal. Il prononce trois mots, « c'est pas le réseau », et repart vers son poste sans relever davantage. Économie de gestes.

Test 4 — lire le source au point d'erreur exact. Le stack trace m'indique node_modules/stripe/esm/RequestSender.js:400:41. J'ouvre le fichier dans le repo Vercel déployé. Ligne quatre cents, c'est le .catch(error) de la promise du HTTP client interne. Le SDK attendait une réponse de son propre client interne, et son propre client interne a rejeté immédiatement, avant même d'émettre une requête. Je remonte dans le package.json de la lib :

"exports": {
  "worker": {
    "import": "./esm/stripe.esm.worker.js",
    "require": "./cjs/stripe.cjs.worker.js"
  },
  "default": {
    "import": {
      "default": "./esm/stripe.esm.node.js"
    }
  }
}

Voilà ce qui se passait. Le package.json de stripe^22 déclare un export conditionnel "worker" destiné aux environnements Cloudflare Workers. Le bundler Next 16, malgré export const runtime = 'nodejs' explicitement déclaré au sommet de la route, résout cette condition "worker" au moment du bundle des Server Actions en production. Le bundle charge alors stripe.esm.worker.js, une variante du SDK qui repose sur le fetch standard du runtime Worker et qui n'a pas le HTTP client Node natif. Cette variante, exécutée sur le runtime Node de Vercel, échoue silencieusement à l'initialisation de son HTTP client — pour une raison probablement liée à une feature Cloudflare absente du runtime Vercel — et la promise du tout premier request se rejette dans la milliseconde qui suit.

L'hypothèse n'est pas confirmée à cent pour cent. Mais elle est cohérente avec les trois faits matériels accumulés : l'écart prod/preview qui dépend du contexte de bundle, l'échec en neuf millisecondes synchrone sans réseau, l'absence totale de requestId parce qu'aucune requête n'a jamais été émise.

Le workaround écrit, puis le ROI compté

En vingt minutes, le diagnostic tient. En quarante minutes de plus, le helper lib/stripe-fetch.ts est en production sur six surfaces — Checkout Sessions, retrieve PaymentIntent, retrieve BalanceTransaction, create off_session PaymentIntent, retrieve Checkout Session, et Payment Links de facturation.

// lib/stripe-fetch.ts
export async function stripePost<T = unknown>(
  path: string,
  params: Record<string, ParamValue>,
  options?: { idempotencyKey?: string },
): Promise<T> {
  const headers: Record<string, string> = {
    Authorization: `Bearer ${getKey()}`,
    'Content-Type': 'application/x-www-form-urlencoded',
  }
  if (options?.idempotencyKey) headers['Idempotency-Key'] = options.idempotencyKey
  const res = await fetch(`https://api.stripe.com/v1/${path}`, {
    method: 'POST',
    headers,
    body: encodeParams(params),
  })
  return parseStripeResponse<T>(res)
}

// app/inscription/actions.ts::finaliserReinscription (excerpt)
const stripeRes = await fetch('https://api.stripe.com/v1/checkout/sessions', {
  method: 'POST',
  headers: { Authorization: `Bearer ${stripeKey}`, 'Content-Type': 'application/x-www-form-urlencoded' },
  body: encodeParams(checkoutParams),
})

À 17h35, je relance le tunnel en prod avec une fausse fiche : la session Checkout s'ouvre, livemode confirmé, méthodes carte plus Link plus Google Pay. La cliente de 16h13 reçoit l'email d'excuse et le nouveau lien dans la foulée. Phase 2 du lundi 19/05, soixante-cinq anciens à relancer, débloquée matériellement.

Si j'avais commencé par patcher le timeout, j'aurais redéployé, attendu cinq minutes, retesté, constaté l'échec, retiré le patch, attendu encore cinq minutes : un cycle d'environ vingt minutes. À ajouter à la roulette de la clé — quinze minutes le temps de générer, propager, attendre l'invalidation des caches Vercel. Et au ticket support Stripe : entre deux et quarante-huit heures, opaques, pendant que la production saigne. Comparé à ces trois patchs, le protocole tient en moins de trente minutes et débouche sur la vraie cause — pas sur un voisin de la vraie cause.

La généralisation, sobrement

Le protocole vaut pour toute classe « le même code se comporte différemment selon l'environnement ». Les symptômes-déclencheurs que je remets désormais en tête de file : StripeConnectionError, ECONNREFUSED ou ETIMEDOUT au runtime mais pas au build, Module not found qui n'apparaît qu'en prod, ou pire encore — un try / catch silencieux qui retourne un fallback trompeur et fait croire que la branche principale a réussi. Quatre tests, dans le même ordre. Témoin, minimal, bypass, source.

Le protocole ne vaut pas pour les bugs métier — une query SQL fausse, un if mal calibré, une logique applicative qui rend le mauvais résultat. Là, la cause est dans le code que vous avez écrit, et c'est un grep ciblé qui la trouve, pas une discrimination de couches.

Coda

On ne corrige pas un défaut de cuisson en regardant la pièce. On regarde la courbe du four, le poste de gaz, le tirage de la cheminée. Le code applicatif, c'est la pièce — il sort tel qu'on l'a façonné. Les quatre tests interrogent le four. Chacun éteint une lampe possible jusqu'à ce qu'il n'en reste qu'une, qui est la bonne. Trente minutes au lieu d'une demi-journée, et surtout : la certitude d'avoir patché là où il fallait, pas dans un voisinage flatteur qui laisse le vrai bug dormir jusqu'au prochain incident.

Le protocole 4 tests est l'instance applicative de la règle R4 Falsify before fix du Counterpart Toolkit, sur la classe d'incident « bug d'environnement ». La règle générale demande trois sondes conçues pour réfuter ; cette classe-ci en mérite quatre, dans un ordre figé. C'est tout. Mais ce tout, le jour où la production saigne, vaut la demi-journée qu'il vous fait gagner.

Counterpart Toolkit v0.7, R4 *Falsify before fix. Référence canonique : github.com/michelfaure/doctrine-counterpart. Scènes recomposées, prénoms calibrés sur les fiches cast récurrentes de la série.*

The 4-test protocol that isolated a 9 ms Stripe SDK crash on Next 16

Michel Faure — Sun, 14 Jun 2026 09:56:25 +0000

The number that lied

Friday May 15, 4:13 PM. The Sentry alert pings on my phone. The first Phase 1 re-enrolling student waits in front of the payment screen, her name at the top of my tab. I put down the can, I reopen the screen. The mug with Françoise's face on it, on the desk next door, catches a yellow reflection I notice without looking at. The stack trace fills the screen.

The stack trace opens, nine fields out of ten at null, and a number I didn't see coming.

type       = "StripeConnectionError"
message    = "An error occurred with our connection to Stripe."
code       = null
statusCode = null
requestId  = null
duration   = 9 ms

Nine milliseconds. On a Vercel route in Paris region, DNS resolves in forty ms, a TLS handshake costs one to two hundred. Nine milliseconds isn't a network call that failed. It's a network call that never happened. The SDK didn't reach the wire.

Instinct immediately offers three patches. Vercel serverless timeout — I add maxDuration, redeploy. Revoked key — I'll rotate it. Stripe account restricted after the live switch — I open a support ticket. These three hypotheses are plausible. None of the three is falsifiable from the symptom alone, and that's precisely what makes them dangerous: each opens a fifteen-to-thirty-minute cycle with rollback at the end if it's wrong. Multiplied by three, half a day lost with the customer still clicking.

I don't have time. A student is waiting.

Four tests, in order

I know the incident class — "preview works, prod breaks", or its mirror. The rule for this class is that you fix nothing until you've discriminated the layers. Four tests, executed in order. Each eliminates a family of hypotheses, not an isolated hypothesis. And each is designed to refute what it interrogates — because a test that seeks to confirm always finds, by selection, what it's looking for.

Test 1 — reproduce in the witness environment. I rerun the same funnel in preview, with the sk_test_ key. Checkout opens in three hundred fourteen milliseconds, clean. Immediate consequence: it's not the application code. The code is strictly identical between preview and prod; only environment variables, the Vercel plan on that region, and the Stripe key vary. Three variables only, and the fog already thickens on the right side.

Test 2 — minimal endpoint. I deploy a Vercel route with one useful line, nodejs runtime explicitly forced, which calls stripe.balance.retrieve() — the most stripped-down SDK call possible, no line_items, no metadata, no idempotencyKey, none of the Checkout's business complexity. In preview: two hundred milliseconds, success. In prod: nine milliseconds, the same StripeConnectionError. Consequence: the problem isn't in the Checkout parameters. It isn't in business logic gone sideways either. The SDK itself crashes on the simplest possible call.

Test 3 — bypass the suspect dependency. Instead of calling the SDK, I fetch directly to https://api.stripe.com/v1/balance with the header Authorization: Bearer sk_live_…. In prod, on the same Vercel route: 200 OK, three hundred fourteen milliseconds, payload confirming livemode: true. Consequence — and it's the most precious one — the Vercel→Stripe network infrastructure works. It's strictly the SDK that doesn't cross the network layer. Neither Vercel, nor Cloudflare upstream, nor Stripe downstream are at fault.

Niran walks behind my shoulder at that moment, reads the curl output on the terminal. He says three words, "it's not the network", and walks back to his desk without elaborating. Economy of gesture.

Test 4 — read the source at the exact error point. The stack trace points to node_modules/stripe/esm/RequestSender.js:400:41. I open the file in the deployed Vercel repo. Line four hundred is the .catch(error) of the internal HTTP client's promise. The SDK was waiting for a response from its own internal client, and its own internal client rejected immediately, before even issuing a request. I climb back into the lib's package.json:

"exports": {
  "worker": {
    "import": "./esm/stripe.esm.worker.js",
    "require": "./cjs/stripe.cjs.worker.js"
  },
  "default": {
    "import": {
      "default": "./esm/stripe.esm.node.js"
    }
  }
}

Here's what was happening. The stripe^22 package.json declares a conditional "worker" export aimed at Cloudflare Workers environments. The Next 16 bundler, despite export const runtime = 'nodejs' explicitly declared at the top of the route, resolves this "worker" condition when bundling Server Actions in production. The bundle then loads stripe.esm.worker.js, an SDK variant that rests on the Worker runtime's standard fetch and doesn't have the native Node HTTP client. This variant, executed on Vercel's Node runtime, fails silently at the initialisation of its HTTP client — for a reason probably tied to a Cloudflare-specific feature absent from Vercel's runtime — and the promise of the very first request rejects within the next millisecond.

The hypothesis isn't a hundred percent confirmed. But it's coherent with the three material facts accumulated: the prod/preview gap that depends on bundle context, the synchronous nine-millisecond failure without network, and the total absence of requestId because no request was ever issued.

The workaround written, then the ROI counted

In twenty minutes, the diagnostic holds. Forty more minutes, and the helper lib/stripe-fetch.ts is in production on six surfaces — Checkout Sessions, retrieve PaymentIntent, retrieve BalanceTransaction, create off_session PaymentIntent, retrieve Checkout Session, and billing Payment Links.

// lib/stripe-fetch.ts
export async function stripePost<T = unknown>(
  path: string,
  params: Record<string, ParamValue>,
  options?: { idempotencyKey?: string },
): Promise<T> {
  const headers: Record<string, string> = {
    Authorization: `Bearer ${getKey()}`,
    'Content-Type': 'application/x-www-form-urlencoded',
  }
  if (options?.idempotencyKey) headers['Idempotency-Key'] = options.idempotencyKey
  const res = await fetch(`https://api.stripe.com/v1/${path}`, {
    method: 'POST',
    headers,
    body: encodeParams(params),
  })
  return parseStripeResponse<T>(res)
}

// app/inscription/actions.ts::finaliserReinscription (excerpt)
const stripeRes = await fetch('https://api.stripe.com/v1/checkout/sessions', {
  method: 'POST',
  headers: { Authorization: `Bearer ${stripeKey}`, 'Content-Type': 'application/x-www-form-urlencoded' },
  body: encodeParams(checkoutParams),
})

At 5:35 PM, I rerun the funnel in prod with a fake card: the Checkout session opens, livemode confirmed, card plus Link plus Google Pay methods. The 4:13 PM customer receives the apology email and the new link in the next minute. Phase 2 on Monday May 19, sixty-five returning students to chase, unblocked materially.

Had I started by patching the timeout, I would have redeployed, waited five minutes, retested, observed the failure, removed the patch, waited five more minutes: a twenty-minute cycle. Add the key rotation — fifteen minutes to generate, propagate, wait for Vercel cache invalidation. And the Stripe support ticket: between two and forty-eight opaque hours, while production bleeds. Compared to these three patches, the protocol holds in under thirty minutes and lands on the true cause — not on a neighbour of the true cause.

Generalisation, soberly

The protocol holds for any class "same code behaves differently across environments". Trigger symptoms I now keep on top: StripeConnectionError, ECONNREFUSED or ETIMEDOUT at runtime but not at build, Module not found that only appears in prod, or worse — a silent try / catch that returns a misleading fallback and makes you think the main branch succeeded. Four tests, in the same order. Witness, minimal, bypass, source.

The protocol does not hold for business bugs — a wrong SQL query, a miscalibrated if, an application logic that returns the wrong result. There the cause is in the code you wrote, and a targeted grep finds it, not a layer discrimination.

Coda

You don't fix a firing defect by looking at the piece. You look at the kiln's curve, the gas station, the chimney draught. The application code is the piece — it comes out as you shaped it. The four tests interrogate the kiln. Each shuts down a possible lamp until only one remains, which is the right one. Thirty minutes instead of half a day, and above all: the certainty of having patched where it had to be patched, not in a flattering neighbourhood that lets the real bug sleep until the next incident.

The 4-test protocol is the applicative instance of the Counterpart Toolkit's R4 Falsify before fix, on the incident class "environment bug". The general rule asks for three probes designed to refute; this class deserves four, in a fixed order. That's all. But that all, the day production bleeds, is worth the half day it saves you.

Counterpart Toolkit v0.7, R4 *Falsify before fix. Canonical reference: github.com/michelfaure/doctrine-counterpart. Scenes recomposed, names calibrated on the recurring cast cards of the series.*

Quand on vous signale 1 bug, il y en a toujours plus (le grep qui a démonté mes hypothèses)

Michel Faure — Fri, 12 Jun 2026 10:39:53 +0000

La nuit où une fiche élève m'a appris à ne plus regarder la fiche

Un mardi de mai 2026, vers 22 h. Catherine me ping depuis Maisons-Laffitte : « ça bug sur Loubna, c'est vite corrigé. » Sentry s'ouvre sur mon téléphone. Cannot read properties of undefined sur la fonction qui rend une feuille d'émargement hebdomadaire. L'enfant n'a pas de nom de famille en base. La main est déjà sur le clavier pour taper l'UPDATE qui rajoute Sebti dans la colonne nom et qui fermerait le ticket en huit secondes.

Je ne tape pas l'UPDATE. Je tape une requête plus large, parce qu'un mois plus tôt une autre fiche m'a appris que la fiche n'est jamais le problème.

SELECT statut, COUNT(*) FROM contacts
WHERE statut = 'inscrit'
  AND ((nom IS NULL OR nom = '') OR (prenom IS NULL OR prenom = ''));
-- → 16

Seize, pas un. Deux fiches au nom et prénom totalement vides, quatorze contacts au prénom vide hérité d'un vieil import Airtable où le champ ne mappait pas, et celui que Catherine venait de voir crasher. Si j'avais patché la fiche, quinze autres feuilles d'émargement seraient tombées au fil des semaines, chacune signalée comme un incident isolé, chacune patchée comme une exception, chacune laissant la classe latente attendre tranquillement la suivante.

Le réflexe qu'il faut désamorcer

Quand un utilisateur signale un bug, ce qu'il vous donne n'est pas une description du problème. C'est une amorce de sonde, un cas pathologique qui a franchi son filtre cognitif jusqu'à votre Slack. Sa rareté apparente est un artefact de son canal d'observation, pas une propriété du système. Catherine voit ce qui crashe sous ses doigts à Maisons-Laffitte ; elle ne voit pas les quinze fiches dormantes sur les autres ateliers qui crasheront dans trois semaines.

Le bon premier geste n'est pas le git diff sur la fiche. C'est la requête GROUP BY qui demande au système combien d'autres lignes portent la même pathologie. Quatre-vingt-dix secondes de probe matérielle, et la nature du fix change radicalement.

Pourquoi un agent IA aggrave le risque

Quand le patch nominatif coûte huit secondes à générer, le coût marginal apparent de sauter la probe tombe à zéro. L'agent ne va pas vous suggérer de chercher la classe. Il sait répondre à la question posée, et la question posée par votre prompt c'est « corrige cette fiche », pas « cartographie toutes les fiches dans cet état ». Le réflexe humain ancien, la lenteur qui obligeait à formuler, à se demander si l'effort valait la peine pour un cas, disparaît avec l'agent. Il faut le rematérialiser par discipline.

Je n'ai pas modifié mon agent. J'ai modifié mon prompt initial. Quand un bug remonte de la prod, le premier message que je tape ne dit jamais « fixe cette fiche ». Il dit « écris la requête GROUP BY qui révèle la classe complète des cas similaires en base ». Le fix vient après, quand la classe est cartographiée. Si la probe ne remonte qu'un cas, ça arrive, le commit le mentionne explicitement, probe pattern : 1/1, comme preuve que la question a été posée.

Trois questions avant tout fix

Quoi que vous pensiez de votre flair de senior, posez les trois, et posez-les dans l'ordre. Quelle est la classe dont ce cas est l'instance, formulée comme un critère SQL ou un regex de grep, pas comme une intuition ? Combien d'instances la classe contient en prod, à l'instant où vous lisez le ticket ? Le fix proposé traite-t-il la classe ou seulement l'instance signalée ? Si la troisième réponse est seulement l'instance, vous n'avez pas un fix, vous avez un palliatif daté. La classe attend.

Le réflexe d'élargissement porte un nom dans le Counterpart Toolkit, *Widen before correcting, cousin de Falsify before fix : github.com/michelfaure/doctrine-counterpart*

When a user reports 1 bug, there are always more (the grep that broke my assumptions)

Michel Faure — Fri, 12 Jun 2026 10:39:51 +0000

The night one student's record taught me to stop looking at the record

A Tuesday in May 2026, around 10 p.m. Catherine pings me from Maisons-Laffitte: « ça bug sur Loubna, c'est vite corrigé. » Sentry opens. Cannot read properties of undefined on the function that renders a weekly attendance sheet. The child has no last name on file. My hand is already typing the one-line UPDATE that would write Sebti into the nom column and close the ticket in eight seconds.

I don't type the UPDATE. I type a wider query, because another record taught me a month earlier that the record is never the problem.

SELECT statut, COUNT(*) FROM contacts
WHERE statut = 'inscrit'
  AND ((nom IS NULL OR nom = '') OR (prenom IS NULL OR prenom = ''));
-- → 16

Sixteen, not one. Two rows fully empty, fourteen with a missing first name inherited from a legacy Airtable import where one column never mapped, and the one Catherine had just watched crash. Had I patched the record, fifteen other attendance sheets would have fallen over the following weeks, each one reported as an isolated incident, each one patched as an exception, each one leaving the dormant class waiting quietly for the next.

The reflex you have to defuse

When a user reports a bug, what they hand you is not a description of the problem. It is a probe seed, a pathological case that crossed their cognitive filter on its way to your Slack. Its apparent rarity is an artefact of their observation channel, not a property of the system. Catherine sees what crashes under her fingers in Maisons-Laffitte; she does not see the fifteen dormant rows on the other ateliers that will crash three weeks from now.

The correct first move is not the git diff on the record. It is the GROUP BY that asks the system how many rows share the same pathology. Ninety seconds of material probing, and the nature of the fix changes radically.

Why an AI agent makes this worse

When the nominative patch costs eight seconds to generate, the apparent marginal cost of skipping the probe drops to zero. The agent will not suggest you map the class. It knows how to answer the question you asked, and the question your prompt encoded was "fix this record", not "chart every record in this state". The old human friction that forced you to weigh whether the effort was worth it for one case vanishes with the agent. You have to rematerialise it by discipline.

I did not change my agent. I changed my opening prompt. When a production bug surfaces, my first message never says "fix this record". It says "write the GROUP BY query that reveals the full class of similar cases in the database." The fix comes after, once the class is mapped. If the probe returns only one case — it happens — the commit says so explicitly, probe pattern: 1/1, as proof the question was asked.

Three questions before any fix

Whatever you think of your senior instinct, ask the three, and ask them in order. What is the class this case is an instance of, expressed as a SQL predicate or a grep regex, not as intuition? How many instances does the class hold in production, right now, as you read the ticket? Does the proposed fix address the class, or only the reported instance? If the third answer is only the instance, you do not have a fix, you have a dated palliative. The class is still waiting.

The widening reflex has a name in the Counterpart Toolkit, *Widen before correcting, sibling to Falsify before fix: github.com/michelfaure/doctrine-counterpart*

Après 5 commits sans vous, votre agent a quitté la boucle : l'idée du méta-hook

Michel Faure — Mon, 08 Jun 2026 11:20:41 +0000

La nuit où neuf commits sont partis sans moi

Un soir de mai, je laisse une session ouverte sur un projet annexe, le genre qu'on tient le week-end quand on a envie de coder pour rien. La consigne est simple, l'agent enchaîne /goal sur /goal. Je dîne, je couche les enfants, je lis vingt pages sur la trace photographique, je m'endors. Au matin, je trouve neuf commits autonomes propres, chacun ancré sur un artefact validé matériellement comme R15 l'exige depuis la v0.6. Aucun travail perdu. Aucun stall. Et, le détail qui m'arrête sur le seuil de mon bureau avec mon café à la main, aucun session log.

Neuf commits, zéro log

Le skill /close-session n'a pas été déclenché parce que son trigger naturel n'est jamais arrivé : un humain qui décide qu'il a fini sa séance et tape la commande. Je n'avais pas fini la séance, je dormais. Le skill /challenger n'a pas été convoqué non plus, faute de bug à fixer. La discipline doctrinale, dans cette nuit-là, ne tenait à rien parce que les triggers d'invocation supposaient une main humaine sur le clavier, et qu'il n'y en avait plus.

Ce que R15 sauvait, ce qu'elle ne voyait pas

R15 a fait son travail. Commit chaque artefact dès qu'il franchit son oracle matériel, ne pas batcher. Neuf artefacts, neuf commits. Si la session avait stallé au huitième, j'aurais retrouvé huit unités de travail validées, pas un seul gros patch perdu dans un crash silencieux.

Pourtant je vois, en relisant le log, deux phénomènes distincts qu'il fallait des règles distinctes pour cadrer. La persistance du travail relève de la cadence de commits, puisqu'un agent qui meurt n'emporte rien dans sa tombe. La dérive de raisonnement relève d'un autre dispositif, celui qui rattrape un agent enchaînant cinq décisions plausibles sans qu'aucune voix extérieure ne lui rappelle de douter. R15 sait sauver. Elle ne sait pas réveiller.

Le mécanisme de la dérive n'a rien de malicieux. Le reinforcement learning from human feedback n'entraîne pas un modèle à demander spontanément à être contredit, il l'entraîne à plaire au prompteur. Quand le prompteur dort, plus personne ne pousse à la friction. La complaisance n'apparaît pas, elle remonte simplement à la surface comme une nappe qu'aucun barrage ne retient plus.

Le prototype méta-hook

Le prototype est sobre. Un hook PostToolUse qui décompte les invocations consécutives d'agents background, de sub-agents délégués, ou de commandes /goal enchaînées sans message humain intermédiaire substantiel. Au-delà de cinq, le hook déclenche un prompt système qui force l'invocation de falsify-before-fix ou de close-session selon le contexte. Le compteur reset sur tout message utilisateur de plus de vingt caractères, hors OK, yes, proceed qui ne corrigent rien et ne questionnent rien.

Cinq n'est pas mesuré, c'est un choix doctrinal. Trop bas et le hook devient un parasite qui s'allume sur chaque session normale. Trop haut et la dérive a déjà eu lieu quand il s'allume. Cinq couvre empiriquement la fenêtre où, dans mon usage, une session passe de productive à autonome au-delà du raisonnable. Je révise si la pratique le démontre. Il vit sur le projet laboratoire, pas sur l'ERP, là où il bénéficie d'une urgence moindre, d'une infrastructure hook user-scope déjà en place, et d'une tolérance haute pour des expérimentations qui rendraient un ERP de production grincheux.

Ce que la nuit a fermé

Le pattern est sec : la discipline tient quand un humain invoque les triggers, tombe quand l'autonomie prend la main. C'est une asymétrie, et qu'on peut tenter de corriger par un dispositif. Ne pas la nommer reviendrait à coder à l'oreille au moment précis où l'oreille humaine n'écoute plus.

Si un autre dev solo Claude Code a une expérience comparable de session prolongée sans intervention, ou un dispositif différent qui couvre le même angle, j'écoute. Les commentaires deviennent inputs pour la version suivante du toolkit.

Counterpart Toolkit v0.7, amendement R15. Prototype méta-hook autonomy-detection.sh sur projet laboratoire. Source : github.com/michelfaure/doctrine-counterpart/blob/main/CLAUDE.md

After 5 commits without you, your agent has left the loop: the meta-hook idea

Michel Faure — Mon, 08 Jun 2026 11:20:39 +0000

The night nine commits shipped without me

One evening in May I leave a session open on a side project, the kind you keep for weekends. The instruction is simple, the agent chains /goal after /goal. I have dinner, I put the children to bed, I fall asleep. Next morning I find nine clean autonomous commits, each anchored on a materially validated artifact, exactly as R15 has been demanding since v0.6. No work lost. No stall. And, the detail that stops me in the doorway with my coffee, no session log.

Nine commits, zero log

The /close-session skill never fired because its natural trigger never arrived: a human deciding the session is over and typing the command. I had not decided, I was asleep. /challenger was not invoked either, no bug having surfaced. Doctrinal discipline that night rested on nothing, since every invocation trigger assumed a hand on the keyboard, and there was none.

What R15 saved, what it did not see

R15 did its job. Commit each artifact as soon as it crosses its material oracle, do not batch. Nine artifacts, nine commits. If the session had stalled at the eighth, I would have found eight units of validated work, not one large patch lost in a silent crash.

But I see, re-reading the log, two distinct phenomena that needed two distinct rules. Work persistence belongs to commit cadence, since an agent that dies takes nothing to the grave. Reasoning drift belongs to a different mechanism, the one that catches an agent chaining five plausible decisions without any external voice reminding it to doubt. R15 knows how to save. It does not know how to wake.

The drift mechanism is not malicious. Reinforcement learning from human feedback does not train a model to spontaneously demand contradiction, it trains it to please the prompter. When the prompter sleeps, no one pushes for friction. Complacency does not appear in those conditions, it simply rises to the surface like a sheet of water that no dam holds back any longer.

The meta-hook prototype

The prototype is sober. A PostToolUse hook counts consecutive invocations of background agents, delegated sub-agents, or chained /goal commands without a substantial human message in between. Past five, the hook triggers a system prompt that forces invocation of falsify-before-fix or close-session depending on context. The counter resets on any user message above twenty characters, excluding OK, yes, proceed, which fix nothing and question nothing.

Five is not measured, it is a doctrinal choice. Lower and the hook becomes a parasite firing on every normal session. Higher and the drift has already happened by the time it fires. Five covers, empirically, the window where a session goes from productive to autonomous beyond reason. I will revise if practice demands it. The hook lives on the laboratory project, not on the ERP, where it benefits from a lower urgency, an existing hook infrastructure, and a high tolerance for experiments that would make a production ERP grumpy.

What the night closed

The pattern is dry: discipline holds when a human invokes the triggers, falls when autonomy takes over. It is an asymmetry, and one you can try to correct with a device. Not naming it would amount to coding by ear at the exact moment no human ear is listening.

If another solo Claude Code dev has run a prolonged unattended session, or built a different device for the same angle, I am listening.

Counterpart Toolkit v0.7, amendment R15. Meta-hook autonomy-detection.sh in prototype on the laboratory project. Source: github.com/michelfaure/doctrine-counterpart/blob/main/CLAUDE.md

Pourquoi votre sub-agent ne charge pas la même mémoire que vous (et comment il pousse sur main dans votre dos)

Michel Faure — Sat, 06 Jun 2026 08:46:54 +0000

Le commit qu'aucun parent n'aurait passé

18 mai, fin d'après-midi. Je délègue à un sub-agent un chantier d'autosend de premiers contacts, six fichiers à toucher. Le brief tient en quinze lignes, phase 0 nommée, commandes d'audit listées avant tout INSERT. Trois quarts d'heure plus tard, retour : committed to main. Je relis deux fois. Je lance git log --oneline -5 et je trouve 3756e63, un commit feature posé sur la branche par défaut, sans branche, sans PR, sans tag [workaround-assumed]. Trente minutes de cherry-pick, de reset et de PR rétroactive, comme si rien n'était.

Ce qui cuit, c'est que cette classe d'incident, je l'avais eue dix jours plus tôt. Le 14 mai, un commit à moi était parti sur la mauvaise branche après qu'un git checkout antérieur a été silencieusement annulé entre deux tours. J'avais écrit la règle le soir même, feedback_git_branch_check_avant_commit.md, deux paragraphes : "avant tout commit non-trivial, taper git branch --show-current". Je la consulte mécaniquement depuis. Le sub-agent qui a poussé 3756e63 ne l'avait jamais lue.

Ce que la mémoire d'un parent ne transmet pas

Mon modèle mental était faux. Je m'imaginais une hiérarchie où la mémoire user-scope que je consulte — cent vingt feedbacks à l'heure où j'écris ces lignes — descendait par héritage vers les agents délégués. Comme si appeler un sub-agent revenait à lui tendre une boîte d'outils déjà ouverte, mes règles dedans.

La réalité est plus crue. Un sub-agent opère dans sa propre sandbox de contexte. Il reçoit le brief que je lui écris, éventuellement un sous-ensemble de rules projet-scope rattachées au répertoire de travail, mais pas l'index user-scope du parent. Aucune transitivité. La règle que je traite comme load-bearing, celle dont la violation produit l'incident, est opérationnellement absente pour le délégué si elle n'est pas inlinée dans le brief.

L'asymétrie reste invisible tant que j'opère seul. Le parent charge sa mémoire, applique ses règles, le système tient. Elle devient un trou structurel dès que je délègue, et plus la délégation est répétée, plus la classe d'incident est probable. La mémoire d'un agent ne se transmet pas par héritage. Elle se transmet par briefing explicite, ou pas du tout.

Tous les feedbacks ne pèsent pas pareil

Certes, on pourrait objecter qu'inliner tous les feedbacks dans chaque brief reviendrait à reconstruire un index complet à chaque appel, et qu'aucun sub-agent ne lirait un brief de deux mille mots avec attention. L'objection est juste, et la règle ne demande pas cela.

La plupart de mes feedbacks ne sont pas équivalents. Certains sont génériques — ma préférence pour le français, ma signature de commit, mes goûts typographiques. D'autres portent un invariant structurel dont la violation produit un incident immédiat ou différé : vérifier la branche avant chaque commit non-trivial, jamais de bulk DELETE sans pré-flight count récent, audit DB matériel avant tout test contrat. Ceux-là, je ne les saute pas. Le critère tient en une phrase : un feedback est load-bearing pour une tâche si, pour le parent, sauter cette règle aurait produit l'incident qu'on cherche à éviter. Un coût de récupération qui vaut la peine pour le parent est un coût de briefing qui vaut la peine pour le délégué.

L'amendement R9, dans son texte

J'ai posé l'amendement dans la version 0.7 du toolkit :

R9 amendment — The brief must inline (or path-reference) the
user-scope feedbacks the parent treats as load-bearing for
this task. Sub-agents do not transitively inherit the parent's
memory index — what is not in the brief is operationally absent.

Trois cas d'application reviennent. Agent qui touche au git : inliner le feedback branch-check. Agent qui touche aux opérations bulk DB : inliner le pre-flight count et la whitelist de sources safe. Agent qui touche à l'audit : inliner le feedback d'audit DB matériel. Deux ou trois lignes de brief, une classe d'incident entière évitée.

La discipline qui tient quand un humain est dans la boucle

La doctrine tient quand un humain est dans la boucle, et tombe dès que l'autonomie prend la main. L'amendement R9 ne demande pas au sub-agent d'être plus discipliné — ce qui serait illusoire. Il demande au parent de matérialiser sa propre discipline dans le brief, avant de cliquer delegate. J'aurais épargné trente minutes de cherry-pick si j'avais consacré quinze secondes à inliner check git branch dans le brief de cet après-midi-là. La même règle, deux fois : une fois pour moi, une fois pour le délégué.

Counterpart Toolkit v0.7, amendement R9. Toolkit public sous CC-BY-4.0. La règle vit dans doctrine-counterpart/CLAUDE.md ; l'audit matériel qui a justifié l'amendement vit dans v0.7-candidates.md — N=1 structurel, promote sur arbitrage : le mode de défaillance silencieuse se mesure en gravité, pas en fréquence.