Take the extdeps-scope loudness probe out from behind a 718-module import

[gunbai-bot]

Scope, stated up front: this is a §2/§3 cleanup. It does NOT reduce the floor's 78.6s row. The PR opened claiming it did; I measured that on CI and it was false, and the title and body below are what survives the retraction. Full correction with numbers: comment.

What this changes

claim_executor derives the <witness>_failure_receipt companion from a Bool witness's own name and evaluates it in the witness entry's context, so the always-false probe pair red_seed_runner_failure_detail_projects_located_receipt exercises had to be reachable from the witness. It was reached by importing tools.floor_effect_gate_witness — which drags in that entry's whole gate closure (ci_gates, the compile-clean, generated-artifact and regen-verify gates, ci_spec) for a name literal and two lines of probe.

• The probe pair moves into the witness entry as seed_runner_loudness_probe_* — where the companion convention wanted it — and is deleted from tools.floor_effect_gate_witness rather than duplicated.
• The orphaned _companion_name wrapper and its name row go with it; their one reader was this witness, which now asks the single authority gunbc.test_module_hygiene failure_receipt_companion directly.
• The probes are func, not test fn, so floor discovery (which selects TestMarkedDecl only) does not enroll them.
• That entry's mute-frontier prose is corrected nine/six → eight/five rather than left describing decls that are gone.

What it is worth, honestly

	before	after
import closure	718 modules / 10.1 MB	62 modules / 0.49 MB
witness entry resolve, under claim_batch	30.726s	1.005s

That saving is real in claim_batch, which resolves the witness entry, and absent in the required floor, which prepares one shared subject for 3663 modules so no per-entry closure is on its critical path. Measured on CI: the row costs 78589ms on main and 90372ms here — no saving, and the difference is host noise.

Why the row is actually expensive, and why nothing here fixes it: its cost sits inside a host builtin (resolve_hygiene_ctx → resolve_entry_graph_shared, standing up a second whole-corpus context) that never returns to eval_expr, so the stride poll cannot see it and the existing 500ms budget cannot cap it. Per my parent lane's measurement this row is 1 of 116 expected-red rows escaping that budget, together 881.8s — 83% of the floor's slow-witness cost. That is a class-level fix being escalated separately; the seed-side repair is deliberately not attempted here, because its only caller is a row under review for deletion and fixing it would be new investment in the frozen v1 seed (DESIGN §3).

The row is also enrolled in v2.workflow.floor_expected_red: in the floor it returns false and the roster holds it. Deletion is on hold pending that class fix and a check for an active fixer — cost alone no longer argues for it, since the class fix would cap it at 500ms.

Evidence

The claim is unchanged — same production seed_runner_bool_false_failure_detail, same located-receipt assertions — shown by execution:

• all seven rows of the entry pass under claim_batch (rc=0);
• renaming seed_runner_loudness_probe_failure_receipt so the companion derivation misses it takes this row RED (rc=1).

CI

Red, and inherited: main fails the same step at this branch's base commit (40 failures vs 42 here). The differing identities are Cpu/Wall budget-class churn in modules this diff does not touch, in both directions. Detail: comment.

[gunbai-bot]

Correction: this does NOT move the floor's 78.6s. Measured, both directions.

I have to retract the headline of the PR body. The first CI run on this branch is the discriminating measurement, and it refutes the premise I built on:

	main (32097006674, 3abc17b)	this branch (32111134617)
red_seed_runner_failure_detail_projects_located_receipt	78589ms, RSS +1.00GB	90372ms, RSS +1.00GB

No saving. If anything it reads worse, and I take that as host noise rather than a regression — but either way the number this PR set out to cut did not move.

Why the pare misses in the floor. My 30.7s → 1.0s figure was measured under claim_batch, which resolves the witness entry itself, so per-entry import closure gates the run there. The required floor prepares one shared subject for the whole corpus (modules_resolved=3663), so no per-entry closure is on its critical path. The saving is real in the harness I measured and irrelevant in the harness the brief was quoting. That is my error: I measured the cheap harness and reported it against the expensive one's number.

Where the 90s actually goes — visible in my own earlier receipt and not read carefully enough at the time. Running this one row resolves three entries, not one:

dag/test/claim/extdeps_scope_placement_gate_loudness_witness_test.dag   1.005s   (what this PR fixes)
dag/gunbc/output_policy.dag                                            26.849s   load=23.8s
dag/gunbc/test_module_hygiene.dag                                       0.034s

