Unbreak main: the stage0 partition roster gains #9689's three modules, and the required build lane gains the partition crates as the wall

[gunbai-bot]

What was broken

cargo build --release --workspace has been red on main since #9689. v1-stage0-v1-infer fails with 13 errors — E0432 on crate::std_target_representation and crate::extdeps_languages_rust_representation, E0433 on those two plus crate::gunbc_rust_source_type_bindings, all from v1_compiler_coercion.rs, plus one E0282 forced by them. #9689 added those three modules to stage0 lib.rs and to src/v1/stage0/src, but not to the derived crate partition — so the partition crates, which compile each stage0 module through a per-crate #[path] include and a reexport chain rather than through the monolith, had no owner for any of them.

The required gate could not see it. Its build lane ran cargo build --release -p v1-compiler --bins. None of the seven partition packages is v1-compiler, so no required phase compiled any of them, and the gate stayed green over a red workspace for a day.

The roster fix, placed by measurement

Authority is v2.workflow.rust_crate_partition; the generated .dag, the stage0 mirror and the crate lib.rs files all follow by regeneration. Placement is forced by each module's own crate:: references, not chosen:

module	additionally depends on	unit
std_target_representation	std_decl_ref, std_types, v1_rt	std-core
extdeps_languages_rust_representation	+ extdeps_uri, extdeps_external_authority, std_coercion	extdeps-languages
gunbc_rust_source_type_bindings	+ extdeps_languages_rust_representation	v1-infer

gunbc_rust_source_type_bindings lands through its own named list rather than being appended to the v1_compiler_* pipeline list: the crate grouping is physical, and the list name should say what the module actually is.

Before touching the compiler I reconstructed the partition closure from the authority alone — the generated rows' modules plus the transitive closure of reexport_packages, joined against the crate:: module references in each rostered module body — and it named exactly those three modules in exactly that one crate, with an empty missing set for the other six. The compiler then agreed. Two independent derivations of the same three names.

The phantom row

std_lens_verdict was in the std-core roster and is not declared in stage0 lib.rs. That is deliberate on lib.rs's side: v2.compiler.self_host.stage0_crate_layout registers it as a SeedRetainedIntrinsicRegistration with has_pub_mod: false. So every partition crate carrying the row compiled a module the monolith does not — one file with two compilation stories.

Disposition of the file: dead source retained under an undeclared reason. Its source module std.lens_verdict no longer exists (the live authority is v2.std.lens_verdict), nothing anywhere references crate::std_lens_verdict, LensVerdict appears in no other stage0 file, and it is absent from the emitted_population.rs manifest. seed_retention_frontier carries retained_reason_undeclared for it.

This PR drops the roster row only. Deleting the file moves the layout authority, the retention frontier, two generated layout artifacts and two crate lib.rs files — and it must also settle src/v1/stage0_core, which is not a workspace member (an orphan crate directory nothing builds, which also path-includes the file). That is a follow-up PR from this lane, not a rider on an unbreak.

The wall

The class is: every crate::N reference in a rostered module must resolve inside its crate's own roster or the transitive closure of its reexport_packages.

The executing wall is the required build lane compiling the partition packages, with rustc as the oracle — gunbc.repo_self_build repo_self_build_partition_crates_command, whose package list is read from the partition roster rather than restated. A crate added to the partition joins the gate with no edit at the gate, so the gate cannot fall behind the authority it guards. That is the property that makes this a wall rather than a one-time repair.

Emitted step, read off the emitted bytes rather than assumed:

      - name: Build the witness fold
        run: |
          cargo build --release -p v1-compiler --bins
          cargo build --release -p v1-stage0-runtime -p v1-stage0-std-core -p v1-stage0-std-surface -p v1-stage0-extdeps-languages -p v1-stage0-v1-artifact -p v1-stage0-v1-infer -p v1-stage0-emit-core

Falsifiers, which are the enrolled evidence: drop a module from a roster → E0432 naming the module and the referrer; a roster entry naming no file → E0583 naming the entry; restore → green.

Not a whole-workspace widening. A declared bin or crate outside both the v1-compiler package and the partition packages is still built by no required phase — the standing 2026-08-25 declared row, which this does not close. Not a restored phase either: gunbc.required_ci_phase_roster (#9698) makes the four required phases a closed coproduct with PartitionCrates deliberately absent under the CI-bankruptcy rung drop. This adds a build step to an existing lane; it does not retire that drop, whose restoration trigger — a change-derived required population — is untouched.

Why there is no hermetic witness for that class

Both routes are closed. A witness reading src/v1/stage0/src to recover crate:: references declares ReadsLiveTree, and the floor's admission test declines those (DeclinedOutsideRequiredGate's sibling arm), so it would execute nowhere while being cited as coverage. Joining against a committed carrier instead needs the Rust module dependency graph, which gunbc.stage0_rust_product_reachability declares unmodeled in its own words — rust_module_dependency_graph_unresolved_edge, "Rust module dependency graph not modeled — cannot walk from cargo bin roots to dependent source files" — with every non-root path refusing on exactly that edge.

