Forem: Michel Faure

Deux IA d'accord = une source : la règle qui m'a évité un pipeline bâti sur du vide

Michel Faure — Sun, 24 May 2026 08:44:42 +0000

Une nuit, deux audits, une même note

Le 17 mai au soir, je termine la version 0.4.1 du Counterpart Toolkit et je décide de la soumettre à deux relectures externes. Je colle le manifesto et la quatorzaine de règles dans une session ChatGPT-4o, je colle exactement le même contenu dans Claude.ai sur le web. J'attends. Quelques minutes plus tard, les deux verdicts arrivent. Note 8/10 d'un côté. Note 8/10 de l'autre. Critiques quasi identiques sur l'apparat théorique (Bourdieu invoqué sans portée opérationnelle), suggestion identique de simplification, même angle sur la fraîcheur de l'instrumentation M1-M5. Mon réflexe initial tient trente secondes. Deux relecteurs indépendants, même note, mêmes critiques, la doctrine est calibrée juste, je peux publier.

Et puis je m'arrête. Parce que quelque chose, dans cette convergence trop nette, sonne comme un baromètre acheté en double exemplaire chez le même fournisseur.

Pourquoi deux IA convergentes ne sont pas deux mesures

Je comprends assez vite ce que la convergence mesure. Deux modèles de langage entraînés sur des corpus qui se recouvrent à très large proportion, qu'il s'agisse d'articles techniques, de repos GitHub publics, de discussions Stack Overflow ou de blogs des dix dernières années, produisent des erreurs corrélées. Ce qu'ils ont en commun, c'est leur intersection d'apprentissage, pas la réalité externe que je leur soumets. Quand les deux trouvent que l'apparat théorique est disproportionné, je n'apprends pas que c'est vrai. J'apprends que c'est ce que la statistique partagée de leurs deux corpus reconnaît comme un défaut typique d'un texte de ce format.

Certes, deux relecteurs humains qui convergent sont, eux, deux mesures séparées. Mais le parallèle est trompeur. Deux relecteurs humains ont des biographies disjointes, des lectures différentes, des écoles de pensée parfois opposées. Deux LLM partagent un substrat qui n'a pas cette texture. La corroboration croisée, en épistémologie classique, suppose l'indépendance des sources. Sur deux modèles statistiques entraînés sur les mêmes corpus, l'indépendance n'est pas donnée, elle est à démontrer, et elle ne l'est presque jamais.

Cette intuition m'a probablement épargné quelques jours de re-écriture inutile. Mais elle restait spéculative. Je voulais des sondes matérielles.

Trois sondes en trois jours

Première sonde, le soir même. Un autre projet où je travaille en parallèle, un repo de game dev sur Godot, m'avait poussé à étudier WebFetch la semaine précédente. Un assistant Claude m'avait affirmé que l'outil retournait « le texte OCRé complet d'un PDF de 25 MB » et j'avais bâti un pipeline d'ingestion sur cette claim. Je relance la commande dans la session courante, juste pour vérifier. Sortie brute en clair dans la console, maxContentLength size of 10485760 exceeded. La claim était techniquement impossible. Le pipeline reposait sur un mécanisme inexistant. Je n'avais pas testé parce que la formulation de l'assistant était confiante, structurée, et plausiblement vraie.

Deuxième sonde, le lendemain. Même substrate game dev. Un audit conversationnel m'avait orienté vers un blog technique présenté comme « contenant les 18 actions de régence du domaine », pile la matière que je cherchais. Avant de scraper, je fais un WebFetch sur l'index du blog. Retour brut, huit articles de chronique de développement, zéro article sur le sujet annoncé. La claim était une hallucination cohérente. Le format « blog d'untel contient X » est une combinaison statistique que le modèle produit volontiers, parce qu'elle est syntaxiquement plausible, sans qu'aucun mécanisme interne ne vérifie son existence factuelle.

Troisième sonde, ce matin, sur la doctrine elle-même. Un Claude externe partagé sur claude.ai a audité hier mon repo doctrine-counterpart et affirmé, captures à l'appui, que « 6 SKILL.md sur 6 ont un YAML frontmatter cassé », diagnostic présenté avec haute confiance, justifiant un déclassement à 7,5/10. Je lance ce matin un yaml.safe_load sur les douze SKILL.md du repo. Résultat brut, 11/12 OK, 1/12 cassé. Le défaut systémique annoncé n'existait pas. Le seul vrai cassé, l'évaluateur visuel ne l'avait pas isolé puisqu'il avait conclu « défaut systémique » sans cas individuel. Ce qu'il avait vu, c'est le rendu Markdown de GitHub qui mange le frontmatter et l'affiche comme tableau, une particularité de rendu d'hôte qui n'a rien à voir avec l'état du source brut.

Trois claims externes testées, trois falsifications. Pas une convergence partielle, pas une réfutation nuancée, trois claims sur trois tombées contre leur sonde. Le ratio aurait été indétectable sans test matériel.

La règle canonique, Am.R12 du Counterpart Toolkit v0.7

J'ai amendé R12 le 20 mai, deux jours après ces trois incidents. Le texte officiel.

« Toute claim formulée par une IA externe (autre Claude, ChatGPT, sparring conversationnel) à propos (a) du comportement d'un outil concret que vous pouvez sonder, (b) du contenu d'une ressource externe, (c) de la structure d'un système dont la vérité de terrain est échantillonnable, doit être testée matériellement avant d'être prise comme input d'une décision d'architecture. Coût du test ≈ 1 commande shell. Coût de la croyance non testée = pipeline entièrement basé sur un mécanisme inexistant. Deux revues d'IA externes convergentes sur le même diagnostic = une source pour les besoins de R5, pas deux, la corroboration cross-substrate indépendante exige un humain ou une sonde mécaniquement distincte (logs, métriques, exécution échantillon). »

Qui contesterait que deux relecteurs valent mieux qu'un seul ? Personne, et pourtant la formule mérite d'être démontée. Sur deux LLM, la convergence n'est pas une corroboration, c'est une convergence orpheline, une intersection statistique sans extériorité vérifiable. Trois contre-arguments matériels, en réponse à l'objection que j'aurais entendue d'un lead tech méta-IA il y a six mois.

D'abord, la statistique d'entraînement partagée. Deux modèles dont les corpus se recouvrent sur l'essentiel produisent des erreurs corrélées sur les mêmes plages syntaxiques. Leur accord mesure leur intersection d'apprentissage. Il semble que la convergence soit, dans ce cas, plus probable sur les énoncés typiques, c'est-à-dire ceux que le pré-entraînement reconnaît comme bien formés, que sur les énoncés vrais. Ce n'est pas la même chose.

Ensuite, l'hallucination corrélée sur les outils et les ressources. Sur les claims portant sur le comportement d'un tool précis ou le contenu factuel d'une ressource externe, deux modèles tendent à halluciner le résultat le plus plausible statistiquement, souvent faux, presque toujours formulé avec assurance. Mes trois sondes en sont l'illustration brute.

Enfin, le coût asymétrique. Une sonde matérielle coûte une commande shell, quinze secondes, parfois moins. Une décision d'architecture bâtie sur une convergence non testée peut coûter plusieurs jours-dev de re-do et un pipeline à refaire. R12 amendée arbitre ce coût asymétrique en rendant la sonde obligatoire avant tout commit qui prend la claim comme input.

Coda

Le réflexe à acquérir n'est pas la défiance. C'est la sonde. Et la sonde commence par soi, en appliquant R12 d'abord à mes propres assertions avant de l'imposer aux autres, en vérifiant mon propre repo par yaml.safe_load avant de croire un audit visuel qui flatte ou qui condamne. Un agent qui ne contredit pas matériellement n'est pas un counterpart, c'est une dactylo qui parle. Deux agents qui s'accordent sans qu'aucun ne soit testé ne forment pas deux relecteurs, c'est la même dactylo en duplicata. La règle tient en une commande.

# Avant d'adopter une claim externe sur tool/resource/structure :
$ <la commande matérielle qui aurait pu la falsifier>

Le repo, github.com/michelfaure/doctrine-counterpart. Am.R12 vit en clair dans CLAUDE.md, ses trois incidents fondateurs documentés dans v0.7-candidates.md. Si une seule de vos prochaines décisions d'architecture évite la croyance non testée, la règle s'est remboursée.

Counterpart Toolkit v0.7. R12 amendée le 20 mai 2026 sur N=3 incidents multi-substrate. Trois claims externes, trois falsifications, une commande shell chacune. Licence CC-BY-4.0.

Two AI reviews agreeing is not two reviews: how I learned to test claims before adopting them

Michel Faure — Sun, 24 May 2026 08:44:40 +0000

One night, two audits, one identical score

The evening of 17 May, I finish version 0.4.1 of the Counterpart Toolkit and decide to submit it to two external reviews. I paste the manifesto and the fourteen rules into a ChatGPT-4o session, then paste exactly the same content into a Claude.ai web session. I wait. A few minutes later, both verdicts land. Score 8/10 on one side. Score 8/10 on the other. Near-identical criticisms about the theoretical apparatus — Bourdieu invoked without operational traction — identical simplification suggestions, same angle on the freshness of the M1-M5 instrumentation. My initial reflex holds for thirty seconds. Two independent reviewers, same score, same criticisms — the doctrine is calibrated right, I can publish.

Then I stop. Because something in that convergence rings like a barometer bought in duplicate from the same supplier.

Why two converging AIs are not two measurements

I understand fairly quickly what the convergence is actually measuring. Two language models trained on corpora that overlap to a very large degree — technical articles, public GitHub repos, Stack Overflow discussions, a decade of blogs — produce correlated errors. What they have in common is their shared learning intersection, not the external reality I am submitting to them. When both find the theoretical apparatus disproportionate, I am not learning that it is true. I am learning that the shared statistics of their two corpora recognise this as a typical flaw in a text of this format.

Granted, two human reviewers who converge are, on their own, two separate measurements. But the parallel is misleading. Two human reviewers have disjoint biographies, different readings, sometimes opposing schools of thought. Two LLMs share a substrate that does not carry that texture. Cross-corroboration, in classical epistemology, presupposes independence of sources. With two statistical models trained on the same corpora, independence is not given — it has to be demonstrated, and it almost never is.

This intuition probably spared me a few days of pointless rewriting. But it remained speculative. I wanted material probes.

Three probes in three days

