Four stale claims, all in durable documentation that would have shipped
as written.
The framing still said "AWAITING APPROVAL. Nothing implemented" while
the ledger and the PR both said otherwise.
R7's status line said SIXTH OCCURRENCE while the body below it recorded
the seventh. Its tree-exclusion bullet said the observing lane's diff is
two docs; the lane carries three. And its cumulative figure said in-gate
is 2 failures in 3 runs, which omitted this lane's final head-exact
verification gate --- a fourth in-gate run, green. The figure is 2 in 4,
and the fourth is named so a reader can tell which run it was.
Active-work carried the same stale docs count and the same 2-in-3, and
recorded neither PR #244, nor the final head 2d76984, nor the gate log
20260829T152824Z-673477. It now carries all three, with the gate's
result read from its eight stage logs rather than inferred from stage
exits.
The sweep that found the last 2-in-3 also printed "(none = consistent)"
unconditionally, which is the read-success-from-absence shape this
project keeps catching. It now prints the hit count and only claims
CLEAN when that count is zero.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Both `duration_ms < 100` assertions --- src/async_runtime.rs and
tests/m4_acceptance.rs --- now print the observed value and the budget.
Neither budget moves.
dispatch_parse_round_trips_a_rust_source_file redded twice on
macOS/lua54, as U11 and again on #243, and BOTH margins were
unrecoverable: the message said only "trivial parse should be fast", so
the second red could not be compared with the first. A 1ms overshoot and
a 900ms overshoot are different failures that produced identical logs.
U11 predicted that cost in writing, and it came true once.
D1 and D2 are verified against REAL PANIC MESSAGES, by forcing only the
comparison bound to 0 in a scratch build:
trivial parse should be fast: took 0ms against a 100ms budget
200-line parse should be quick: took 11ms against a 100ms budget
The second is the stronger demonstration --- a non-zero observed value
cannot be mistaken for a literal.
That scratch panic proves only half. It exercises a budget of 0 while
printing 100ms, so it says nothing about the committed threshold. D3
carries that half separately by pinning the literal 100 in both files.
The two are a proof together and neither substitutes for the other.
The framing withdraws revision 1's claim that the async_runtime
assertion was the codebase's sole measurement-omitting one. It was not:
tests/m4_acceptance.rs:244 is the same measurement against the same
budget. The claim is withdrawn rather than repaired, because a sweep
wide enough to be complete also catches `Instant::now() < deadline` loop
guards and `eval::<bool>` turbofish, while one narrow enough to be
accurate proves nothing about completeness. This is not an
assertion-hygiene audit.
workflow_dispatch was split out per the ledger's own recorded decision;
it and U9's still-unrun discriminating control remain separate lanes.
Framing docs/parse-budget-diagnosability-framing.md revision 2, approved.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016bqGA6s9tTUFzYpbeW3tai
Levi Neuwirth