Next-rung trigger, recorded and not built here: the Rust module dependency graph modeled as a committed carrier. The crate:: closure then becomes decidable without reading the tree, and the join can replace the build as the wall.

A totality join was drafted and rejected as a change detector: union of the six crate module lists == stage0_all_partitioned_modules is measure() == measure(), because stage0_all_partitioned_modules is the concat of those same six lists in the same file. Deleting a module from stage0_extdeps_language_modules changes both sides and stays green.

The witness, and exactly what it claims

v2.test.claim.stage0_partition_roster_layout_join_witness catches one class: a roster entry naming a stage0 file the crate-layout authority registers with has_pub_mod: false — the std_lens_verdict class. It is not evidence about the E0432 class, and its header says so.

It was RED on the required path before the regen — required-floor: FAIL v2.test.claim.stage0_partition_roster_layout_join_witness.w_live_partition_roster_declares_no_undeclared_module returned Bool(false) (run 33293054935) — and green after. An earlier revision sat at test.claim.*, which matches none of required_gate_prefixes, so the floor discovered it, classified it DeclinedOutsideRequiredGate and never ran it while it was red. The module path is part of the wall.

Its discriminating RED is a fixture, because once the phantom row is gone the live rosters and the seed-retained filename roster are disjoint, making the live assertion an empty-set claim whose condition is absent — green whether the detector works or not. §4b's rule for that shape is that a state unrepresentable in the accepted corpus may still be representable in a fixture, and the detector is a pure fold over rows. The fixture cites the real std_lens_verdict registration rather than an invented name, so it also reds if the layout authority ever grows a pub mod for that file.

witness_v1_infer_unit_members_holds was (unit.members |> count) == 9 and went stale the moment the roster gained a module. It is not retyped to 10: it is now an identity join between the declared roster and what came back through the assignment map and partition_fold, so it cannot be repaired by editing a number. Its blind spot — an error in the roster itself, where both sides move together — is stated in place. Sibling unit witnesses still carry count literals; converting them is a separate diff.

Cost

One remote dispatch, 15 cores, same target dir, in order:

measurement	seconds	rc
BINS_COLD — what the build lane compiles today	308	0
PARTITION_ADDED — the seven partition packages on top	47	0
BINS_WARM — control	236	0
PARTITION_WARM — control	0	0

+47 s on the build lane, and zero on the required check. The two required lanes run in parallel under an aggregate context, so the check's wall clock is max(build, floor), not the sum. Last run: build 11m12s, floor 15m09s; 11m12s + 47s = 11m59s, still under the floor lane. Free until the build lane grows past the floor by roughly three minutes.

⚠️ BINS_WARM is 236 s, not ~0 — a trap for the next author. Building the partition packages invalidates part of the v1-compiler bins build: the two invocations select different package sets, so cargo unifies shared dependency features differently and rebuilds them. PARTITION_WARM at 0 s shows the invalidation is one-directional. The emitted step is unaffected (bins first, partition second, paying the measured 47 s), and the floor lane is a separate job with its own target dir — but a step added after mine in that job would silently pay ~236 s, which the +47 s figure alone does not show.

rc=0 on PARTITION_ADDED is also the wall's positive control: the same command that produced the 13 errors now compiles green.

Regeneration receipt

Produced by the generators, not by hand, and tightly scoped:

• main_wet rewrote exactly two artifacts — the generated partition .dag and witnesses.yml. Nothing else in the corpus moved.
• --required-regen reported exactly one drifted mirror: gunbc_stage0_crate_partition_generated.rs.
• --emit-partition-crates rendered 14 and wrote 3: the std-core, extdeps-languages and v1-infer lib.rs — precisely the three crates the roster change touches.

Regen note for the next author: main_wet is OOM-killed on a BuildBuddy runner under the default budget (SIGKILL, rc=137), and it is silent through a cmd | grep | tail pipeline because the pipeline reports the last stage's status. /sys/fs/cgroup/memory.max and memory.high are unreadable on those runners, so memory_governor::read_host_budget_bytes falls through to MemAvailable — the host's memory, not the slot's — and caps at the 15 GiB declared slot line, which can still exceed the slot. Set GUNBC_MEMORY_BUDGET_BYTES explicitly (10 GiB here; peak RSS 7.7 GiB). Filed separately as a governor fail-open; not fixed here.