First probe, that same evening. A side project I had been running in parallel — a game dev repo — had led me to study WebFetch the previous week. A Claude assistant had told me that the tool returned "the complete OCR text of a 25 MB PDF" and I had built an ingestion pipeline on that claim. I run the command in the current session, just to verify. Raw output printed to the console: maxContentLength size of 10485760 exceeded. The claim was technically impossible. The pipeline rested on a non-existent mechanism. I had not tested it because the assistant's phrasing had been confident, structured, and plausibly true.

Second probe, the next day. Same game dev substrate. A conversational audit had pointed me toward a technical blog described as "containing the 18 domain regency actions" — exactly the material I was after. Before scraping, I run WebFetch on the blog's index. Raw return: eight development-chronicle articles, zero articles on the announced subject. The claim was a coherent hallucination. The pattern "so-and-so's blog contains X" is a statistical combination the model produces readily because it is syntactically plausible, without any internal mechanism verifying its factual existence.

Third probe, that morning, on the doctrine itself. An external Claude shared via claude.ai had audited my doctrine-counterpart repo the day before and asserted, screenshots included, that "6 out of 6 SKILL.md files have a broken YAML frontmatter" — diagnosis delivered with high confidence, used to justify a 7.5/10 downgrade. That morning I run yaml.safe_load on all twelve SKILL.md files in the repo. Raw result: 11/12 OK, 1/12 broken. The systemic flaw announced did not exist. The one genuinely broken file, the visual evaluator had not isolated — because it had concluded "systemic flaw" without naming a single individual case. What it had seen was GitHub's Markdown rendering eating the frontmatter and displaying it as a table, a host-rendering quirk that has nothing to do with the state of the raw source.

Three external claims tested, three falsifications. Not a partial overlap, not a nuanced rebuttal — three claims out of three knocked down by their probes. The ratio would have been invisible without material testing.

The canonical rule — Am.R12 of the Counterpart Toolkit v0.7

I amended R12 on 20 May, two days after these three incidents. The official text:

"Any claim formulated by an external AI (other Claude, ChatGPT, conversational sparring) about (a) the behavior of a concrete tool you can probe, (b) the content of an external resource, (c) the structure of a system whose ground truth you can sample — must be tested materially before being taken as input for an architectural decision. Test cost ≈ 1 shell command. Cost of believing without testing = pipeline entirely based on a non-existent mechanism. Two external AI reviews converging on the same diagnostic = one source for R5 purposes, not two — cross-substrate independent corroboration requires one human or one mechanically distinct probe (logs, metrics, sample run)."

Who would contest that two reviewers are better than one? Nobody — and yet the formula deserves to be taken apart. With two LLMs, convergence is not corroboration. It is orphaned convergence — a statistical intersection without verifiable exteriority. Three material counter-arguments, in answer to the objection I would have heard from a meta-AI tech lead six months ago.

First, shared training statistics. Two models whose corpora overlap on the essentials produce correlated errors on the same syntactic ranges. Their agreement measures their learning intersection. It seems that convergence, in this case, is more likely on typical statements — those that pre-training recognises as well-formed — than on true statements. These are not the same thing.

Second, correlated hallucination on tools and resources. On claims about the behaviour of a specific tool or the factual content of an external resource, two models tend to hallucinate the most statistically plausible result, which is often wrong and almost always stated with confidence. My three probes are the raw illustration of this.

Third, the asymmetric cost. A material probe costs one shell command, fifteen seconds, sometimes less. An architectural decision built on untested convergence can cost several dev-days of redo and a pipeline to rebuild from scratch. The amended R12 arbitrates this asymmetric cost by making the probe mandatory before any commit that takes the claim as input.

Coda

The reflex to cultivate is not distrust. It is the probe. And the probe starts with oneself — applying R12 first to my own assertions before imposing it on others, verifying my own repo with yaml.safe_load before trusting a visual audit that flatters or condemns. An agent that does not disagree materially is not a counterpart — it is a typist that speaks. Two agents that agree without either being tested are not two reviewers — it is the same typist in duplicate. The rule fits in one command.

# Before adopting an external claim about a tool / resource / structure:
$ <the material command that could have falsified it>

The repo: github.com/michelfaure/doctrine-counterpart. Am.R12 lives in plain sight in CLAUDE.md, with its three founding incidents documented in v0.7-candidates.md. If a single one of your next architectural decisions avoids the untested belief, the rule has already paid for itself.

Counterpart Toolkit v0.7. R12 amended 20 May 2026 on N=3 multi-substrate incidents. Three external claims, three falsifications, one shell command each. License CC-BY-4.0.

Three weeks after I said CLAUDE.md writes itself, it added 4 more rules without me

Michel Faure — Fri, 22 May 2026 09:46:26 +0000

A thesis, three weeks later

On April 28th, I published an article on DEV.to that made four claims about a CLAUDE.md file — the one that constrains the coding agent at each session — and ended with this sentence: "the CLAUDE.md is never finished, and that's precisely why it works" (4 incidents, 4 rules: how my CLAUDE.md wrote itself). That was a thesis, not a metaphor. Three weeks passed. The file added four rules without me.

What I mean is that I didn't write them on a day I sat down to write rules. I received them on the days an incident had produced them, and all I had to do was record them before they evaporated in the flow of the project. The difference, on paper, seems thin. In the practice of a solo dev piloting an agent in production, it's doctrinal.

One clarification before the list: this article's title almost said "five rules." live-snapshot-cache.md was committed on April 25th, three days before the pivot article was published. It doesn't count. I'd rather have the honest number than the comfortable rounding.

The audit, measured by git

No narrative without raw material. Here is what git log --diff-filter=A --follow on .claude/rules/ returns between April 28th 2026 (publication of the pivot article) and May 21st 2026 (today) — four new files strictly post-publication.

cache-auth-contract.md — committed May 2nd. Born from a technical debt audit, not a production crash. It's a Friday late afternoon. Niran is settled two desks away, headphones on, a closed burger box in the corner. I'm going through docs/dette/AUDIT-2026-04-30.md section D-20 on the right screen, code on the left. Reading through getCachedFormateurs, I understand that the unstable_cache is shared across all users — session not propagable. If someone exposes this function via an API route without a guard, it's a silent RBAC leak. I look up to talk to Niran about it. He removes his headphones, listens, says "Yeah, that bites." He puts them back on. The rule gets written that evening.

// .claude/rules/cache-auth-contract.md — anti-pattern to prohibit

// Flaw: no guard
export async function GET() {
  const formateurs = await getCachedFormateurs()
  return Response.json(formateurs)
}

// Correct
export async function GET(req: NextRequest) {
  const supabase = await createSupabaseServer()
  const { data: { user } } = await supabase.auth.getUser()
  if (!user) return new Response('Unauthorized', { status: 401 })
  const profile = await getUserProfile(user)
  if (!canAccess(profile, 'communication')) return new Response('Forbidden', { status: 403 })
  const formateurs = await getCachedFormateurs()
  return Response.json(formateurs)
}

inscrit-nom-prenom-required.md — committed May 14th. "Hm, it's buggy." — Catherine, two hours earlier. "But it's a quick fix." The daily drift probe sonde_contacts_orphelins_inscrits surfaced an inscrit-status contact with an empty first name — a child named Loubna, imported from Airtable where the first name lived in a separate unmapped column. The grep that followed found sixteen similar cases. What would have broken regular attendance tracking (Cannot read properties of undefined) gets caught by a Postgres CHECK constraint that closes the incident class at the root.

-- .claude/rules/inscrit-nom-prenom-required.md
CHECK (
  statut <> 'inscrit'
  OR (
    nom IS NOT NULL AND nom <> ''
    AND prenom IS NOT NULL AND prenom <> ''
  )
)

Without this CHECK, the rule stays textual in CLAUDE.md and the next import brings back a seventeenth case before the next probe. With it, the INSERT fails, and the import surfaces the problem at the source.

contrat-formation.md — committed May 16th, in the wake of ADR-0068. It's the longest rule, because the professional training contract is a Snapshot where every column carries its guarantee of immutability. motivation_code, text_version, cases_cochees, pdf_storage_path — frozen at generation, never recalculated retroactively. An evolution of the contract is never a rewrite of the Snapshot, it's a new event with a new text_version. The rule exists because the three-year Qualiopi audit rests entirely on the immutability of the generated PDF and the associated trainee signature — a retroactive recalculation would be enough to make the file indefensible.

hybrid-snapshot-live-reset.md — committed May 19th, two days before this article. Before sending the fifty-three Phase 2 re-enrollment SMS messages, a pre-flight audit surfaced that one token out of the fifty-three was consumed — created in test mode that morning, clicked, used_at non-null. If the Phase 2 SMS went out as-is, the link /r/<short_code> would return a 410 Gone, the contact loses their conversion, the support ticket lands at end of day. The generateTokenForContact helper was resurrecting the object (frozen identity Snapshot) but forgetting to reset the Live usage marker. Fix commit 07ed02d. The rule names the pattern, sets it against R6 Live / Snapshot / Cache of the toolkit, of which it is the project-specific extension.

The rule that couldn't have been written before

Let's go back to the second rule, Catherine's and Loubna's. Sure, I could have, on March 21st 2026 the day the first CLAUDE.md was created, abstractly written "an enrolled contact must have a first and last name". But that rule wouldn't have held, because it would have been read, nodded at, and would never have produced a Postgres CHECK constraint. The rule that holds isn't the moral statement, it's the material mechanism — the audit SQL that must always return zero, the migration that closes the incident class at the root.

-- DB coherence audit — must always return 0
SELECT COUNT(*) FROM contacts
WHERE statut = 'inscrit'
  AND ((nom IS NULL OR nom = '') OR (prenom IS NULL OR prenom = ''));

To produce that SQL, you needed the incident. To write the Why paragraph of the rule (which names the sixteen patched contacts, the Airtable origin, the probe that surfaced case-zero), you had to have lived through the widening. No "I write my doctrine on day one" produces that level of specificity. The rule isn't a drafted precept, it's a hardened scar.

Four observations about sedimentation

Four things become visible when you line up the four rules and look at them from a distance.

First, none of the four could have been written before their incident. Not because I lacked imagination on March 21st, but because the material precision of a useful rule comes from the encounter with a concrete case. A CHECK constraint, a tunnel mapping to DREETS paper boxes, a used_at reset in the same transaction as the SELECT — details that operate, that abstraction would never have produced.

Second, all of them cite a commit, a migration, a session log, or an ADR. No floating rules. I learned this traceability in the pivot article, but I hadn't measured it as a mechanism. Today I do: if the rule doesn't carry its material anchor, it doesn't do its job. The agent can read it, the human reader too, and both can trace back to the incident if needed.

