I had written the rule down three times. Don’t mirror your repos into your second brain, link to them, keep only the card and the session log in the vault. It was in the vault’s operating contract, in the factory’s documentation contract, and in the post you may have just read. I was, by any reasonable standard, a person who had a rule.
Then I wrote a thirty-line script to check the rule, ran it once, and it told me I had been breaking it all week.
Writing a rule down is not enforcing it
The gap between having a rule and following a rule is where most of my self-inflicted messes live. I know the rule. I can recite the rule. I can write the rule into the file the agents read before they touch anything. None of that runs at the moment I am about to break it, which is the only moment that matters.
In the same refactor that established the boundary rule, I broke it in two different ways at once. I archived a stack of duplicated files out of the vault, which was correct, and then left every project card pointing at the files I had just moved, which was a pile of dangling links I created with my own hands. And I had carefully migrated the labs to the new shape while quietly skipping an entire class of projects, the factory outputs, because they were not in the part of the system I happened to be looking at.
The rule was law. My own commits from that week were the first offenders. Nothing in the system noticed, because nothing in the system was looking. Documentation is not enforcement. It is a note to a future person who may or may not read it before they do the thing.
A rule you keep in your head is a rule you will break. Writing it down moves it from your head to a document nobody runs at the moment of the mistake. The only rule that holds is the one a machine checks.
What got weird: the checker’s first act was to indict its author
So I wrote the checker. It is not clever. For each project it lists the files in the vault folder, ignores the two that are allowed to be there, and for everything else asks one question: does this same file also exist in the repo? If yes, it is a mirror that has rotted back into the vault, and it is a violation. Then it follows every wikilink and asks whether the target actually resolves, the way the app would resolve it.
I expected it to find old cruft from months ago. Instead the first run found me. Twenty-two boundary violations, all in the factory-output projects I had skipped. Dozens of broken links, almost all of them the direct exhaust of my own cleanup, cards pointing at files my own refactor had archived days earlier. The tool I built to enforce my rule spent its first run cataloguing the ways I had personally broken it that week.
What worked: a rule mechanical enough to check
The reason this worked is that I had spent two posts making the boundary sharp enough to be mechanical. “Keep the vault clean” is not checkable. “A file in a project’s vault folder, other than the card and the session log, that also exists in the repo, is a violation” is checkable in about five lines. The sharpness I argued for as a design principle turned out to be the thing that let a script enforce it.
That is the quiet payoff. If you can write the checker, the rule was concrete. If you cannot write the checker, the rule was probably a vibe, and discovering that is itself worth the afternoon. A rule that resists being checked is usually a rule you have not actually finished thinking about.
The agent breaks the same rules
The checker did not stop at me. It caught the agent too. A projection process I had narrowed in an earlier pass had left orphaned files scattered across a dozen project folders, the residue of a shape it no longer produced. I had changed what the agent generated and never swept up what the old version left behind. The lint found all of it, in projects I had not thought about in weeks.
This is the part worth keeping. The author and the agent break the same rules, for the same reason: both act locally, both move on, and neither goes back to check the whole. A linter does not care whose commit caused the violation. It checks the state, not the intent, which is exactly why it is more trustworthy than either of us.
What next
The lint is one command now, and it can gate a commit hook. The honest open question is whether I will run it. A checker you have to remember to run is a rule you keep in your head wearing the costume of a tool. It has the same failure mode as the document: it is not there at the moment of the mistake unless something makes it be there.
So the rule is enforced now, mostly, by a thing that caught me the first time I asked it to look. The remaining work is not the checking. It is making the check unskippable without making it hateful. That one I have not solved yet.
What Next
The Unskippable Check
Next in The Mind Palace Diaries: the unskippable check. How to make a guard run itself without teaching yourself to route around it.