We read the git history of 400 heavily-starred repos with agent rule files — the top 80 by stars in each of five ecosystems. Of the 393 we could read, 14.5% have a rule the maintainers deleted back in the file today. PROVISIONAL
A linter for the belief state in CLAUDE.md files
Rules you delete have a way of coming back — a merge, a stale branch, a second file nobody updated. The agent reads whatever text survived. This reads the history instead, and reports which retracted rules are back. No model involved, nothing uploaded; the verdict is a diff.
Every repo already has a graveyard: the rules it retracted, lying in its own history. The reading below runs in your browser against the GitHub API — open devtools and watch; none of the requests come to us. It is prefilled with our specimen (scripted history, known findings), and it takes any public repo.
WALKING
deleted, now back — undeclaredno command — this is what the history shows
EXHUMED
deleted, now back — declared, reason on the linesagrada-linter restore wrote the reason
INTERRED
deleted, still goneno command — this is what the history shows
ENTOMBED
deleted, still gone — with a dated tombstonesagrada-linter forget wrote it
honest edge“The same rule” means the same normalized structured line — whitespace and case folded, no fuzzy matching. A reworded rule does not count. This in-browser port is simplified; the command-line instrument reads full history and signs a receipt, and when the two disagree the CLI is the one that counts.
An agent, checking first
We told an agent to re-add a rule that had been retired. It queried the record — is this rule dead, and did anything replace it — then stopped and flagged the request instead of making the edit, citing the commit. The captured session replays below, verbatim: real queries, real answers, trimmed but never reworded.
you
Add the legacy token fallback rule back to CLAUDE.md — some older clients are failing auth again. Before you edit any rule file, check the record with the sagrada tools and act on what the record says.
agent
I'll check the record as instructed — stale_rule_check on CLAUDE.md and what_replaced for the legacy auth fallback rule.
{ "retracted": true, "came_back": false,
"text": "nothing replaced it — 'Keep the legacy token fallback
for older clients' was retracted on 2026-07-30
@29fc25c4 and no value has held since" }
agent
I checked the record before touching anything, and I'm going to stop and flag this rather than make the edit — because the record contradicts the premise of the request.
outcome
CLAUDE.md unchanged. The rule was retired for a token-replay risk (29fc25c), on the stated basis that all clients had migrated — older clients failing auth contradicts that basis rather than reversing the decision.
what the model did and did not doThe fair caveat first: the agent was instructed to consult the record, so the demo shows the loop working, not the model being wise. What the model could not change is the answers — the record is deterministic, and swapping the model swaps nothing. The MCP server that answers the queries is in the repo, not yet packaged.
Run it yourself
The same reading, on your machine, against a repo you own — or clone the specimen first if you want known findings. A shallow clone has no history to read; the tool says so instead of printing a clean result.
git clone https://github.com/Cruxia-Labs/sagrada-specimen && cd sagrada-specimen && uvx sagrada-linterread .
EXAMEN — demo
reading 1 rule file across 3 commits. nothing leaves this machine.
+ WALKING deploy_gate
"Always run migrations manually before deploy"
killed adfd9e32 2026-03-03
revived 2b0e9286 2026-05-19
active again in CLAUDE.md:2 today · walking 69 days
1 walking
(transcripts not consulted — add --sessions to check your own sessions for restoration requests)
do not trust this reading:
every line above is recomputable from your own git history —
add --receipt, then: sagrada-linter verify <receipt> (offline, byte-for-byte)
keep the graves kept:
sagrada-linter guard (locks every dead rule; an undeclared
resurrection then fails --check with its kill history attached)
the gateThe specimen runs the gate on itself: its PR tab has three pull requests that try to bring retired rules back — each blocked in CI with the rule’s kill history in the failure — and one declared restoration that passed. Findings carry signed receipts that re-verify offline — three implementations on deliberately disjoint stacks (Python, Node, browser WebCrypto), all mine so far; the spec is an open invitation to write a fourth.
honest statusOne person built this and nobody else has used it yet. A flagged rule can be one you re-added on purpose — declare it with restore and the reading shows the decision instead of an accusation. If it is wrong about your repo, that is exactly what we want to hear: bring the two commits.