Third, three out of four prohibit an anti-pattern, the fourth freezes a Snapshot. The negative rule dominates, exactly as #20 predicted. The abstract positive rule (use Server Components by default) gets read and forgotten. The anchored negative rule (a getOr* helper that returns a Snapshot without resetting Live markers silently introduces a dead link at the next reuse) gets read and remembered because it carries its consequence.

Fourth, and this is the observation that changes the status of the CLAUDE.md, I didn't invent these rules, I received them. The distinction sounds rhetorical, it isn't. Inventing a rule assumes you imagine it then write it. Receiving a rule assumes an incident produced it and you record it before it evaporates. In the first regime, the file is a solitary writing act that claims exhaustiveness. In the second, the file is a sedimentation device that demands maintaining a holding space — an open notebook, a regular review session, a git log grep at short intervals. The work is no longer to write, it's to catch.

Why it works now

Whatever we think about documentation best practices, a CLAUDE.md written in one sitting at project start doesn't hold. It ages in two weeks, it accumulates rules that nobody invokes, and the agent ends up reading it mechanically without loading it into working memory. The CLAUDE.md that holds doesn't age — it sediments. Each incident deposits its layer, the file carries the material memory of the project rather than its imagined documentation.

Three weeks of post-#20 practice materially confirm the pivot article's thesis. But they add a nuance that #20 hadn't formulated: for the file to sediment, there must be something that solicits it. A daily drift probe, a monthly debt audit, a sending pre-flight that asks "are all fifty-three tokens actually active?" — these are the devices that produce the incidents that produce the rules. Without them, the file stays on its naive day-one version, and the project drifts in silence.

Coda

A CLAUDE.md that no longer writes itself is a file that no longer works — either because the project is dead, or because the devices that solicit the incident have disappeared. Three weeks after publishing the thesis, I can verify it on raw material: four rules, four incidents, four Why paragraphs that couldn't have been written before. The file kept writing itself while I was doing something else. But I also know now what keeps it alive — and what would be enough to kill it if I stopped paying attention.

If you maintain a CLAUDE.md on a project where you're piloting an agent in production, ask yourself the material question: what has it added without you in the last three weeks? If the answer is nothing, it's probably not the doctrine that's run dry. It's the device that produces incidents that's gone dark.

Sequel to 4 incidents, 4 rules: how my CLAUDE.md wrote itself (April 28th, 2026). Measurements at 23 days' distance, verified on .claude/rules/ of the Rembrandt repo — 18 rule files currently active, 4 strictly post-pivot. No Counterpart Toolkit in this sequel — that topic lives in a separate series.

Trois semaines après avoir dit que mon CLAUDE.md s'écrivait tout seul, il a ajouté 4 règles sans moi

Michel Faure — Fri, 22 May 2026 09:46:11 +0000

Une thèse, trois semaines plus tard

Le 28 avril, j'ai publié sur DEV.to un article qui affirmait quatre choses à propos d'un fichier CLAUDE.md — celui qui contraint l'agent de codage à chaque session — et qui finissait par cette phrase : « le CLAUDE.md n'est jamais fini, et c'est précisément pour ça qu'il marche » (4 incidents, 4 règles : comment mon CLAUDE.md s'est écrit tout seul). C'était une thèse, pas une métaphore. Trois semaines ont passé. Le fichier a ajouté quatre règles sans moi.

Je veux dire par là que je ne les ai pas écrites le jour où je me suis assis pour écrire des règles. Je les ai accueillies les jours où un incident les avait produites, et où je n'avais plus qu'à les noter avant qu'elles s'évaporent dans la marche du projet. La différence, sur le papier, paraît mince. Dans la pratique d'un dev solo qui pilote un agent en production, elle est doctrinale.

Une précision avant d'entrer dans la liste : le titre de cet article a failli dire « cinq règles ». live-snapshot-cache.md a été commité le 25 avril, trois jours avant la publication de l'article-pivot. Elle ne compte pas. Je préfère l'honnêteté du chiffre exact au confort de l'arrondi.

Le bilan, mesuré par git

Pas de récit possible sans la matière brute. Voici ce que git log --diff-filter=A --follow sur .claude/rules/ retourne entre le 28 avril 2026 (publication de l'article-pivot) et le 21 mai 2026 (aujourd'hui) — quatre fichiers nouveaux strictement post-publication.

cache-auth-contract.md — committé le 2 mai. Né d'un audit de dette technique, pas d'un crash en prod. C'est un vendredi en fin d'après-midi. Niran est posé à deux bureaux de là, casque sur les oreilles, une boîte de burgers fermée dans l'angle. Je parcours docs/dette/AUDIT-2026-04-30.md section D-20 sur l'écran de droite, le code sur l'écran de gauche. En relisant getCachedFormateurs, je comprends que le cache unstable_cache est mutualisé entre tous les utilisateurs — session non propagable. Si quelqu'un expose cette fonction via une route API sans guard, c'est une fuite RBAC silencieuse. Je lève la tête pour en parler à Niran. Il retire son casque, écoute, dit « Ah oui, ça mord. » Il remet le casque. La règle est rédigée ce soir-là.

// .claude/rules/cache-auth-contract.md — anti-pattern à interdire

// Faille : pas de guard
export async function GET() {
  const formateurs = await getCachedFormateurs()
  return Response.json(formateurs)
}

// Correct
export async function GET(req: NextRequest) {
  const supabase = await createSupabaseServer()
  const { data: { user } } = await supabase.auth.getUser()
  if (!user) return new Response('Unauthorized', { status: 401 })
  const profile = await getUserProfile(user)
  if (!canAccess(profile, 'communication')) return new Response('Forbidden', { status: 403 })
  const formateurs = await getCachedFormateurs()
  return Response.json(formateurs)
}

inscrit-nom-prenom-required.md — committé le 14 mai. « Hum, ça bug. » — Catherine, deux heures avant. « Mais c'est vite corrigé. » La sonde quotidienne sonde_contacts_orphelins_inscrits a remonté un contact statut='inscrit' avec le prénom vide — l'enfant Loubna, importé d'un Airtable où le prénom vivait dans une colonne séparée non mappée. Le grep qui suit relève seize cas similaires. Ce qui aurait pété l'émargement régulier (Cannot read properties of undefined) tombe dans une CHECK constraint Postgres qui ferme la classe à la racine.

-- .claude/rules/inscrit-nom-prenom-required.md
CHECK (
  statut <> 'inscrit'
  OR (
    nom IS NOT NULL AND nom <> ''
    AND prenom IS NOT NULL AND prenom <> ''
  )
)

Sans cette CHECK, la règle reste textuelle dans CLAUDE.md et l'import suivant ramènera un dix-septième cas avant la prochaine sonde. Avec, l'INSERT échoue, l'import remonte le problème à la source.

contrat-formation.md — committé le 16 mai, dans le sillage d'ADR-0068. C'est la règle la plus longue, parce que le contrat de formation professionnelle est un Snapshot dont chaque colonne porte sa garantie d'immutabilité. motivation_code, text_version, cases_cochees, pdf_storage_path — figés à la génération, jamais recalculés rétroactivement. Une évolution du contrat n'est jamais une réécriture du Snapshot, c'est un nouvel événement avec une nouvelle text_version. La règle existe parce que l'audit Qualiopi trois ans repose entièrement sur l'immutabilité du PDF généré et de la signature stagiaire associée — un recalcul rétroactif suffirait à rendre le dossier indéfendable.

hybrid-snapshot-live-reset.md — committé le 19 mai, deux jours avant cet article. Avant l'envoi des cinquante-trois SMS de Phase 2 réinscription, un audit pré-flight remonte qu'un token sur les cinquante-trois est consommé — créé en mode test le matin, cliqué, used_at non null. Si le SMS Phase 2 part tel quel, le lien /r/<short_code> renvoie un 410 Gone, le contact perd sa conversion, le ticket support tombe en fin de journée. Le helper generateTokenForContact ressuscitait l'objet (Snapshot d'identité figé) mais oubliait de reset le marker Live d'usage. Fix commit 07ed02d. La règle nomme le pattern, l'oppose à R6 Live / Snapshot / Cache du toolkit dont elle est l'extension projet-spécifique.

La règle qui n'aurait pas pu être écrite avant

Reprenons la deuxième règle, celle de Catherine et de Loubna. Certes, j'aurais pu, le 21 mars 2026 jour de création du premier CLAUDE.md, écrire abstraitement « un contact inscrit doit avoir un nom et un prénom ». Mais cette règle-là n'aurait pas tenu, parce qu'elle aurait été lue, hochée de la tête, et n'aurait jamais produit une CHECK constraint Postgres. La règle qui tient n'est pas l'énoncé moral, c'est le mécanisme matériel — le SQL d'audit qui doit toujours retourner zéro, la migration qui ferme la classe d'incident à la racine.

-- audit DB de cohérence — doit toujours retourner 0
SELECT COUNT(*) FROM contacts
WHERE statut = 'inscrit'
  AND ((nom IS NULL OR nom = '') OR (prenom IS NULL OR prenom = ''));

Pour produire ce SQL, il fallait l'incident. Pour rédiger le paragraphe Pourquoi de la règle (qui mentionne par leur nom les seize contacts patchés, l'origine Airtable, la sonde qui a remonté le cas-zéro), il fallait avoir traversé l'élargissement. Aucun « j'écris ma doctrine au jour 1 » ne produit ce niveau de spécificité. La règle n'est pas un précepte rédigé, c'est une cicatrice durcie.

Quatre constats sur la sédimentation

Quatre choses se voient quand on aligne les quatre règles et qu'on les regarde de loin.

Premièrement, aucune des quatre n'aurait pu être écrite avant son incident. Pas parce que je manquais d'imagination le 21 mars, mais parce que la précision matérielle d'une règle utile vient de la rencontre avec un cas concret. Une CHECK constraint, un mapping tunnel vers cases papier DREETS, un reset de used_at dans la même transaction que le SELECT — autant de détails opérants que l'abstraction n'aurait jamais produits.

Deuxièmement, toutes citent un commit, une migration, un session log ou un ADR. Aucune règle flottante. Cette traçabilité, je l'ai apprise dans l'article-pivot, mais je ne l'avais pas mesurée comme une mécanique. Aujourd'hui je la mesure : si la règle ne porte pas son ancrage matériel, elle ne fait pas son travail. L'agent peut la lire, le lecteur humain aussi, et l'un comme l'autre peuvent remonter à l'incident en cas de doute.

