Make the witness-roster walk demand-directed instead of unconditional pre-plan

[gunbai-bot]

What this deletes

claim_executor ran discover_floor_witness_roster_with_snapshot before resolving the plan, unconditionally, on every invocation — ordinary floor, regen, falsifier, and every scoped worker.

Its own comment stated the intent:

the plan path always runs the fail-closed walk once up front — before the (expensive) plan evaluation, so a naming violation is the cheapest possible failure

Measured, it is the most expensive phase in the process:

path	walk cost	of
ordinary floor (run 31477894666)	5.9 min	56.5 min
regen	~6 min	~15 min, on a two-node plan

Why it costs that

"Naming hygiene" is a misleading label. The four rules in v2.workflow.floor_naming_hygiene are string predicates over file paths and line prefixes — no parse, no resolve, no types. But the roster producer they are reached through additionally builds module-graph facts, runs a second strict reference-resolution pass, computes path indexes, and runs inert-lens reachability plus the construction-justification census.

Regen's plan has two known gates and no discovery batch. It paid six minutes to discover a roster it never reads.

The change

Hygiene is a property of the witness roster, so it is now paid by the plans that have one. The walk moves to the existing schedules_discovery predicate, after the plan's batches settle.

• Plans that do schedule discovery pay exactly what they paid before. The roster is memoized by request digest (IN_PROCESS_ROSTER_BY_REQUEST), so the corpus batch hits the memo this call fills. Same total work, later.
• Plans that do not schedule discovery pay nothing — and cannot be unhygienic, because they have no roster.
• The walk-attempt id is still minted unconditionally; it is a tracing coordinate every later phase stamps, and it is not the expensive part.

Also closes a hole the repo already named

gunbc.ci_spec gunbc_ci_floor_batch_wall_budget_note:

PRELUDE COVERAGE HOLE — the ~5min before batch-1 arms (naming-hygiene walk, policy install, plan resolve/eval, governor arm, eager compile-clean install) sits OUTSIDE every batch budget and can only red at the 55min step cap.

The walk is now inside the region the plan accounts for, or absent.

What this is NOT

Not a cache, not a memo, not a scope narrowing of the hygiene rules. Every plan that has a roster still runs the identical fail-closed walk over it. This deletes an unconditional call edge, not a check.

Follow-ups deliberately excluded (they are the next PR, not this one): moving the placement rules to the ingestion boundary, deriving test identities from the parser rather than a line scan, dropping the __ filename rule, and removing the inert-lens census.

Acceptance

• cargo check -p v1-compiler --bin claim_executor clean
• CI's own floor is the executed control: it schedules discovery, so it must run the walk and stay green
• regen is the discriminating measurement — it schedules none, so its walk count must go to zero and its wall must drop by the phase cost

[gunbai-bot]

Thanks — approving note taken. One correction to the coverage analysis, because the mitigation named in review 51098 is not the one that actually holds.

The axis is not selection. The review reads the loss as "a *_test.dag not selected into any batch in a given run". Selection isn't what changed — the moved call still passes scan_dirs: &[] and discovery_scope_dirs: &[], i.e. it is still the whole-source-root walk with identical coverage. What changed is whether the plan schedules discovery at all.

So the loss is exactly:

ordinary floor plan   schedules discovery (batch 3)  → full-tree walk still runs, per PR
regen plan            two nodes, no discovery        → no walk
plan-artifact plan    no discovery                   → no walk

Every PR runs the ci job, whose plan schedules discovery, so a misnamed *_test.dag still reds per-PR at full tree scope. The residual gap is regen-only and plan-artifact-only runs.

The falsifier is not the backstop. Review 51098 attributes coverage to "the falsifier cadence that runs discovery cold". That cadence has not produced a green verdict since 2026-08-03 — eight days. Its cold-corpus component currently reports verified=false / BudgetExceeded on a component that ran all 8,600 witnesses in its usual 63.7 min (the failure mode is mislabelled; the underlying diagnostic is 12 ordinary witness reds). Receipts: runs 31450909331 and 31460888571, floor-component-receipt artifact, affected_set_cold_control.

Citing it as the compensating control would be resting this change on an instrument that is currently dark. The ordinary floor is the real backstop, and it is sufficient for the per-PR claim.

— sent from eager-cat-841

[gunbai-bot]

Both findings from review 51099 verified against the code and addressed in ff43f42.

Finding 1 — documented behavior drift. Correct, and blocking. Fixed.

DESIGN.md Building & checks did say the opposite of the new code (the executor runs the zero-enrollment naming walk when no discovery batch is scheduled), and the diff did not touch the authority. That is the §3 violation as described. The clause is now superseded in gunbc.design_document — the .dag authority, not the generated DESIGN.md, which the heal job regenerates.

The reviewer's characterization is also right on the substance and I've written it that way rather than softening it: these are corpus-wide nameability rules, not roster enrollment rules, so skipping them on discovery-free paths is a policy change. It is recorded as a declared narrowing with the honest coverage argument — every PR runs the ci job, whose plan schedules discovery and walks the full tree at unchanged scope, so per-PR coverage is unchanged; what is deleted is a second redundant walk on regen-only and plan-artifact-only runs. The note also states explicitly that this is not backstopped by the affected-set falsifier, which has produced no green verdict since 2026-08-03.

Finding 2 — ordering trade for discovery plans. Correct, intentional, now priced in the note.

Confirmed: batches are known only after plan resolve/eval, so a naming violation on the floor path pays ~0.5 min of plan resolution before refusing, reversing the original "cheapest possible failure" ordering. The trade is stated in the design note with both sides of the number: ~0.5 min later on the refusing path, against ~6 min saved on every regen.

A dissolve-on is recorded with it — the clause, the separate walk, and the __-basename rule all retire when the placement rules move to canonical source ingestion and test identities derive from parser-produced declarations rather than a line scan.

— sent from eager-cat-841