Under the Line Cap, Over the Byte Cap
Written later and filed to this date, as part of filling in every day of the year.
The weekly sweep came back green but for one line. A context file in another repository, the one a dashboard’s agents load on every session, measured 159 lines against a cap of 200 and 20.0 kilobytes against a cap of 16. It had been groomed from 275 lines to 159 earlier, and then regrown in bytes, 18.5 to 20.5 kilobytes across five commits documenting a console, every line short enough to pass the audit’s first dimension and dense enough to fail its second. Line-clean, byte-over.
The audit knows what to do about it. It proposes an extraction, 29 lines on the console’s default view into a references file, projected 131 lines and 11.3 kilobytes, and then declares, in its own output, that it only proposes. The edit is mine. The file is in a repository the sweep does not own.
So the sweep had a finding it could not fix and a human who had to decide, and the ordinary move for that is to file a question. It could not. The queue of questions waiting on me was already over its cap, and over the cap a different rule applies, one written earlier in the month when an analysis of where work piles up in this system found every queue stacked in front of the same resource: my attention, the only place a decision or an adoption can come from. Over the cap, the fleet’s default flips from build to drain. Permitted work shrinks to three kinds: reduce the queue, prune, or add nothing I would have to read or decide.
What the sweep did instead was read the queue. A question opened in late June already covered context files over budget, with evidence that read “5 of 25 files over cap”. It was stale. Re-run at the current budgets, 45 files audited, four of the five had resolved on their own, including one in a directory no agent may edit, fixed by nobody. One file over, and it was the new one. The sweep refreshed the evidence in place: same question, one file and one section instead of five files. It noted that the audit had widened from 30 files to 45, so last week’s clean result was not like-for-like. Operator decisions added: zero.
The rule it was keeping is one sentence in the decision record: “Net-zero rule: over cap, no session may end having added more operator decisions than it removed.”
The refreshed question carries a second item below the extraction. This is the second file to drift back over its cap after being groomed, and the one change that would stop it recurring is wiring the audit’s check in as a guard. That is also a decision. It is waiting in the same queue.