Floor cost repair: one producer, not three witnesses — the compile-phase frontier standing crosses the 500ms CPU ceiling and makes the required floor a coin flip

[gunbai-bot]

The coin flip, located

required-floor refused three of the last four main runs with interrupted_cpu_deadline in {17, 15, 2} and verdict=FloorRefused, while run 33673806092 on the same corpus passed. The refused rows are the same seventeen identities in three modules, and the run log names them BUDGET-REFUSED in 503..506ms against v2.workflow.required_floor required_floor_claim_cpu_safety_limit_ms (500):

module	rows
test/claim/self_host_compile_phase_live_gate_witness	13
test/claim/self_host_compile_phase_frontier_witness	2
test/claim/compiler_frontend_program_status_witness	2

On the passing run those same rows completed at 452–496ms. Nothing about them changed between runs; they sit inside one scheduler quantum of the ceiling, so which side a PR lands on is ambient fleet load.

One root, not three

All seventeen rows spend their whole cost in gunbc.self_host_compile_phase_frontier compile_phase_frontier_standing. The first two modules call it directly; the third reaches it through gunbc.compiler_frontend_program_status milestone_status, whose SelfHostWholeCorpusPopulationDerived arm asks the same question. So the repair is in the producer, not in any witness — and v2.workflow.required_floor names exactly this remedy ("reduce what the witness reaches for"; relocation is forbidden).

What was fixed

Attributed with the instrument that already exists (claim_batch --entry <witness> --functions <rows>, whose [witness] line reports per-row CPU), using probe modules that call one callee at a time. Three terms carried it, all shapes DESIGN §6 fixes on sight rather than on the realized n:

• newly_exposed_identity_admitted — a cheap identity guard conjoined ahead of an expensive cause derivation. && in this substrate evaluates BOTH operands (v1_interpreter eval_expr_inner evaluates left and right before applying the operator), so the guard narrowed the result without guarding the work: the derivation, two of whose arms scan the whole previous board, ran once per (added identity × disposition row) pair. Selecting the rows first is exactly equivalent — any(xs, p && q) = any(filter(xs, p), q) for boolean p, q.
• board_added_identities / board_removed_identities / phase_ratchet — set difference answered by any over the other population per row, making the comparison count the product of two populations that grow with every receipt. Now one identity-keyed membership index per population.
• identity_is_hop_relocation — re-derived diagnostic_semantic_key for every row of added and removed on every call. Those keys depend on the transition, not on the identity under test, so they are derived once at apply_regression_transition — the least common ancestor of the demand (DESIGN §2).

Result on this container: the worst row of each module falls from ~275–296ms to ~60–67ms.

Evidence

Every row of all three witness modules passes: 13/13, 35/35, 34/34 — including the frontier witness's discriminating reds over newly_exposed_identity_admitted, and the live gate's planted-identity and equal-cardinality-swap refusals. Those are the probes that would go red if the restructure had changed the answer.

No semantic change is claimed and none was found. The receipts' sealed identities, prefix digests and census digests are all derived, not literals, so an equal standing is an equal projection: gunbc.design_ledgers renders only latest and its output is unchanged. No consumer outside this module named any signature that moved, and the module has no stage0 Rust mirror, so no regeneration is implied.

What this does not do

It does not bring the population to the ~1ms median an ordinary witness should hold. The rows remain above required_floor_claim_cost_line_ms (100, diagnostic only) once the fleet's host factor is applied. The residue is the receipt-sealing data fold, paid once per claim — a different subject from the per-call scans repaired here.

Worth knowing beyond this diff

&& and || are strict in the interpreter and short-circuiting in the emitted Rust. The two agree on the answer and differ in what they evaluate. Every cheap_guard && expensive_derivation written in the corpus by an author carrying the Rust habit over is paying the expensive half unconditionally. This diff repairs one instance; the class is not censused.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WEFMasGn2cAGCMJW2694pb

[gunbai-bot]

Verified on the floor, at identity grain rather than by the green

Run 33688872492, required-witnesses-floor:

required-floor: planned=3498 executed=3498 terminal=3498 passed=3423 known_red_held=26
                failed=0 interrupted_before_verdict=0 interrupted_cpu_deadline=0
                interrupted_wall_deadline=0 completed_over_cost_requirement=0 route_gap_held=49
required-floor: verdict=FloorClean

The accounting closes exactly, which is stronger than the pass:

run	planned	passed	interrupted_cpu_deadline	passed + interrupted
main 33681059548	3498	3406	17	3423
main 33680659583	3498	3408	15	3423
this PR	3498	3423	0	3423

Same planned, same known_red_held=26, same route_gap_held=49 — so the rows that were being interrupted are the rows now passing, and nothing was dropped from the population to get there.

All seventeen rows also left the over-cost report. That report lists every row above required_floor_claim_cost_line_ms (100); the three modules appear zero times in it now, where the previously-passing run had fourteen of them at 452–496ms occupying the top of the ranking. The new worst row on the floor is v2.test.execution.rust_emit_host_call_equals_eval at cpu_ms=395 — unrelated to this diff, and now the head of that population.

One read I had to correct mid-check: my first attempt to grep this log returned 0 BUDGET-REFUSED, which looked like confirmation. The log was empty because the run had not finished, so that zero was a fact about the fetch and not about the run. The figures above come from the completed job.

— sent from warm-ibex-636