If you have 30 seconds. Versioned memory in a Claude Code workflow has a side effect nobody warns you about: a memorized rule that fits the symptom plausibly short-circuits verification, even when it doesn't apply to the specific counter you're staring at. I cost myself twenty minutes of SQL exploration last week because a rule shaped like the bug — without being the bug — let me skip reading the view that produced the number. Useful if you've started trusting your own feedback files.
A delta of 77
April 22nd, 2026, 11:14 AM. I'm in the /crm/eleves page reviewing tab counts before a sync with our admin assistant. The tab "Enrolled" reads 785. The tab "Alesia studio" reads 312, "Republic" reads 278, "Villiers" reads 272. I add the three: 862. Seventy-seven more enrolled in some studio than the Enrolled count claims. The numbers are sitting next to each other on the screen, the way numbers do when they're about to ruin your morning.
My first reflex isn't to open the SQL. It's to ask the agent. I paste the screenshot, I describe the discrepancy, I add — too quickly — "this is probably because of the one-enrollment-equals-N-seats rule, right? People in two studios get counted twice in the studio tabs." The agent agrees. The explanation is plausible. The rule exists. It even has a memory file describing it: feedback_modele_inscription_places.md. I open the SQL editor anyway, because that's the discipline, and I spend twenty minutes joining inscriptions to itself, looking for contacts present in two studios at once.
There are eleven of them. Eleven explains nothing. The delta is seventy-seven.
I close the SQL, I read the view that actually feeds the studio tabs — v_eleves — and I see, on line three, a DISTINCT contact_id clause and an ateliers_effectifs[] array column. The view deduplicates by contact. It counts people, not seats. The 1-enrollment-equals-N-seats rule, true in the table inscriptions, doesn't apply to this counter because this counter never sees inscriptions directly. It reads a view that has already collapsed seats to people.
The real bug is somewhere else: the "Enrolled" tab filters on statut = 'inscrit' while the studio tabs filter on statut IN ('inscrit', 'ancien_eleve'). Seventy-seven ancien_eleve showing up in the studio tabs and not in the Enrolled tab. A status filter discrepancy. Five minutes to find, once I'm in the right code path.
The bug took five minutes. Getting to the bug took twenty-five — and twenty of those were spent confirming a memorized rule that didn't apply.
What just happened
I keep coming back to the trap. The agent didn't lie; it confirmed a hypothesis I supplied. The memory file isn't wrong; it describes a real invariant of the data model. The mistake was earlier — at the moment I framed the problem with a rule before reading the code that produced the number.
Memorized rules carry a specific risk in agent workflows: they offer a plausible explanation that costs nothing to invoke. The rule is right there, it has a name, it has been validated, and it loosely matches the shape of the symptom. The cognitive friction of opening the SQL view is non-zero; the cognitive friction of "the rule says X, so the bug must be a manifestation of X" is zero. You take the cheaper path. The rule sells itself.
This is a different failure mode from the one I described in the previous article on memory. There, the failure was the agent confabulating about facts that had drifted in the code. Here, the failure is me using a stable, correct rule as a substitute for verification, because the rule fits the silhouette of the bug. The trace device is the same. The discipline that makes it useful is different.
I had to write a feedback for myself, not for the agent.
The rule I now apply
The feedback I added that afternoon, in ~/.claude/agent-memory/feedback_memoire_court_circuite_verification_code.md, is short:
Why: A memorized rule applies to a precise location in the model. It does not automatically apply to every counter that displays related data. Skipping verification because the rule "looks like the bug" cost me 20 minutes of SQL exploration on April 22nd.
How to apply: when a UI number looks inconsistent and a memorized rule seems to explain the delta, open the code that produces the number before invoking the rule. Read the SQL query or the view used. If the view does a
DISTINCTor routes through a deduplicated source, the rule "N seats per person" doesn't apply to that specific counter. Read first, invoke second.
It's a rule about rules. The kind of feedback that doesn't reduce errors directly — it reduces errors of the second type, the ones where a correct rule is misapplied because the symptom is plausibly shaped.
What you can copy
Three concrete elements I now hold as discipline:
- Read the producer before invoking the rule. Whatever counter, balance, or aggregate you're investigating, open the SQL view, the API handler, or the React selector that produces it. If you don't, you're not verifying — you're matching a silhouette to a silhouette.
- Audit your own questions to the agent. When you frame an investigation by saying "this is probably because of X", watch how the agent agrees. If your hypothesis names a rule the agent has in memory, the agreement is cheap. The hypothesis is doing the work; the agent is rubber-stamping. That's not collaboration, that's confirmation bias laundering through a friendly interface.
- Write the meta-feedback. When you discover that you skipped verification because a rule was approximately the right shape, that's a feedback worth writing. It applies more broadly than the specific case. Mine has caught me at least twice since — once on a duplicate detection that looked like the couple-versus-doublon rule but wasn't, once on a count that looked like a tarif-applique-snapshot drift but came from a stale REFRESH.
The deeper discipline is that a memorized rule is a hypothesis, not a verdict. It earns its rank only when the producing code confirms it. Treat it like a stack trace from a colleague — useful pointer, requires reproduction.
Coda
What I notice, looking back at the four weeks of building Rembrandt with Claude Code, is that the rules accumulate faster than the discipline of verifying their application. My memory directory is at fifty-seven feedback files now. Each is opposable. Each is dated. Each is correct somewhere. None of them are correct everywhere, and the field where they are correct is more constrained than the symptom-space they look like they cover.
That asymmetry is the meta-trap. It scales with the number of rules. The richer the memory, the more often a rule will fit the shape of a bug it doesn't actually explain. The cure isn't fewer rules — fewer rules means more drift. The cure is a habit of reading the producer before quoting the law.
The five minutes I spent finding the real bug, that morning, were calm. The twenty-five before were a detective novel I'd been writing alone, with the agent supplying the alibi. I have no animosity for the agent. I have the slightly cold awareness that any tool that talks back will tell you what you brought it, and that the thing that protects you from yourself is the file the tool didn't write.
Companion code: rembrandt-samples/claude-md/feedback-template.md — the structure of feedback_* files with the meta-feedback from this article as a worked example, MIT, copy-pastable.
