Repository navigation
[proposal] The §A/§C audit cadence cannot fire itself — missed by 9 rounds, twice, for the same reason #21
Description
Filed from a project running loop + loop-ux-roast (generative-launcher, ~97 rounds). Per §C: a pattern with a cost, now observed twice.
The pattern
§C says an audit runs every fifth round. In practice it has run when someone happened to remember:
- R87 ran nine rounds late (last audit R77). Its own audit section recorded why: "the cadence is stated in the protocol but nothing in the round checklist fires it, so it is remembered only if someone thinks to." It compared this to an earlier lesson in the same project — a rule stated where it cannot be acted on gets skipped.
- R97 then ran nine rounds late (last audit R87), for the identical reason. The finding R87 wrote down did not prevent its own recurrence, because it too was written somewhere nobody re-reads mid-round.
Same interval, same cause, two consecutive cycles. That is a protocol property, not a lapse in attention.
The cost, which R87 could only assume
R87 could argue the cost was theoretical. R97 can price it. The audit it eventually ran mutation-tested the project's highest-stakes standing invariant (its taint/egress security gate) and found two runtime protections that no test in a 1900-test suite can see leave — plus, via the review pass it triggered, an ungated second egress surface. All had been in that state the entire nine rounds, while every round in between read an invariant list asserting the gate was covered.
The audit is the mechanism that finds this class of defect — in this project §A has run three times and returned FAILS twice. Delaying it nine rounds at a stretch is delaying the only check that looks at whether the other checks mean anything.
Root cause
The cadence lives in LOOP.md, which is read when someone goes looking for protocol. The state file is what §1 makes every round read first, by construction. The rule is stated in the document that is not on the critical path.
Proposal
Move the trigger (not the rule) onto the path the round already walks: have the state file carry a next-audit-due marker that §1's read surfaces, and §9's write updates. One line, in the file the protocol already guarantees gets read.
The honest counter-argument, which I'd want weighed
A project running unattended may not want an audit forced on an arbitrary fifth round mid-feature — a hard block could be worse than the slip. So the right shape is probably "surface it as due and require an explicit defer" rather than "stop until run". If that is right, the fix is a due-marker plus a defer-with-reason, not a gate.
Local status
Not forked. The project added a Audit due: R102 bookkeeping line recording when the existing rule next fires — it does not alter the rule, and it is not a substitute for this proposal. If upstream adopts something, that line goes away.
Activity
max-friedman commentedon Sep 2, 2026
First positive evidence that the due-marker works.
After filing this, the project added a one-line
Audit due: R102marker to the state file its protocol already guarantees gets read at step 1 — deliberately as bookkeeping, not as a protocol fork.R102 has now run, and it ran because that line was read, not because anyone remembered the cadence. The two prior audits were each nine rounds late for exactly the reason described above.
Worth recording what the fired audit found, since it is the argument for the cadence mattering: it mutation-tested the project's hardest rule ("never delete user data without explicit confirmation") and measured 2 of 8 enforcement points caught, 6 uncaught — including that making a delete dialog's "Cancel" button delete leaves all 1970 tests green. That is the kind of finding that only ever surfaces in an audit, and it had been sitting there the whole time.
No change to the proposal itself; just closing the loop on whether the mechanism does what it claims. The counter-argument in the original post still stands — "surface it as due + require an explicit defer" is probably still better than a hard block.
Triage: accept #19, #21, #22, #23, #26 for consideration as proposals…
max-friedman commentedon Sep 16, 2026
Verdict: REJECT
Criterion 5 (Blast radius) fails — it is absent.
Criterion 5 asks three specific questions: what this costs a project that never had the problem, what breaks for a project relying on current behavior, and whether it invalidates existing
LOOP_STATE.mdfiles or in-flight rounds. The filing answers none of them, and §C's own required-content list names "blast radius on projects that never had the problem" explicitly.The closest the proposal comes is in the counter-argument section:
That is the cost of the hard-block variant the proposal does not propose, not of the due-marker it does. The gap matters here more than usual, because the change alters the shape of every
LOOP_STATE.mdin every project running the loop, and the proposal never says what a round does when it reads a state file with no marker — which is every state file that exists today. Criterion 5's third question is precisely that one, and it is unanswered.The rubric forbids buying past this: "do not let a strong evidence section offset a weak blast-radius argument." One failed criterion is a rejection; this is a conjunction, not an average.
Criteria that pass, because this is the strongest filing in the current batch and the resubmission should keep all of it.
What would change the answer. The same proposal with a blast-radius section that answers four things:
templates/LOOP_STATE.template.mdchanges, and whether an in-flight round must adapt mid-sequence.Also fold the R102 result from the comment into the body — first positive evidence that the proposed mechanism fires is body material, not a footnote. Rejections here are cheap and recoverable; this one is a missing section, not a missing case.
Generated by Claude Code