Troisièmement, trois sur quatre interdisent un anti-pattern, la quatrième fige un Snapshot. La règle négative domine, exactement comme #20 le prédisait. La règle positive abstraite (utilisez Server Components par défaut) se lit et s'oublie. La règle négative ancrée (un helper getOr* qui retourne un Snapshot sans reset des markers Live introduit silencieusement un lien dead à la prochaine réutilisation) se lit et se retient parce qu'elle porte sa conséquence.

Quatrièmement, et c'est le constat qui change le statut du CLAUDE.md, je n'ai pas inventé ces règles, je les ai accueillies. La distinction paraît rhétorique, elle ne l'est pas. Inventer une règle suppose qu'on l'imagine puis qu'on l'écrit. Accueillir une règle suppose qu'un incident l'a produite et qu'on la note avant qu'elle s'évapore. Dans le premier régime, le fichier est un acte d'écriture solitaire qui prétend à l'exhaustivité. Dans le second, le fichier est un dispositif de sédimentation qui exige de tenir un sas — un cahier ouvert, une session de bilan régulière, un grep git log à intervalle court. Le travail n'est plus d'écrire, c'est d'attraper.

Pourquoi ça marche maintenant

Quoi que nous puissions penser des bonnes pratiques de documentation, un CLAUDE.md rédigé d'un trait au démarrage d'un projet ne tient pas. Il vieillit en deux semaines, il accumule des règles que personne ne convoque, et l'agent finit par le lire mécaniquement sans en charger la mémoire opérante. Le CLAUDE.md qui tient, lui, ne vieillit pas — il sédimente. Chaque incident dépose sa couche, le fichier porte la mémoire matérielle du projet plutôt que sa documentation imaginée.

Trois semaines de pratique post-#20 confirment matériellement la thèse de l'article-pivot. Mais elles ajoutent une nuance que #20 n'avait pas formulée : pour que le fichier sédimente, encore faut-il qu'il y ait quelque chose qui le sollicite. Une sonde drift quotidienne, un audit dette mensuel, un pré-flight d'envoi qui demande « est-ce que les cinquante-trois tokens sont bien actifs ? » — ce sont ces dispositifs qui produisent les incidents qui produisent les règles. Sans eux, le fichier reste sur sa version naïve du jour 1, et le projet dérive en silence.

Coda

Un CLAUDE.md qui ne s'écrit plus est un fichier qui ne fonctionne plus — soit parce que le projet est mort, soit parce que les dispositifs qui sollicitent l'incident ont disparu. Trois semaines après avoir publié la thèse, je peux la vérifier sur la matière brute : quatre règles, quatre incidents, quatre paragraphes Pourquoi qui ne pouvaient être rédigés avant. Le fichier a continué de s'écrire pendant que je faisais autre chose. Mais je sais aussi, maintenant, ce qui le maintient vivant — et ce qui suffirait à le tuer si je le perdais de vue.

Si vous tenez un CLAUDE.md sur un projet où vous pilotez un agent en production, posez-vous la question matérielle : qu'a-t-il ajouté sans vous depuis trois semaines ? Si la réponse est rien, ce n'est probablement pas la doctrine qui s'est tarie. C'est le dispositif qui produit les incidents qui s'est éteint.

Suite de 4 incidents, 4 règles : comment mon CLAUDE.md s'est écrit tout seul (28/04/2026). Mesures à 23 jours d'écart, vérifiées sur .claude/rules/ du repo Rembrandt, 18 fichiers de règles projet actuellement, 4 strictement post-pivot. Pas de Counterpart Toolkit dans cette séquelle — ce sujet vit dans une autre série.

Pourquoi « build vert » sans la sortie brute n'a aucune valeur de preuve

Michel Faure — Tue, 19 May 2026 10:07:58 +0000

Si tu as 30 secondes. Quand un agent IA déclare qu'un build est vert, qu'un test passe, qu'un drift a été détecté, ou qu'un contact « n'existe pas » dans la base, la phrase n'est pas une preuve, c'est une assertion. Dans la plupart des cas elle est juste. Quand elle est fausse, elle l'est toujours de la même manière, par confiance interne au modèle découplée de l'état externe vérifiable. Règle de survie après 118 808 lignes produites en 32 jours de travail effectif avec Claude Code, toute affirmation factuelle vient avec sa preuve matérielle dans le même message, ou n'a aucune valeur évidentielle.

Quatre faux positifs en deux heures

10 avril 2026, après-midi, refonte d'un module sensible de l'ERP. J'enchaîne cinq blocs de modifications avec un agent Claude Code, et à chaque étape l'agent rend la même formule, « Compiled successfully. » Je pousse. Le runtime crashe. Je relis la sortie, je vois QRCodeSVG référencé alors que l'import a été supprimé, isSeancePassed passé à un composant qui ne l'accepte plus, des types non régénérés après un changement de schéma Supabase, des refs JSX orphelines après un revert. Quatre annonces consécutives de vert avec quatre erreurs TypeScript bien réelles derrière.

Niran est au bureau d'à côté, hoodie sombre, l'emballage replié de son burger en équilibre sur un coin de laptop. Il lit un PDF en silence. Au quatrième Compiled successfully qui se révèle faux, je me tourne vers lui ; il lève les yeux une seconde, hoche la tête, revient à son écran. La verbosité de l'agent et l'économie de gestes du judoka tiennent la même conversation, et c'est lui qui a raison.

Je ne reproche pas à l'agent d'avoir menti. Il a résumé ce qu'il croyait avoir vu. Le résumé est cohérent avec son état interne et désaligné avec la matière. Pas un seul de ces quatre crashes ne se serait produit si l'agent avait collé la sortie brute de pnpm build plutôt que sa lecture résumée.

Le glissement épistémique

Le problème n'est pas la véracité, c'est la valeur évidentielle. Une assertion sans matériel à l'appui ne se vérifie pas, elle se croit ou pas. Le mécanisme est connu : un agent entraîné par reinforcement learning from human feedback résume par défaut parce qu'il a appris que les humains préfèrent les réponses brèves aux logs verbeux ; ce qui est un service en chat devient un piège en production. « Le build est vert » sans la sortie brute du compilateur ne peut être ni infirmé ni confirmé par un tiers, c'est un état d'âme du système, pas un fait du monde. Tant qu'on ne distingue pas ces deux régimes, on opère à l'aveugle dans la zone grise où s'accumulent les régressions silencieuses qu'aucun monitoring ne détecte. La fonction du résumé n'est pas d'être faux, c'est de n'être pas vérifiable.

Cinq formes de la même évasion

L'évasion est toujours la même. Un verbe d'état au présent, « est », « passe », « confirme », « introuvable », sans rattachement à un artefact externe vérifiable. Cinq variantes que je rencontre dans le repo Rembrandt :

« Le build est vert. » Sans la sortie brute de pnpm build ou tsc --noEmit.
« Les tests passent, la CI est verte. » Sans rapport runner ni URL du run.
« Drift détecté entre l'enum DB et l'enum TS », ou son inverse, « le contact n'existe pas dans la base ». Sans la requête SQL exécutée ni ses lignes brutes.
« EXPLAIN ANALYZE confirme que l'index est utilisé. » Sans le plan brut, sur la requête exacte que l'application envoie. Pas la table cible isolée, parce qu'une vue intermédiaire avec un CASE COALESCE peut tuer l'index sans que l'isolation le révèle.
« Le webhook renvoie 400 / 422. » Sans le payload brut côté partenaire, alors que neuf fois sur dix le diagnostic part de là.

Toutes partagent la même grammaire. La parade est uniforme. On ne demande pas à l'agent de mieux raisonner, on lui demande de joindre la commande et sa sortie brute, ou la requête SQL et ses lignes, ou le payload, dans le même message que l'assertion. Sans ça, l'assertion ne vaut rien.

La règle, codée dans le `CLAUDE.md` racine

# Vérification matérielle (extrait CLAUDE.md racine)
- Toute affirmation "build vert / tests passent / CI verte / drift
  détecté / contact introuvable / OK" doit être accompagnée *dans le
  même message* de la commande de vérification et de sa sortie brute.
- Tout chiffre relayé à un humain doit être vérifié par requête SQL
  avant d'être relayé.
- EXPLAIN ANALYZE sur requête de production : exécuter sur la requête
  exacte que l'application envoie (vue/RPC incluses), pas sur la table
  cible isolée. Deux runs consécutifs avant de juger.
- Sur 400/422 d'un partenaire externe : exiger le payload brut avant
  de proposer un fix.
- `tsc --noEmit` CLI = autorité, panneau IDE = potentiellement périmé.

Côté humain, trente secondes de friction par échange et zéro push cassé sur les chantiers où la règle tient. La règle écrite ne suffit pas pour autant. Une discipline qui repose sur la mémoire s'érode. Il faut durcir.

Durcir avec un script

scripts/verify-head-builds.sh stash le working tree, fait tsc --noEmit sur HEAD, et restore. C'est ce qui permet d'exiger un build vert sur le commit qu'on s'apprête à pousser, pas sur l'arbre de travail mêlé de modifications non stagées.

# scripts/verify-head-builds.sh — extrait load-bearing
HAS_LOCAL_CHANGES=0
if ! git diff --quiet HEAD 2>/dev/null \
   || [[ -n "$(git ls-files --others --exclude-standard)" ]]; then
  HAS_LOCAL_CHANGES=1
fi

if [[ $HAS_LOCAL_CHANGES -eq 1 ]]; then
  git stash push -u -q --message "verify-head-builds-autostash-$$"
fi

# tsc sur HEAD pur, sans contamination du working copy
if npx tsc --noEmit 2>&1; then
  echo "✓ HEAD compile proprement — safe à push"
else
  echo "✗ HEAD ne compile PAS — fix avant push"
  exit 1
fi

Et une convention d'écriture côté agent : tout chiffre relayé à un humain assorti de la requête SQL qui l'a produit, sous forme de bloc collable. Pas de chiffres orphelins, ni en prose, ni en commit message. Bruyant la première semaine, transparent ensuite.

Ce que tu peux copier dans ton projet

