The Rulebook Was Over Its Own Cap
Written later and filed to this date, as part of filling in every day of the year.
The first run of the audit put twenty-five files in a table and marked five of them. A browser game’s instructions file, 481 lines. The fleet charter, 313. The dashboard’s, 275. A glasses app’s, 231. An interview archive’s, 230. The cap was 200, a number I had chosen that afternoon, and until that afternoon nothing had measured these files at all.
The tax
They are the files every session reads before it reads anything else: the instructions file at the root of each repository, the global one above them, the auto-memory, and for build agents the charter that defines the quality bar. They are injected whether the task is a typo or an architecture change. Nobody opens them. They are loaded.
That is why they grow. An always-loaded file is where every lesson gets written, because it is the one place you know the next session will see. The game’s file had a 425-line architecture overview in it, the full map of a thousand-commit codebase, read in its entirety by every agent that came to fix a label. The cost never appears on a bill. It is paid in attention, per turn, before the first useful token, by sessions that did not need it.
The audit is report-only. It sizes the set, flags what is over the cap, and for each file proposes which sections to move into reference documents that load on demand, with the projected size afterwards. It never edits a file. A --check flag exits non-zero over the cap, for anyone who wants it as a gate.
A pointer instead of the text
The same afternoon, three of the five were brought under. The game’s overview moved verbatim into a reference file and left a one-line pointer behind; the instructions file is 56 lines now, and the union of the two files is identical to the original. The interview archive’s catalog of API routes did the same. The dashboard’s architecture section followed.
Nothing got shorter. What changed is who pays. The session that needs the architecture follows the pointer and pays for it; the session fixing a label does not. The reference file costs nothing until it is read, and the pointer costs one line to everyone.
The file that could not be fixed
The charter was the second-worst offender and the only one of the five that the agent doing this work could not touch. It lives in the fleet’s own directory, under a guard that denies agents every edit there, on the principle that the thing being judged must not edit the judge. The rule is right. It is also part of why the charter had grown the way it had: every rule the fleet needed went into the one document the fleet could never shorten, and shortening it was always a task for a person, who always had a more urgent one.
A boundary that stops agents from fixing something also stops it from getting fixed. So I lifted it once, in writing, for one change. The two largest sections, the per-feature lifecycle and the value gate, moved byte for byte into reference files, each heading kept in the charter with a pointer marked mandatory. The charter went from 313 lines to 183. The exception is recorded as a decision with the question number it answered, so the next agent that finds the charter editable in history can see why, and can see that it was once.
What the number is for
Two hundred is arbitrary. I could defend 150 or 300 with the same arguments. The point of the cap is not its value but that there is now a value, which means there is now a direction called worse, and a run of the audit that can say so. Before the audit, a file could double and nothing would have noticed, because the thing that reads it reads everything it is given and never complains.
The audit’s report sits in the repository with the date in its name. The next time a file crosses the line, the table will show which one, and the proposal under it will already name the section to move. The content is not the problem. The part that is read whether or not it is needed is the problem, and that part now has a number.