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