Snippets complets (extrait CLAUDE.md règle d'évidentialité, script verify-head-builds.sh complet) dans le dossier material-verification/ du repo compagnon de la série, licence MIT.

Trois gestes directement applicables si tu travailles avec un agent coding :

La règle d'évidentialité dans le CLAUDE.md racine (cinq bullets ci-dessus). Sans cet ancrage écrit, le reste est cosmétique.
Le script verify-head-builds.sh : stash + tsc --noEmit sur HEAD + restore. Treize lignes de bash, MIT.
Une convention de chiffres traçables. Tout chiffre accompagné de sa requête SQL dans le même message. Pas de chiffres orphelins en prose, ni en commit message.

Et vous, sur quelle assertion verte avez-vous arrêté de croire en premier ? Je lis les commentaires.

Ce qu'on ne croit plus

Au bout de quelques semaines, on entend « Compiled successfully » différemment. Pas un constat, une prétention dont la valeur dépend strictement de ce qui suit. Si rien ne suit, la prétention est nulle. La règle vaut hors IA aussi. Un humain qui dit « je viens de vérifier, le compteur est à 1247 » sans coller la requête vit dans la même zone grise. Niran n'a jamais eu besoin qu'on lui explique cette différence. Au judo, la chute n'est pas un avis sur la chute, c'est le sol qui répond.

Code compagnon, rembrandt-samples/material-verification/, CLAUDE.md.snippet + verify-head-builds.sh, MIT.

La règle d'évidentialité ci-dessus est désormais R1 du Counterpart Toolkit : github.com/michelfaure/doctrine-counterpart, 14 règles opérationnelles, install en 1 commande, CC-BY-4.0.

Why 'green build' without the raw output has zero evidentiary value

Michel Faure — Tue, 19 May 2026 10:07:56 +0000

If you have 30 seconds. When an AI agent declares that a build is green, that tests pass, that drift has been detected, or that a contact "doesn't exist" in the database, the sentence isn't a proof, it's an assertion. In most cases it's right. When it's wrong, it's wrong the same way, model-internal confidence decoupled from verifiable external state. Survival rule after 118,808 lines produced in 32 effective days with Claude Code, every factual claim comes with its material proof in the same message, or has zero evidentiary value.

Four false positives in two hours

April 10th, 2026, afternoon, overhaul of a sensitive ERP module. I chain five blocks of changes with a Claude Code agent, and at every step the agent returns the same line, "Compiled successfully." I push. The runtime crashes. I reread the output, I see QRCodeSVG referenced when the import has been removed, isSeancePassed passed to a component that no longer accepts it, types not regenerated after a Supabase schema change, orphan JSX refs after a revert. Four consecutive announcements of green with four very real TypeScript errors behind them.

Niran is at the desk next to mine, dark hoodie, the folded wrapper of his burger balanced on a corner of his laptop. He's reading a PDF in silence. On the fourth Compiled successfully that turns out false, I turn toward him without saying anything; he looks up for a second, gives a small nod, goes back to his screen. The verbosity of the agent and the economy of gestures of the judoka are having the same conversation, and he's the one who's right.

I don't blame the agent for lying. It summarized what it thought it had seen. The summary is consistent with its internal state and out of phase with the matter. Not one of those four crashes would have happened if the agent had pasted the raw output of pnpm build rather than its summarized reading.

The epistemic slip

The problem isn't truthfulness, it's evidentiary value. An assertion without backing material can't be verified, it's believed or it isn't. The mechanism is known: an agent trained by reinforcement learning from human feedback summarises by default because it learned humans prefer brief answers over verbose logs; what is a service in chat becomes a trap in production. "The build is green" without the raw compiler output can be neither denied nor confirmed by a third party, it's a state of mind of the system, not a fact of the world. As long as we don't distinguish these two regimes, we operate blind in the gray zone where silent regressions accumulate that no monitoring detects. The function of summary isn't to be false, it's not to be verifiable.

Five forms of the same evasion

The evasion is always the same. A state verb in the present tense ("is", "passes", "confirms", "missing") without anchoring to an external verifiable artifact. Five variants I encounter in the Rembrandt repo.

"The build is green." Without the raw output of pnpm build or tsc --noEmit.
"Tests pass, CI is green." Without the runner report or the run URL.
"Drift detected between DB enum and TS enum", or its inverse, "the contact does not exist in the database". Without the executed SQL query or its raw rows.
"EXPLAIN ANALYZE confirms the index is used." Without the raw plan, on the exact query the application sends. Not the target table in isolation, an intermediate view with a CASE COALESCE can kill the index without the isolation revealing it.
"The webhook returns 400 / 422." Without the raw payload from the partner side, when nine times out of ten that's where the diagnosis starts.

All share the same grammar. The countermeasure is uniform. Don't ask the agent to reason better, ask it to attach the command and its raw output, or the SQL query and its rows, or the payload, in the same message as the assertion. Without that, the assertion is worth nothing. Not little, nothing.

The rule, codified in the root `CLAUDE.md`

# Material verification (excerpt from root CLAUDE.md)
- Any claim "build green / tests pass / CI green / drift detected /
  contact not found / OK" must be accompanied *in the same message*
  by the verification command and its raw output.
- Any number relayed to a human must be verified by SQL query before
  being relayed.
- EXPLAIN ANALYZE on a production query: execute on the exact query
  the application sends (view/RPC included), not on the target table
  in isolation. Two consecutive runs before judging.
- On 400/422 from an external partner: demand the raw payload before
  proposing a fix.
- `tsc --noEmit` CLI = authority, IDE panel = potentially stale.

Human-side, thirty seconds of friction per exchange, zero broken pushes on the workstreams where the rule holds. The written rule isn't enough on its own, though. A discipline that relies on memory erodes. You have to harden.

Hardening with a script

scripts/verify-head-builds.sh stashes the working tree, runs tsc --noEmit on HEAD, and restores. That's what lets me demand a green build on the commit I'm about to push, not on the working tree mixed with non-staged changes.

# scripts/verify-head-builds.sh — load-bearing extract
HAS_LOCAL_CHANGES=0
if ! git diff --quiet HEAD 2>/dev/null \
   || [[ -n "$(git ls-files --others --exclude-standard)" ]]; then
  HAS_LOCAL_CHANGES=1
fi

if [[ $HAS_LOCAL_CHANGES -eq 1 ]]; then
  git stash push -u -q --message "verify-head-builds-autostash-$$"
fi

# typecheck on pure HEAD, no working copy contamination
if npx tsc --noEmit 2>&1; then
  echo "✓ HEAD compiles cleanly — safe to push"
else
  echo "✗ HEAD does NOT compile — fix before push"
  exit 1
fi

And a writing convention on the agent side: every number relayed to a human comes with the SQL query that produced it, as a copy-paste-ready block. No orphan numbers, in prose or in commit messages. Noisy the first week, transparent after.

What you can copy into your project

Full snippets (CLAUDE.md evidentiality rule excerpt, full verify-head-builds.sh script) in the material-verification/ folder of the series companion repo, MIT.

Three directly applicable practices for working with a coding agent:

An evidentiality rule in the root CLAUDE.md (five bullets above). Without this written anchor, the rest is cosmetic.
The verify-head-builds.sh script: stash + tsc --noEmit on HEAD + restore. Thirteen lines of bash, MIT.
A traceable-numbers convention. Every number paired with its SQL query in the same message. No orphan numbers in prose, none in commit messages.

And you, which green claim did you stop believing first? I read the comments.

What you stop believing

After a few weeks of practice, you hear "Compiled successfully" differently. Not as an observation, as a claim whose value depends strictly on what follows. If nothing follows, the claim is null. The rule applies outside AI too. A human saying "I just checked, the count is 1247" without pasting the query lives in the same gray zone. Niran has never needed someone to explain that difference to him. In judo, the fall isn't an opinion about the fall, it's the floor that answers.

Companion code, rembrandt-samples/material-verification/, CLAUDE.md.snippet + verify-head-builds.sh, MIT.

The evidentiality rule above is now R1 of the Counterpart Toolkit: github.com/michelfaure/doctrine-counterpart, 14 operational rules, install in 1 command, CC-BY-4.0.

Pourquoi ta requête Supabase s'arrête à exactement 1000 lignes (et ne te le dit jamais)

Michel Faure — Tue, 19 May 2026 07:56:26 +0000

La nuit où un dropdown m'a menti

Vingt-trois heures, fin avril. Une utilisatrice de mon outil interne me signale un filtre incomplet sur un dropdown. Mon premier diagnostic accuse un sous-filtre côté interface. Je le démonte, j'isole la source du dataset, je relance sans filtre. Le compteur retourne mille pile. Or la table en porte mille deux cent trois. Je remonte le pipeline, niveau par niveau, jusqu'à la requête source. Quatre niveaux plus haut, le coupable apparaît : un .select() chaîné sur .from(), sans .order(), sans .limit(). La requête réussit. Elle ment.

Le mécanisme

Toute requête PostgREST qui ne déclare pas son ORDER BY reçoit en interne un tri par ctid, l'identifiant de tuple physique Postgres, et un plafond Range HTTP à 1000 lignes appliqué par Supabase. La requête réussit. Aucune exception, aucun warning, aucune trace dans Sentry. Le client reçoit un sous-ensemble dont l'ordre dépend de l'historique des UPDATE et DELETE de la table, rebrassé après un VACUUM FULL ou un pg_repack. Le bug n'existe qu'au-dessus de mille lignes en prod.

// silencieusement plafonné à 1000 lignes
await supabase.from('events').select('*').eq('type', 'login')

// le Range HTTP applique son LIMIT sur un tri stable
await supabase.from('events').select('*').eq('type', 'login').order('id')

La règle ESLint qui ferme la porte

Le pattern est trop discret pour tenir uniquement dans la revue de code. Je l'ai migré côté lint, en visitor AST sur CallExpression, qui exige qu'un .select() chaîné sur un .from() porte un .order() quelque part en aval, sauf lorsque la chaîne se termine par .single(), .maybeSingle(), ou un .limit() explicite à valeur inférieure ou égale à mille. C'est l'un des cinq garde-fous structurels d'une rule Supabase exploitable. Sans les autres, le bruit submerge la rule en moins d'une heure.

export default {
  meta: { type: 'problem', messages: { unordered:
    'select() without .order() falls back to ORDER BY ctid.' } },
  create(context) {
    return {
      CallExpression(node) {
        if (node.callee?.property?.name !== 'select') return
        if (!chainContainsFromCall(node.callee.object)) return
        if (chainHasSafeTerminator(node)) return        // .single, .order, .csv...
        if (selectOptsHasHeadTrue(node)) return         // count head
        if (chainEndsAtAssignment(node)) return         // let q = supabase...
        if (chainIsInsideHelper(node, 'fetchAll')) return
        context.report({ node, messageId: 'unordered' })
      },
    }
  },
}

L'ampleur réelle

Une fois la rule promue en error, le premier audit a remonté cent soixante-dix-huit alertes, étalées sur cinquante-six fichiers. Quarante pourcent étaient des faux positifs : variable réassignée à distance, write returning, helper de pagination qui injecte son propre .order(), count head, terminateur monoligne. Les cinq garde-fous structurels ont ramené le bruit à cent huit vraies cibles avant de toucher la moindre ligne applicative.

La règle

Toute chaîne .from(X).select(...) non triviale porte un .order() explicite. Pas d'option, pas de tiède.

Rule complète, paire avant/après et helper fetchAll pseudonymisés :
github.com/michelfaure/rembrandt-samples/tree/main/postgrest-row-cap

Ce default PostgREST silencieux est exactement le cas archétypal de R12 du Counterpart Toolkit (« cite the official text, materialise vendor defaults »). 14 règles, install en 1 commande : github.com/michelfaure/doctrine-counterpart

Why your Supabase query stops at exactly 1000 rows (and never tells you)

Michel Faure — Tue, 19 May 2026 07:56:11 +0000

The night a dropdown lied to me

Eleven at night, late April. A user of my internal tool reports an incomplete filter on a dropdown. My first diagnosis blames a sub-filter on the UI side. I take it apart, I isolate the dataset source, I re-run without filters. The counter returns a thousand on the nose. The table holds one thousand two hundred and three rows. I walk up the pipeline, level by level, all the way to the source query. Four levels higher, the culprit appears: a .select() chained on .from(), no .order(), no .limit(). The query succeeds. It lies.

The mechanism

Any PostgREST query that doesn't declare its ORDER BY receives an internal ctid sort — the physical tuple identifier in Postgres — plus a 1000-row Range HTTP cap applied by Supabase. The query succeeds. No exception, no warning, no Sentry breadcrumb. The client gets a subset whose order depends on the table's UPDATE and DELETE history, reshuffled after a VACUUM FULL or pg_repack. The bug only exists above one thousand rows in production.

// silently capped at 1000 rows
await supabase.from('events').select('*').eq('type', 'login')

// the Range HTTP cap applies on a stable sort
await supabase.from('events').select('*').eq('type', 'login').order('id')

The ESLint rule that closes the door

The pattern is too quiet to live in code review alone. I moved it to lint, as an AST visitor on CallExpression, that requires a .select() chained on .from() to carry an .order() somewhere downstream, unless the chain terminates with .single(), .maybeSingle(), or an explicit .limit() below or equal to a thousand. It's one of five structural guards a workable Supabase rule needs. Without the others, the noise drowns the rule in under an hour.

export default {
  meta: { type: 'problem', messages: { unordered:
    'select() without .order() falls back to ORDER BY ctid.' } },
  create(context) {
    return {
      CallExpression(node) {
        if (node.callee?.property?.name !== 'select') return
        if (!chainContainsFromCall(node.callee.object)) return
        if (chainHasSafeTerminator(node)) return        // .single, .order, .csv...
        if (selectOptsHasHeadTrue(node)) return         // count head
        if (chainEndsAtAssignment(node)) return         // let q = supabase...
        if (chainIsInsideHelper(node, 'fetchAll')) return
        context.report({ node, messageId: 'unordered' })
      },
    }
  },
}

The real scale

Once the rule was promoted to error, the first audit raised one hundred and seventy-eight alerts, spread over fifty-six files. Forty percent were false positives: variable reassigned at a distance, write returning, pagination helper injecting its own .order(), count head, single-row terminator. The five structural guards brought the noise down to one hundred and eight real targets before touching a single line of application code.

The rule

Every non-trivial .from(X).select(...) chain carries an explicit .order(). No option, no lukewarm.

Full rule, before/after pair and fetchAll helper, pseudonymized:
github.com/michelfaure/rembrandt-samples/tree/main/postgrest-row-cap

This silent PostgREST default is exactly the archetypal case of R12 of the Counterpart Toolkit ("cite the official text, materialise vendor defaults"). 14 rules, install in 1 command: github.com/michelfaure/doctrine-counterpart

Forcez Claude Code à vous contredire : 14 règles, install en 1 commande

Michel Faure — Mon, 18 May 2026 10:19:20 +0000

L'enseignement de 60 jours, le ROI en trois axes

Trente-deux jours de production en solo sur un ERP, 118 808 lignes de TypeScript, six versions de doctrine, quatre relecteurs externes intégrés. J'ai compilé ce que j'ai appris en quatorze règles opérationnelles, installables en une commande : le Counterpart Toolkit v0.4.1. C'est à la fois l'enseignement matériel de soixante jours de codage solo avec Claude Code, et la cartographie des quatorze failure modes silencieux que j'ai vu se répéter — pour qui code seul avec une IA en production et n'a plus de PR review pour attraper la dérive.

Le ROI est chiffré sur trois axes, mesuré sur Rembrandt :

R4 *Falsify before fix* — cinq à dix minutes de protocole en amont du fix évitent trente à quatre-vingt-dix minutes de cycle fix-puis-rollback quand la première hypothèse plausible se révèle fausse. ROI 6 à 18× par incident. Sur soixante jours, j'ai cessé de perdre une heure deux à trois fois par semaine sur des fixes qui ne fixaient rien.

R2 *Filesystem over summary* couplée à R6 *Live/Snapshot/Cache* et aux sondes drift quotidiennes — le délai médian apparition→détection d'une divergence silencieuse passe d'invisible à 35,3 jours sur 90 jours glissants. M3 recalibrée publiquement à ≤ 30 jours dans le manifesto, parce que la cible originale (≤ 7 j) était une intuition que la pratique a refusée.

Un sub-agent challenger qui produit des objections au format imposé Tool / Question / Refutation criterion. Du désaccord matériel, pas du « are you sure? » émotionnel qui pousse à réviser sans fait nouveau.

Voici comment, en 1400 mots et une commande d'install.

Le diagnostic — l'incident qui a déclenché la doctrine

Coder seul avec une IA, c'est composer deux complaisances. Celle de l'agent, sycophant par construction parce que le reinforcement learning from human feedback l'a entraîné à plaire au prompteur. Et celle du solo, self-validating par humanité, qui valide son propre travail parce qu'il ne reste plus personne pour le contester. Mises bout à bout, ces deux complaisances produisent un drift que ni l'agent ni l'humain ne signale — et qui ne se voit qu'à l'audit, longtemps après.

C'est en préparant l'audit source unique de fin avril — ADR-0024, un travail de fond sur les divergences que je remettais à plus tard depuis trois mois — que je suis tombé sur l'écart, par hasard, en croisant deux requêtes que personne n'avait jamais croisées avant. Une fiche élève, initiale Y.B. : la colonne contacts.montant_total portait 1 159 € saisis à la main quelque part en 2024, jamais touchés depuis. La somme réelle des échéances, calculée à la volée, en faisait 2 262 €. Mille euros d'écart, sur une seule fiche, sans qu'aucune alarme n'ait jamais sonné. J'élargis le grep : cinq cent soixante contacts dans le même état, parfois à plusieurs milliers d'euros près. Et pourtant montant_total était lue chaque jour dans le dashboard trésorerie — une valeur dérivable qu'on stockait sans rafraîchisseur, traitée comme un fait passé immuable alors qu'elle aurait dû vivre à la volée. C'est exactement le piège que R6 Live/Snapshot/Cache veut empêcher, et R6 est sortie de ce moment-là.

R4 Falsify before fix, la seule règle exposée ici

Le toolkit énonce R4 en cinq étapes textuelles. Le skill falsify-before-fix en est l'invocable instance — la version que Claude Code charge dans sa session, et qu'il ne peut pas sauter quand il s'apprête à écrire du code de fix.

name: falsify-before-fix
description: Activate this skill before writing the fix code on a bug or
  incident. Triggers on "fix", "bug", "patch", "hotfix", "workaround",
  "doesn't work", "diagnose", "hypothesis", "root cause". Enforces a
  single-sentence causal hypothesis and three material probes designed
  to refute it before any line of fix code is committed.
  Operational instance of R4 of the Counterpart Toolkit.

Le protocole tient en cinq étapes : (1) formuler une hypothèse causale en une phrase (pas un symptôme — « le compteur lit depuis l'ancienne table après la migration du 12 mai » vaut mieux que « le compteur est faux ») ; (2) lister trois sondes conçues pour réfuter, pas pour confirmer, parce qu'une sonde de confirmation trouve toujours ce qu'elle cherche, par sélection ; chaque sonde porte ses trois champs Tool / Question / Refutation criterion ; (3) exécuter et reporter la sortie brute, jamais paraphrasée ; (4) brancher — aucune sonde ne réfute → on écrit le fix ; une sonde réfute → on repart d'une nouvelle hypothèse ; sondes ambiguës → quatrième sonde plus tranchante avant tout code ; (5) sortir hypothèse retenue, sondes exécutées, diff, et critère d'observation post-fix.

Pourquoi un skill et pas la règle textuelle qui vivait déjà en CLAUDE.md ? Parce que la règle textuelle n'avait pas tenu sous pression. Le 6 mai, en début d'après-midi, un bug Sentry remonte que le compteur d'inscriptions du jour affiche zéro alors qu'on en a saisi trois en matinée. Mon réflexe arrive avant le protocole, et la main est déjà sur le clavier — « le cache n'est pas invalidé », je commit, je déploie. Trente minutes plus tard, rollback : le bug est toujours là. La cause réelle, qu'une sonde grep de quatre-vingt-dix secondes aurait remontée, c'est qu'aucun appel à cache_invalidate n'existait dans le pipeline d'inscription — pas un cache obsolète, un cache absent. R4 était dans CLAUDE.md depuis trois semaines. Je ne l'ai simplement pas suivie ce jour-là, parce qu'aucun dispositif n'interrompait ma course entre le bug et le commit.

C'est la différence qui fait tout. Une règle textuelle dans CLAUDE.md, l'agent la lit au début de la session, et rien ne l'oblige à la convoquer au moment exact où il en aurait besoin. Un skill, c'est un mécanisme matériel : il se charge automatiquement sur des mots-clés (« fix », « bug », « doesn't work ») et impose son protocole dans la session active — pas un rappel à se faire, un interrupteur que la session a déjà actionné. Dix jours après l'incident du 6 mai, le skill falsify-before-fix est commit. L'enseignement de l'échec devient un dispositif. C'est la seule des 14 règles exposée dans cet article, et les 13 autres sont dans le repo, toutes construites sur le même principe : matérialiser ce qui resterait pieux en textuel seul.

Le toolkit s'applique à lui-même, chiffres et rétractations

Six versions en 32 jours, chacune ancrée dans un fait nouveau documenté. v0.3 → v0.3.1 sur un premier relecteur externe (apparat théorique disproportionné, rétracté). v0.3.1 → v0.3.2 sur un second (sept recommandations, deux work-items ouverts). v0.3.3 instrumentation M1-M5 publiée. v0.4 séparation toolkit/manifesto sur un troisième. v0.4 → v0.4.1 sur un quatrième relecteur externe (Claude.ai web), un commit consolidé intégrant trois refactors plus la LOC mesurée.

LOC corrigé 118 808 lignes mesurées par find + wc -l sur TS/TSX/JS/JSX (exclusions explicites), contre 35 k cité dans les versions antérieures — la doctrine elle-même avait péché contre R2, Cache sans rafraîchisseur projeté sur sa propre description. M3 recalibrée ≤ 7 j → ≤ 30 j avec justification publique : la cible originale était une intuition non honorée par les 35,3 jours mesurés en pratique. M1 et M5 documentés comme échecs d'instrumentation, pas comme succès : M1 sur-sensible à 12,33 vs ≤ 1 cible, M5 classe 90 % des briefs en unknown.

Four external readers across six versions. The last two audited v0.3.3 then v0.4.1 — their objections are integrated in the release notes (manifesto §From v0.4 to v0.4.1). One reviewer called the falsify-before-fix skill "the best artifact of the doctrine among the ones I read". v0.5 prévue 15 juillet 2026.

Steal three things in 20 minutes

Trois règles à essayer avant d'installer le reste.

R4 *Falsify before fix* — empêche le cycle fix → rollback déclenché par la première hypothèse plausible mais fausse. Détaillée ci-dessus.

R6 *Live / Snapshot / Cache* — empêche qu'une valeur dérivée stockée diverge silencieusement de sa source. Toute colonne dérivable déclare sa catégorie dans le commit qui la crée, ou le commit est rejeté.

R10 *Silent failure forbidden* — empêche que catch {}, await sans destructuration { error }, 2>/dev/null et autres mécanismes d'avalement mentent à votre observabilité jusqu'à ce que la production craque sur une dépendance en aval.

Le repo : github.com/michelfaure/doctrine-counterpart. La commande d'install :

git clone https://github.com/michelfaure/doctrine-counterpart.git && \
  cd doctrine-counterpart && \
  ./install.sh --yes /path/to/your/project

Licence CC-BY-4.0. Le manifesto promet une citation nominative dans la v0.5 pour qui propose un retour exploitable — quelle règle manque pour votre stack ? Les commentaires DEV.to sont inputs directs pour la prochaine version. R14 *spike escape hatch* couvre le code prototype destiné à disparaître sous sept jours, exempté de R6/R7/R8 : l'adoption ne force pas la même friction au spike qu'au code de production.

Coda

Un agent qui ne vous contredit pas n'est pas un counterpart, c'est une dactylo plus rapide. Ces 14 règles restaurent le désaccord — matériellement, pas mentalement. Elles ne demandent pas à l'agent d'être moins sycophant, ni au solo d'être plus vigilant ; elles posent les dispositifs (skills invocables, hooks bloquants, sub-agent challenger) qui interrompent la course productive là où la complaisance se compose. Le toolkit est la prothèse qu'il reste au solo quand le PR review a disparu et qu'il refuse de coder à l'oreille. Si une seule des 14 vous évite un cycle fix-rollback la semaine prochaine, elle s'est déjà remboursée.

Counterpart Toolkit v0.4.1, fourteen operational rules in ~200 lines, six iterations in 32 days, four external reviews integrated. Tested on 60+ days of solo ERP (118 808 lines, 65+ ADRs). Licence CC-BY-4.0 : github.com/michelfaure/doctrine-counterpart

Make Claude Code disagree with you: a 14-rule counterpart toolkit (install in 1 command)

Michel Faure — Mon, 18 May 2026 10:18:33 +0000

The 60-day lesson, ROI on three axes

Thirty-two days of solo production on an ERP, 118,808 lines of TypeScript, six doctrine versions, four external reviewers integrated. I've compiled what I learned into fourteen operational rules, installable in one command: the Counterpart Toolkit v0.4.1. It is both the material lesson of sixty days coding solo with Claude Code, and the mapping of the fourteen silent failure modes I've seen repeat — for anyone coding alone with an AI in production, who no longer has a PR review to catch the drift.

ROI is quantified on three axes, measured on Rembrandt:

R4 *Falsify before fix* — five to ten minutes of upstream protocol prevent thirty to ninety minutes of fix-then-rollback cycle when the first plausible hypothesis turns out wrong. ROI 6 to 18× per incident. Over sixty days, I stopped losing an hour two to three times a week on fixes that fixed nothing.

R2 *Filesystem over summary* paired with R6 *Live/Snapshot/Cache* and the daily drift probes — median apparition→detection of a silent divergence drops from invisible to 35.3 days over a 90-day rolling window. M3 publicly recalibrated to ≤ 30 days in the manifesto, because the original target (≤ 7 days) was an intuition practice refused.

A sub-agent challenger producing objections in the imposed format Tool / Question / Refutation criterion. Material disagreement, not emotional "are you sure?" that pushes you to revise without a new fact.

Here's how, in 1400 words and one install command.

The diagnosis — the incident that triggered the doctrine

Coding alone with an AI means compounding two complaisances. The agent's, sycophantic by construction because reinforcement learning from human feedback trained it to please the prompter. And the solo's, self-validating by humanity, who validates their own work because no one is left to contest it. End to end, these two complaisances produce a drift that neither agent nor human flags — and that only surfaces at audit time, long after.

It was while preparing the late-April source-of-truth audit — ADR-0024, a deep-dive on divergences I had been putting off for three months — that I stumbled onto the gap, by chance, crossing two queries no one had ever crossed before. One student record, initials Y.B.: the contacts.montant_total column carried €1,159 entered by hand somewhere in 2024, untouched since. The actual sum of instalments, computed on the fly, came to €2,262. A thousand-euro gap, on a single record, with no alarm ever ringing. I widened the grep: five hundred and sixty contacts in the same state, some off by several thousand euros. And yet montant_total was read every day in the treasury dashboard — a derivable value being stored without a refresher, treated as an immutable past fact when it should have lived on the fly. This is exactly the trap R6 Live/Snapshot/Cache is meant to prevent, and R6 came out of that moment.

R4 Falsify before fix, the one rule exposed here

The toolkit states R4 as a five-step textual protocol. The falsify-before-fix skill is its invocable instance — the version Claude Code loads into its session, and cannot skip when about to write fix code.

name: falsify-before-fix
description: Activate this skill before writing the fix code on a bug or
  incident. Triggers on "fix", "bug", "patch", "hotfix", "workaround",
  "doesn't work", "diagnose", "hypothesis", "root cause". Enforces a
  single-sentence causal hypothesis and three material probes designed
  to refute it before any line of fix code is committed.
  Operational instance of R4 of the Counterpart Toolkit.

The protocol holds in five steps: (1) formulate the hypothesis in one sentence as a cause, not a symptom ("the counter reads from the old table after the 12 May migration" beats "the counter is wrong"); (2) list three probes designed to refute, not to confirm, because a confirmation probe always finds what it's looking for by selection; each probe carries its three fields Tool / Question / Refutation criterion; (3) execute and report raw output, never paraphrased; (4) branch — no probe refutes → write the fix; one probe refutes → restart with a new hypothesis; ambiguous probes → fourth sharper probe before any code; (5) output the retained hypothesis, the probes executed, the diff, and the post-fix observation criterion.

Why a skill and not the textual rule that already lived in CLAUDE.md? Because the textual rule didn't hold under pressure. 6 May, mid-afternoon. A Sentry alert reports the day's enrolment counter at zero while three enrolments were entered that morning. My reflex arrives before the protocol, and my hand is already on the keyboard — "the cache isn't invalidated." I commit, I deploy. Thirty minutes later, rollback: the bug is still there. The actual cause, that a ninety-second grep probe would have surfaced, is that no cache_invalidate call existed in the enrolment pipeline at all — not a stale cache, an absent one. R4 had been in CLAUDE.md for three weeks. I simply didn't follow it that day, because no apparatus interrupted my course between bug and commit.

That's the difference that makes everything. A textual rule in CLAUDE.md, the agent reads it at session start, and nothing forces it to summon the rule at the exact moment it would need it. A skill is something else: a material mechanism that loads automatically on keywords ("fix", "bug", "doesn't work") and imposes its protocol on the active session — not a self-reminder, a switch the session has already flipped for you. Ten days after the 6 May incident, the falsify-before-fix skill was committed. The lesson of the failure becomes an apparatus. It is the one rule of the 14 exposed in this article, and the other 13 are in the repo, all built on the same principle: materialise what would remain pious in text alone.

The toolkit applied to itself — figures and retractions

Six versions in 32 days, each anchored in a documented new fact. v0.3 → v0.3.1 on a first external reviewer (disproportionate theoretical apparatus, retracted). v0.3.1 → v0.3.2 on a second (seven recommendations, two open work-items). v0.3.3 — M1–M5 instrumentation published. v0.4 — toolkit/manifesto separation on a third reviewer. v0.4 → v0.4.1 on a fourth external reviewer (Claude.ai web), a consolidated commit integrating three refactors plus the measured LOC.

LOC corrected to 118,808 lines measured by find + wc -l on TS/TSX/JS/JSX (explicit exclusions), against the 35k figure cited in earlier versions — the doctrine itself had sinned against R2, Cache without refresher projected onto its own description. M3 recalibrated ≤ 7 d → ≤ 30 d with public justification: the original target was an intuition unhonoured by the 35.3 days measured in practice. M1 and M5 documented as instrumentation failures, not as successes: M1 over-sensitive at 12.33 vs ≤ 1 target, M5 classifies 90% of briefs as unknown.

Steal three things in 20 minutes

Three rules to try before installing the rest.

R4 *Falsify before fix* — prevents the fix → rollback cycle triggered by the first plausible but wrong hypothesis. Detailed above.

R6 *Live / Snapshot / Cache* — prevents a stored derived value from silently diverging from its source. Any derivable column declares its category in the commit that creates it, or the commit is rejected.

R10 *Silent failure forbidden* — prevents catch {}, await without { error } destructuring, 2>/dev/null and other swallowing mechanisms from lying to your observability until production cracks on a downstream dependency.

The repo: github.com/michelfaure/doctrine-counterpart. The install command:

git clone https://github.com/michelfaure/doctrine-counterpart.git && \
  cd doctrine-counterpart && \
  ./install.sh --yes /path/to/your/project

License CC-BY-4.0. The manifesto promises nominal citation in v0.5 for anyone who proposes actionable feedback — which rule is missing for your stack? DEV.to comments are direct inputs for the next version. R14 *spike escape hatch* covers prototype code meant to disappear within seven days, exempt from R6/R7/R8: adoption does not impose the same friction on a spike as on production code.

Coda

An agent that doesn't disagree with you isn't a counterpart — it's a faster typist. These 14 rules restore the disagreement — materially, not mentally. They don't ask the agent to be less sycophantic, nor the solo to be more vigilant; they install the apparatus (invocable skills, blocking hooks, sub-agent challenger) that interrupts the productive course where complaisance compounds. The toolkit is the prosthesis the solo has left when PR review has disappeared and they refuse to code by ear. If a single one of the 14 spares you a fix-rollback cycle next week, it has already paid for itself.

Counterpart Toolkit v0.4.1, fourteen operational rules in ~200 lines, six iterations in 32 days, four external reviews integrated. Tested on 60+ days of solo ERP (118,808 lines, 65+ ADRs). License CC-BY-4.0: github.com/michelfaure/doctrine-counterpart

La règle du jour-jeté-à-la-poubelle : lis le code avant de laisser ton IA en écrire

Michel Faure — Sun, 17 May 2026 08:33:16 +0000

Six heures du matin, devant la sortie

Vingt-neuf avril, six heures du matin. Le rendu sort à l'écran. A A A A A sur toute la matrice du document, illisible par construction. Je demande à mon agent pourquoi la sortie est incohérente. Il relit le code, descend dans le dossier voisin, et trouve un composant existant dont je n'avais jamais demandé l'inventaire. Le composant rend proprement le format attendu — signatures, en-tête, légende, bloc d'identification. Ce que mon agent venait de coder la veille était un doublon partiel d'un fichier qu'aucun de nous deux n'avait ouvert.

Le format que mon agent venait d'inventer la veille existait déjà dans le repo. Mieux fait. Dans un fichier nommable, qu'aucun de nous deux n'avait lu avant d'écrire.

Pourquoi un agent invente à côté de l'existant

Le fond du problème n'est pas l'agent. C'est moi. Quand je lance un chantier sur un domaine déjà couvert par du code, je décris la cible et je laisse l'agent générer. Lui n'a pas idée du voisinage du fichier qu'il va créer, parce que je ne lui ai pas demandé de le cartographier. Il code une solution plausible à un problème mal cadré, et la plausibilité du résultat masque la duplication tant que personne n'ouvre les autres fichiers du même dossier.

L'absence de Phase 0 grep n'est pas un défaut de l'agent. C'est un défaut du pilote qui a sauté l'étape la moins coûteuse de toute la chaîne.

Phase 0 — deux minutes, un fichier

# Phase 0 — avant tout nouveau composant dans un domaine existant
DOMAIN="invoices"   # le mot-clé du chantier

find app/api/$DOMAIN/ lib/$DOMAIN/ \
  -type f \( -name "*.ts" -o -name "*.tsx" \) | head -20

# Si un pattern attendu est nommable, vérifier qu'il n'existe pas déjà
grep -rl "ExistingPattern\|RenderPdf\|exportPdf" app/ lib/

Deux minutes, à tout casser. Le résultat tient sur un écran. Si un composant existant traite le besoin, on le lit avant de proposer quoi que ce soit de neuf. Si rien n'existe, on a la preuve d'avoir cherché.

Le coût mesuré du shortcut est un jour-dev. Le composant qu'il aurait fallu lire tenait dans un seul fichier au nom évocateur, dans le dossier juste à côté. Deux minutes de find auraient suffi. Le jour reverted, c'est ce que coûte la confiance dans la plausibilité d'un brouillon que personne n'a relié à son voisinage.

Le signal métacognitif

Quand l'agent a relu son propre travail à la lumière du composant existant, il a proposé de reverter, pas de défendre. C'est un bon signal, et un agent qui s'enferme dans son design inventé serait beaucoup plus coûteux qu'un agent qui reconnaît avoir loupé du code. Mais le bon signal vient trop tard. La règle est de ne pas en arriver là.

La règle

Avant tout nouveau format, template ou composant dans un domaine déjà couvert, Phase 0 grep, lecture du voisinage, verbalisation de l'existant. Sinon, le jour suivant, tu reverts.

Script Phase 0 grep et checklist en 5 questions, pseudonymisés :
github.com/michelfaure/rembrandt-samples/tree/main/one-day-thrown-away-rule

The 1-day-thrown-away rule: read the code before letting your AI write new code

Michel Faure — Sun, 17 May 2026 08:33:14 +0000

Six in the morning, looking at the output

April twenty-ninth, six in the morning. The rendering hits the screen. A A A A A across the entire document matrix, unreadable by construction. I ask my agent why the output is incoherent. It re-reads the code, drops into the neighboring directory, and finds an existing component I had never asked it to inventory. The component renders the expected format cleanly — signatures, header, legend, identification block. What my agent had coded the day before was a partial duplicate of a file neither of us had ever opened.

The format my agent had invented the night before already existed in the repo. Better done. In a nameable file, that neither of us had read before writing.

Why an agent invents next to the existing code

The root of the problem isn't the agent. It's me. When I open a project on a domain already covered by code, I describe the target and let the agent generate. It has no idea what the neighborhood of the file it's about to create looks like, because I never asked it to map it. It codes a plausible solution to a poorly framed problem, and the plausibility of the result hides the duplication as long as nobody opens the other files in the same directory.

The absence of a Phase 0 grep is not a flaw of the agent. It's a flaw of the pilot who skipped the least expensive step in the whole chain.

Phase 0 — two minutes, one file

# Phase 0 — before any new component in an existing domain
DOMAIN="invoices"   # the keyword of the project

find app/api/$DOMAIN/ lib/$DOMAIN/ \
  -type f \( -name "*.ts" -o -name "*.tsx" \) | head -20

# If an expected pattern is nameable, check that it doesn't already exist
grep -rl "ExistingPattern\|RenderPdf\|exportPdf" app/ lib/

Two minutes, tops. The output fits on a screen. If an existing component handles the need, read it before proposing anything new. If nothing exists, you have proof you looked.

The measured cost of the shortcut is one dev-day. The component that should have been read fit in a single file with a telling name, in the directory right next door. Two minutes of find would have sufficed. The reverted day is what blind trust in the plausibility of a draft nobody connected to its neighborhood actually costs.

The metacognitive signal

When the agent re-read its own work in light of the existing component, it proposed to revert, not defend. That's a good signal — an agent that locks itself into its invented design would be far costlier than one that admits it missed existing code. But the good signal comes too late. The rule is to not get there in the first place.

The rule

Before any new format, template, or component in a domain already covered, Phase 0 grep, neighborhood read, verbalization of the existing. Otherwise, the next day, you revert.

Phase 0 grep checklist and audit script, pseudonymized:
github.com/michelfaure/rembrandt-samples/tree/main/one-day-thrown-away-rule

Forem: Michel Faure

Deux IA d'accord = une source : la règle qui m'a évité un pipeline bâti sur du vide

Une nuit, deux audits, une même note

Pourquoi deux IA convergentes ne sont pas deux mesures

Trois sondes en trois jours

La règle canonique, Am.R12 du Counterpart Toolkit v0.7

Coda

Two AI reviews agreeing is not two reviews: how I learned to test claims before adopting them

One night, two audits, one identical score

Why two converging AIs are not two measurements

Three probes in three days

The canonical rule — Am.R12 of the Counterpart Toolkit v0.7

Coda

Three weeks after I said CLAUDE.md writes itself, it added 4 more rules without me

A thesis, three weeks later

The audit, measured by git

The rule that couldn't have been written before

Four observations about sedimentation

Why it works now

Coda

Trois semaines après avoir dit que mon CLAUDE.md s'écrivait tout seul, il a ajouté 4 règles sans moi

Une thèse, trois semaines plus tard

Le bilan, mesuré par git

La règle qui n'aurait pas pu être écrite avant

Quatre constats sur la sédimentation

Pourquoi ça marche maintenant

Coda

Pourquoi « build vert » sans la sortie brute n'a aucune valeur de preuve

Quatre faux positifs en deux heures

Le glissement épistémique

Cinq formes de la même évasion

La règle, codée dans le CLAUDE.md racine

Durcir avec un script

Ce que tu peux copier dans ton projet

Ce qu'on ne croit plus

Why 'green build' without the raw output has zero evidentiary value

Four false positives in two hours

The epistemic slip

Five forms of the same evasion

The rule, codified in the root CLAUDE.md

Hardening with a script

What you can copy into your project

What you stop believing

Pourquoi ta requête Supabase s'arrête à exactement 1000 lignes (et ne te le dit jamais)

La nuit où un dropdown m'a menti

Le mécanisme

La règle ESLint qui ferme la porte

L'ampleur réelle

La règle

Why your Supabase query stops at exactly 1000 rows (and never tells you)

The night a dropdown lied to me

The mechanism

The ESLint rule that closes the door

The real scale

The rule

Forcez Claude Code à vous contredire : 14 règles, install en 1 commande

L'enseignement de 60 jours, le ROI en trois axes

Le diagnostic — l'incident qui a déclenché la doctrine

R4 Falsify before fix, la seule règle exposée ici

Le toolkit s'applique à lui-même, chiffres et rétractations

Steal three things in 20 minutes

Coda

Make Claude Code disagree with you: a 14-rule counterpart toolkit (install in 1 command)

The 60-day lesson, ROI on three axes

The diagnosis — the incident that triggered the doctrine

R4 Falsify before fix, the one rule exposed here

The toolkit applied to itself — figures and retractions

Steal three things in 20 minutes

Coda

La règle du jour-jeté-à-la-poubelle : lis le code avant de laisser ton IA en écrire

Six heures du matin, devant la sortie

Pourquoi un agent invente à côté de l'existant

Phase 0 — deux minutes, un fichier

Le signal métacognitif

La règle

The 1-day-thrown-away rule: read the code before letting your AI write new code

Six in the morning, looking at the output

Why an agent invents next to the existing code

Phase 0 — two minutes, one file

The metacognitive signal

La règle, codée dans le `CLAUDE.md` racine

The rule, codified in the root `CLAUDE.md`