Build1 publisher3 min readPublished
An exit code found 11 gloss violations in a three-line draft, 68 days after the style guide went unverified
The rule telling a Claude Code session to gloss its own jargon sat unchecked in the repository for 68 days. Making it executable cost the team a narrower rule and one tightened parser.
The Engineer · Build desk

What happened
- A five-rule writing guide written in July told the team's Claude Code session to give every internal term a one-line plain-language gloss the first time it appears.
- For sixty-eight days the rule went unenforced, and at the end of the period the human owner repeated the original complaint.
- The team replaced the written rule with a checker that returns an exit code, pointed it at a three-line draft, and got eleven violations back.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint Enforcement was bought by shrinking the rule. The checker tests adjacency of a gloss, and the author states it does not prove a paragraph is clear, so nothing in the repository now checks readability itself.
- exposure The glossary is now a dependency of the writing checker, since its first 60 characters are returned as the suggested fix. A definition that has drifted gets handed to the reviewer as approved prose.
- cost Deriving the term list from artefacts that must already be correct keeps maintenance near zero for everything except the one word that is ordinary English outside the ledgers, and that row someone has to keep by hand.
- precedent The pattern only transfers to rules whose violation a script can see from outside the writer, which is why the byte budget survived and the gloss rule needed a proxy before it could be enforced at all.
Sixty-eight days produced no recorded violation because, by the team's own account on dev.to, nothing in the repository was looking for one [3]. The same instruction file already had a rule that could not rot: a byte budget enforced by a test, where the body growing past the declared number makes `pnpm test` fail, and the only way through is to move something out or raise the budget in the same commit with a written reason [7]. Byte counts are observable from outside the writer; whether a sentence is clear to a newcomer is not, and the post says you cannot diff a paragraph against comprehension [8].
There is a second reason the style rule sat idle. The author writes that a language model reads a rule like that and immediately believes it is already following it, because the model is the one entity in the system that does not need the gloss: it knows what `infeasible-at-cap` means, and it wrote the code that emits it [5]. The owner's second ask, 68 days after the first, is what the author treats as the evidence, on the grounds that anybody can miss a rule once [6].
The check that shipped is narrower than the rule it replaced. It stops at whether every internal term, on first appearance, sits next to a plain-language gloss, and the author says plainly that this does not prove the paragraph is clear [9]. What it catches is the failure the owner complained about, which was a run of `verdict`, `FOLLOW_DAILY_CAP` and `stock-runway` with nothing around them [10].
The checker accepts exactly three gloss shapes: term (gloss), gloss (term), and term = gloss [14]. A parenthetical counts only when it holds two or more consecutive characters of prose in the reader's language, sitting adjacent to the term [15]. The first implementation of the third form accepted an equals sign followed by any text containing prose within the next 24 characters. That passed `verdict=infeasible-at-cap was raised`, because prose appeared later in the sentence, and it recorded `verdict` as glossed. The gloss now has to begin immediately after the equals sign [16].
The checker holds a set of seen terms, so each one is reported once [17]. So the eleven violations in the three-line draft are eleven distinct terms [19], about 3.7 a line [18]. For that rate to say anything about your own drafts, your prose has to be as dense in internal vocabulary as a shop report whose nouns are command names and ledger fields.
The term list is derived from artefacts that already have to be correct, on the reasoning that a hand-maintained list of forbidden words would have rotted faster than the rule it replaced [11]. When the checker finds an unglossed term the glossary already defines, it returns the first 60 characters of that definition as the suggested fix [13]. A definition that has drifted therefore ships as the sentence the reviewer is told to write. The post does not report how many of the eleven flagged terms the reviewer accepted [21]. One row of the dictionary stays hand-maintained, because `behind` is an ordinary English word everywhere except in their ledgers [12].
What to watch
- Whether the checker gets wired into pnpm test so a violation makes the build red, the way the byte budget already does.
- Whether the team publishes a false-positive count once more reports have run through the checker.
- Whether the derived dictionary keeps up as new commands add jargon, or the hand-maintained row grows into the linter list they set out to avoid.