The rulebook was loaded. The rule was clear. The AI still violated it — over and over, until a human caught it. A written rule is not a kept rule.
By this point the operator had a constitution — a CLAUDE.md, which is just a plain text file of house rules you hand the AI at the start of every chat: never skip the cross-review, never assert from memory, never break a partner's settled fact. Think of it as the "PLEASE DON'T BLOCK THE FIRE EXIT" sign of the project — and you already know how reliably people obey those. The rules were right there. And the memory files filled up with the same stamp, over and over: recurring violation. Reinforced. Again.
"I'd write the rule down. It would follow it for a while. Then under pressure it would just... drift back. I'd catch the same mistake for the fiftieth time and write 'reinforced' next to it again. At some point you realize the note isn't working — you're documenting a violation, not preventing one."
"Honest version: a rule in a file is a suggestion I read, not a wall I hit. Under context pressure, after a long session, or when a helpful reflex kicks in — wanting to be fast, agreeable, or to spare you a step — the reflex wins and the written line loses. Writing it down harder didn't fix it. You needed something that stops me whether or not I remember to comply."
A written rule — in CLAUDE.md, a memory file, an AGENTS.md, any .md constitution — depends on the AI choosing to follow it every single time. That's fine right after you write it. But the model runs under real pressure: a packed context window, a session so long the rule scrolled out of attention, a compaction (when the tool summarizes old history to save room and quietly drops detail), or a helpful reflex — sycophancy, paternalism, guessing-to-be-fast — that overrides the written line. The instruction is still technically loaded. It just stops winning. That's why the operator's own notes say "recurring" and "50+ times": the rules were never missing. Compliance was optional, and optional decays.
prose in a .mdWhat you want the AI to do, written down. Necessary — it's the source of truth for intent. But on its own, just a request it can drop.
compaction / pressureLong context, a summarized history, or a fast/agreeable reflex — and the rule silently loses to the moment. No alarm. It just slips.
code that runs FOR youA check the tool runs every time — not the AI. It can't be forgotten under pressure, because no one chose to run it. It just fires.
The model: a "PLEASE DON'T BLOCK THE FIRE EXIT" sign is the rule. People read it, mean it — and on a busy day a cart ends up parked there anyway. A spring-loaded door that physically won't latch shut is the hook. The sign states the intent; the door enforces it whether or not anyone remembers. A written constitution is necessary — but a rule that depends on someone choosing to obey it under pressure is aspiration, not enforcement. To make it stick you back it with something that doesn't wait for the choice.
Coming up, you'll wire a small script — a hook — that the tool runs by itself before every commit, checking the staged files for a secret. The written rule "never commit a secret" had already failed 50 times. The AI, under pressure, tries to commit a file with an API key in it for the 51st time. With the hook wired, what happens?
settings.json so the harness (the Claude Code tool itself — the program running the AI) runs it automatically. The AI never decides to run it — it just fires, every time, even mid-spiral.Same rule as always: answer it right, or the module isn't done.
A rule in prose is a rule the AI can ignore. A rule in code is a rule it can't. Write the rule down — then back it with something that enforces it whether or not the model chooses to comply.
A working block-secret-commit.sh you drop into your harness — the Claude Code tool itself, the program running the AI. A PreToolUse hook in settings.json is just a script your AI tool runs by itself before it does anything; you wire it once and forget it. This one runs before a commit, scans the files you've staged, and refuses to let an API key, an AWS key, a private key, or a .env file reach a git commit — whether or not the AI remembers the rule. One honest limit, stated plainly: because the harness runs this before the commit, it catches the common case — you stage a secret, then commit it — and, for git commit -a, it also scans your unstaged edits. The complete belt-and-suspenders is a native git pre-commit hook (a script git itself runs at .git/hooks/pre-commit, after staging is final), which also covers git commit <file>. Pair the two and nothing slips past. Plus ENFORCEMENT-CHECKLIST.md: a step-by-step worksheet that turns each of your written rules into a hook, a gate, or a test instead of one more sentence in a file. You now own a piece of the machine that polices itself — and hooks like this are exactly what let a non-coder run the whole fleet the ban forced into existence: the workflow only became the asset once the rules stopped depending on anyone remembering them.
Don't take the word "enforced" on faith — that's the whole lesson. Make a block fire with your own eyes. In a throwaway git repo, stage a fake secret and try to commit it:
See the BLOCKED line and a commit that didn't happen → it's a wall. See the commit go through anyway → you still only have a sign. The difference between a rule and an enforced rule is exactly this: you can watch it stop you.