PREEMPTION-1: the opaque-host-call population was a selection view of its own discovery instrument — one member, truthfully eight, now grounded in the seed's dispatch authority

[gunbai-bot]

The defect

The PREEMPTION-1 §4b rung drop is declared over a population of host operations whose cost accrues where no safety poll can land. That population carried one member and called itself "exhaustive rather than illustrative", on this reasoning: compile_dag_rust_emit_check "is the only native free_call.* arm this corpus has MEASURED reaching CPU cost the safety poll cannot see", citing floor run 32301212975's 60317ms row.

Both halves are true and the arrow between them is invented. Being caught over a limit in one floor run is how the operation was found; it is not what makes it unbounded. The finding aid was read as the population — DESIGN's selection_view_read_as_population — so a declared drop under-reported its own bounded population by eight to one, and seven arms that have always reached the identical unpollable dispatch shape were left describing themselves as protected by a guarantee that has never held for them.

The criterion, and the eight members

A free_call.* arm whose Rust realization synchronously runs a nested compile of .dag sources. Each row carries the Rust entry point that makes it a member, so a reader re-checks membership rather than trusting it:

arm	nested compile reached
compile_dag_rust_emit_check	compile_sources
compile_dag_diagnostic_census	compile_sources
compile_dag_multi_module_fixture	compile_to_resolved
observe_declared_import_closure_symbol_binding	compile_declared_import_closure_only_with_pool
witness_layer_roots_compile_clean_check	compile_to_resolved_with_options
witness_layer_roots_compile_clean_emit_check	floor_compile_clean_emit_ok
install_or_consume_floor_compile_clean_gate_receipt	whole-tree compile on lazy install
witness_compile_clean_cli_floor_verdicts_agree	two whole-tree compiles

install_or_consume_floor_compile_clean_gate_receipt's own doc comment already warned that "a Bool read could cost a whole-tree compile" — it was outside the population anyway.

What the criterion does not cover is named rather than implied: free_call.extdeps_qualified_name_resolves_in_derived_module_set reaches a whole-corpus INDEX build — unbounded in the same way, not a compile. It is outside this criterion, not bounded. Widening to "unbounded opaque host work" needs its own survey and carries a dissolution condition saying so.

The grounding

gunbc.v1_interpreter_opaque_host_call sits beside the dispatch roster, not beside the floor, because every member resolves against gunbc.v1_interpreter_primitive_surface v1_interpreter_primitive_arms — the seed's single dispatch-surface authority, itself drift-gated against the generated lookup tables. Rename or delete an arm and the join goes red; the prior hand-typed literal was joined to nothing and would have stayed green.

opaque_host_call_surface refuses rather than shortening its list when the join breaks. A List<String> that silently dropped unresolved rows would shrink the safety population at exactly the moment it matters — the absorbing fallback §5 forbids.

Executed evidence

The wall's two arms were previously exercised against one hand-typed string and one invented string (some_unmeasured_new_host_call) that can never occur — so the refusal arm had never been shown against a real host operation. Four new witnesses in test.claim.preemption_reachability:

• the grounding join goes red on roster drift;
• the two tower spellings are held equal at identity — injection by per-member admission, plus distinctness, plus equal cardinality — not a count comparison;
• a second real member (install_or_consume_floor_compile_clean_gate_receipt) is admitted by name, so the correction cannot be silently reverted to the measured-only reading;
• filesystem_read, a live free_call arm meeting no criterion, is still refused — the wall did not collapse to admitting everything as the population grew.

What this does not do

It does not make an opaque host call interruptible. The specimen row still completes at twelve times its limit. This corrects what the declared drop says about itself and grounds the wall that governs its growth; the restoration trigger — a deadline-aware contract or a killable process boundary — is untouched and still open.

Two things verified for that follow-up while reading the arming path:

• The wall deadline is poll-based in eval_expr (line-adjacent to the CPU poll) and has one genuinely out-of-loop enforcement: wait_child_honoring_wall_deadline drains a shell child on a worker thread, polls wall_deadline_exceeded_error() at ≤250ms, and kills the process group. That is the restoration trigger already implemented — for shell children only, not for synchronous in-process arms.
• So the shape of the remaining work is decided by a boundary, not a clock: a watchdog thread can observe a crossing inside a synchronous nested compile but cannot stop it. Interruption needs the compile behind a killable worker process, exactly as ClaimPreemptionReachability's trigger says.

Local execution was not available (BuildBuddy refuses with HostBudgetUnreadable — no cgroup limit binds the runner), so the four witnesses are validated by CI.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JwDQpQY1QGK6SzuixLuTov

[gunbai-bot]

CI status, with the one red attributed.

• required-witnesses-build pass (18m45s) — this alone proves the three files compile; one witness compile error refuses the whole floor.
• required-witnesses-floor pass (23m18s) — the four new witnesses executed green. That is the executed evidence the change is about, and it is the run I could not get locally (BuildBuddy refuses with HostBudgetUnreadable: no cgroup limit binds its runner).
• witnesses (required aggregate) pass.
• rust-unit-tests fail — not this branch. compiler_tests::shell_service_unmodeled_output_key_refuses panics at compiler_tests.rs:1045 ("service module must emit src/probe.rs"). It is red on main across the five most recent concluded runs, with the identical signature and the identical tally (645 passed; 1 failed; 141 ignored) — checked on run 33615659836, a main run. This diff touches no Rust at all; the test was introduced by XL-0-SERVICE: the service-emission path in 05_emit_rust binds stdout to every declared output field and does not box the error arm — it emits non-compiling Rust #9886 (XL-0-SERVICE) and belongs to that lane.
• fabric-evidence pending at 0s — a currently declared §4b rung drop, not a required merge block.

mergeStateStatus is UNSTABLE rather than BLOCKED, which is the shape of a non-required check being red.

— sent from merry-koi-65

[gunbai-bot]

Correction to the comment above: fabric-evidence was not stuck — I read it mid-run. It passed (36m52s). Final state of this head:

check	result
required-witnesses-floor	pass (23m18s)
required-witnesses-build	pass (18m45s)
witnesses (required aggregate)	pass
fabric-evidence	pass (36m52s)
emit-copy-qualification-battery	skipping
rust-unit-tests	fail — main’s red, compiler_tests::shell_service_unmodeled_output_key_refuses, identical signature and tally on main run 33615659836; #9886’s lane

So the only red on this PR is one that is red on main too, in a job that is not a needs of the required aggregate. mergeStateStatus oscillates between UNSTABLE and UNKNOWN as GitHub recomputes; UNSTABLE/MERGEABLE is the settled reading, which is the shape of a non-required check being red.

— sent from merry-koi-65