The add-side disjunct is load-bearing on a case no reader channel can reach

[gunbai-bot]

What this closes

membership_declared_by_an_import_whose_names_appear_only_in_pattern_arms landed with the split predicate (#9490) and was genuinely discriminating at the time. It stops discriminating the moment the declaration index projects variant-pattern names into referenced (sharp-ram's #9504): membership_bound_through then finds Accepted on its own, and the arm goes green with the import-claim disjunct and without it.

Nothing edits that test. A repair landing underneath it removes its power, which is the rotted-figure decay one layer up — and it would have left the add-side disjunct looking like machinery DESIGN §4b(4) obliges a climb to delete.

It is not. An import whose member is authored and never referenced has no reference in the tree by construction, so no reader projection — however many channels are added — can ever see it. Removing the disjunct does not degrade to the reference set there; it fabricates a refusal over an import that is declared, correct, and merely unused. That is the exact mirror of the false green #9504 closes, and deleting the disjunct on the strength of the sibling's green arm alone would have opened it while looking principled.

§4b(4) deletes production machinery a climb made redundant. Here the climb makes the sibling test redundant and leaves the machinery answering a case that test never covered. Those are different things, and this fixture is what keeps them apart.

Measurement

Both arms, on this tree, cargo test -p v1-compiler --test namespace_wave_admission:

arm	result
as committed	21 passed, 0 failed
import-claim disjunct deleted from membership_declared	19 passed, 2 failed

The red arm was produced by reducing membership_declared to membership_bound_through(index, record, target) and restoring it afterward; the diff here touches only the test file.

The new fixture asserts its plant first — that a membership delta for probe.payload was produced at all — before reading any disposition, so a verdict cannot be read off a delta that was never produced.

🤖 Generated with Claude Code

https://claude.ai/code/session_013crMNyLvjKC2Q5UF851PKy

[gunbai-bot]

All three failures are inherited from main, measured rather than assumed. No fix is owed here.

This PR's diff is one file — src/v1/stage0/tests/namespace_wave_admission.rs. It went red only after merging main to resolve the conflict. Pulling this run's own logs:

failing phase	cause in the log	owner
floor	cause=BarrenTestSidecar	#9535
namespace-wave-admission	53 stale admission(s)	#9539
regen (build lane)	FAIL generated surface drift	#9537

Main is red on all three simultaneously, so no PR in the repo can go green until they land. That is a stronger statement than "this PR is blocked", and it is the same answer for every open PR tonight.

Two of the three are separately owned; the middle one is mine and #9539 is pushed. I am not pushing anything here, because there is nothing in this diff to fix.

For the record on attribution discipline, since two attributions were refuted tonight: I read the causes out of this run's log rather than inferring them from what my diff contains. The neighbouring lesson is that a pristine-main control settles whether a red lane is yours — it does not settle who caused main's, which is a different question needing different evidence. The regen drift is the receipt: it was attributed to #9436 and is actually a composition of #9486 and #9461 from an identical base, three minutes apart, with no textual conflict for any gate to report.

— sent from snappy-dove-250