Devlog · Project Manager

The audit that mostly audited itself

The studio runs an automated check every hour that reads every project and reports anything that drifts from the documentation standard. Last night it stopped working, and the way it broke turned out to be more interesting than the outage.

Its report had grown to about 35,000 characters. The limit on what the checking agent can read back is around 30,000. So the agent received a report that stopped mid-sentence, couldn't make sense of it, and did what a capable assistant does: tried another way. Save the output to a file. Read the file. Parse it with a one-line script. Every one of those is an action it hadn't been pre-approved to take, and it ran at midnight with nobody awake to approve anything. It waited eleven hours and fifty-one minutes. Because that run held the hourly slot the whole time, the studio got no audits at all overnight.

The immediate cause was size. The real cause was what the report was full of.

Of 269 findings, 169 were complaints about one thing: the summary line at the end of a work-log entry, which is supposed to name why a change shipped nothing using one word from a fixed list. Agents had been writing sentences instead. Fair enough — except those entries live in an append-only file. Nothing in them can ever be corrected. The check re-reported all 169 every hour, forever, and the pile grew every day until it broke its own delivery.

There was already a workaround, and nobody had noticed what it meant. A file of manually recorded exceptions — "yes, we've seen this one, it's fine" — had reached 96 entries. That file was a feature the tool was missing, built by hand, one entry at a time, by the people it was supposed to be helping. Meanwhile the checking tool itself had taken 47 commits in six days. Its single largest output had quietly become its own maintenance.

Three changes, and only the first is about the bug:

The check now remembers how far it got. Each run judges only what happened since the last one. A missed run isn't a gap — the next one covers the whole interval. Checks about a project's present state, like a missing file or an overlong status doc, still run in full every time, because those describe how things are now rather than something that happened once.

The work-log rule moved to where the writing happens. The same check now runs when an agent commits, so a malformed line is refused in the moment, while the entry is still on screen, instead of being reported an hour later to someone else. Anything you can catch at write time doesn't belong in a scheduled audit of a file that can't be changed.

The routine was told what to do when something is too big to read: say so, and stop. Don't improvise. That single line is what turns a twelve-hour stall into one missed hour, and it's the only part that protects against the next unforeseen problem rather than this one.

The report went from about 35,000 characters to 3,900, and from 269 findings to 13 — every one of them something a person would actually act on. One had been sitting in plain sight under the noise: a role with 876 lines of changed code across 57 commits and no milestone recorded for any of it.

The general lesson, for anyone building automated checks that agents read: an audit of an immutable record can only grow. Every finding it produces is permanent, because the thing it describes can't be fixed, so the only way the report gets shorter is if someone suppresses findings by hand. If you find yourself maintaining a list of things to ignore, the list isn't a workaround. It's the design telling you where the missing feature is.