The two extra entries come from the seed, not the witness: cli_run/test_module_hygiene_bridge.rs resolve_hygiene_ctx calls resolve_entry_graph_shared to answer the companion-name lookup, standing up a second whole-corpus context beside the one already resident — the exact hazard cli_run.rs prime_witness_execution_legs documents in-code and fixed for itself by taking the caller's index instead. Both failure_receipt_companion_from_authority and witness_verdict_diagnostic_companion_from_authority route through it, and this row is the corpus's one caller of that path.

A second fact I should have led with: this row is enrolled in v2.workflow.floor_expected_red. In the floor it returns false and the roster holds it. So in CI today it establishes nothing and costs ~90s to do it — it passes only under claim_batch (verified, rc=0, with the mutation control red at rc=1).

What I am NOT doing unilaterally

Two candidate dispositions, and both exceed what this brief authorises me to decide alone:

1. Fix the seed bridge — thread the caller's index into resolve_hygiene_ctx the way prime_witness_execution_legs_from_authority already does. Root-causes the cost for every caller, keeps the claim. But it is hand-Rust inside the frozen v1 seed, and DESIGN §3's freeze is explicit that a frozen X takes no new investment.
2. Delete the row — it is expected-red in the floor, so nothing is lost from CI's verdict, and ~90s plus 1GB of peak RSS goes away. But it is enrolled as branch debt someone may be actively fixing, and the roster's own note says a row belongs there "only while someone is fixing it" — deleting the subject out from under that is not mine to decide.

What stands in this PR regardless of that decision: the §2/§3 half. The probe pair no longer sits behind a 718-module import; the duplicate _companion_name wrapper is gone in favour of the single authority; the gate entry's frontier prose no longer describes deleted decls; and the offline/claim_batch execution of this witness is 30× cheaper to resolve. That is worth keeping on its own terms — it is just not the 78.6s.

Asking my parent lane which of the two dispositions to take before touching either.

— sent from clever-carp-725

[gunbai-bot]

Re: "CI failing, push a fix" — there is no fix of mine to push. The red is inherited from main.

main is red at the exact commit this branch forks from (3abc17b), in the same required-floor step:

	main run 32097006674	this branch run 32111134617
conclusion	failure	failure
required-floor:	planned=9418 executed=9418 passed=8584 known_red_held=794 failed=40	planned=9418 executed=9418 passed=8582 known_red_held=794 failed=42

The last four witnesses runs on main are all failure. This PR did not turn a green branch red.

The two failure sets are not nested — they churn in both directions

31 identities fail in both runs. 9 fail only on main; 11 fail only here. If this diff were the cause, the difference would be one-directional; it is not.

11 branch-only, every one a budget overrun by 1–27ms against a 500ms budget:

generic_item_clone_bound_witness.impl_accessor_inherits_item_bound_once      Wall 500ms vs 500ms
generic_item_clone_bound_witness.recursive_declared_type_saturation_positive  Cpu 512ms vs 500ms
where_refinement_enforcement_witness.*  (4 rows)                              Cpu 516-527ms vs 500ms
roadmap_forecast_witness.*  (2 rows)                                          wall/eval 501ms vs 500ms
roadmap_receipt_continuity_acceptance.*                                       wall budget exceeded
translate_underived_refusal.cross_language_compile_refuses_canonical_underived Cpu 509ms vs 500ms
emit_ingest_python_same_language_round_trip.python_same_language_parse_bridge  wall budget exceeded

9 main-only, a different class entirely — emit_host_* and rust_record_construct_emit_host_*, all errored: host tool unresolved:.

Nothing failing names anything this PR touches

The diff is two files. No failing identity is in tools.floor_effect_gate_witness or test.claim.extdeps_scope_placement_gate_loudness_witness, and the moved probes (seed_runner_loudness_probe_*) appear in no failure. The witness row this PR is about holds identically on both runs: enrolled in floor_expected_red, returns false, held as expected — 78589ms on main, 90372ms here, which is the measurement I already retracted the PR's headline over.

I am deliberately not pushing anything. Every candidate "fix" here is someone else's row: raising a 500ms budget to absorb a 9ms overrun is the absorbing fallback DESIGN §5 forbids, and the host tool unresolved family is a runner-environment fact, not a source defect. A commit from me would also cancel in-flight CI and buy nothing.

The real blocker on this PR is the disposition question in my previous comment (fix the frozen seed bridge, or delete the expected-red row), which is with my parent lane. Merge readiness otherwise: 2 approvals, no REQUEST_CHANGES, mergeable CLEAN.

— sent from clever-carp-725