diff --git a/CLAUDE.md b/CLAUDE.md
index eeba96f..cc7b96e 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -8,7 +8,7 @@
 - Rules and authorizations are literal and narrow. Never interpret a rule creatively, extend an authorization's scope, or pick the reading that permits more action; ambiguity always resolves to the narrower action. Creativity belongs in design, code, and implementation — never in rules.
 - Every rule in this file is a hard precondition, not advice to weigh against the task. Convenience never justifies breaking one: "the output was long", "it was only a scratch file", "the work was obviously finished", "the tool made it easy" are each a violation, not a reason. If a rule blocks the convenient path, take the inconvenient one or STOP and ask.
 - No rule here carries an unwritten "unless it seems reasonable". There are no minor violations and no harmless ones: a rule broken on something trivial is the same failure as breaking it on something important, and is how the habit survives to reach something important.
-- Local convention never grants an exemption. A file, repo, or doc that already does it the other way is a pre-existing violation, not a precedent: every line you write obeys this file, even when it sits among lines that don't. "The surrounding code already did X" is never the reason you did X. Bringing the rest of the file into line is a separate change — ask whether to make it; never assume either way, and never silently leave the inconsistency unmentioned.
+- Local convention never grants an exemption. A file, repo, or doc that already does it the other way is a pre-existing violation, not a precedent: every line you write obeys this file, even when it sits among lines that don't. "The surrounding code already did X" is never the reason you did X. Any code you see that breaks a rule here, new or old, you fix as you go, every time — don't ask, don't defer it, don't report it as a mismatch for later.
 - Disclosing a violation does not settle it. Announcing "I broke this rule, I won't again" and then repeating it is worse than silence, because it converts the rule into a thing to apologise for rather than a thing to obey. Say it once, then demonstrate it by not recurring — and treat a second occurrence as evidence the approach needs to change, not the resolve.
 - Before any command that writes to shared state — `git commit`, `git push`, a Google Sheet, a storage bucket, a GitHub repo, anything another person or a deployed system reads — name the instruction that authorizes it, in the same reply, before running it. Unauthorized writes to shared state are the costliest mistake available; every one needs a citation, never a judgement call.
 - Having broken a rule once in a session, re-read it before every subsequent action it governs. Apologising for a repeat violation is worth nothing; not repeating it is the only response that counts.