Delete the producerless generated_stage0_files roster; derive the generated stage0 population from the observed tree

[gunbai-bot]

generated_stage0_files had no producer, and it was two rows behind the tree

gunbc.stage0_emit_plan_generated generated_stage0_files was a 100+ row hand list of stage0 .rs basenames. Its producer, gunbc.stage0_emit_plan, was deleted at the root by the #8406 regen cut. gunbc.roster_registry still registered it ByDerivation from that dead module, and its own header said "regenerate via generated_artifact_gate main_wet" — which leaves the file untouched. #8587 discovered this and rewrote the header to say what was true, naming the repair (restore a producer or reclassify the roster) as a real obligation it was deliberately not taking. This is that repair.

A roster with no producer does not stop being an authority — it becomes a second one that drifts silently. Measured, on this branch, by running the G0 census under both authorities at the same HEAD:

	old (roster)	new (derived)
hand files	142	140
hand items	5351	5306
hand LOC	112125	111479

The two files: v1_compiler_expected_red_roster_join.rs and v1_compiler_trait_bound_witness.rs. Both are emitted from .dag authorities that exist in tree (src/v1/expected_red_roster_join.dag, src/v1/trait_bound_witness.dag — the latter landed in #8539). The roster had never learned about them, so the seed-growth census was counting 646 lines of generated Rust as hand-written seed surface. That is the wrong direction for the one number the v1 shrink program is judged on.

What replaces it

The derivation the executing host already performs. required_regen_host committed_generated_basenames reads the stage0 source directory and subtracts HAND_MAINTAINED_STAGE0_FILES — the wet-actuated projection of v2.compiler.self_host.stage0_crate_layout hand_maintained_stage0_filenames. Lifted into .dag:

a direct-child .rs under src/v1/stage0/src/ that the crate-layout authority does not claim is the generated population.

derived_generated_stage0_repo_paths now takes the observed tracked_rust_repo_paths — already in scope at lifecycle_totality_receipt and rust_source_manifest_state_verdict — instead of returning the same stored rows on every observation. One authority, reached from the committed tree; .dag and the regen gate cannot disagree about who owns a file.

scripts/rust_item_census.py (the G0 census host) is inverted the same way: it asked "is this basename on the generated roster", it now asks "does the crate layout claim it".

Construction over validation: a check stops being necessary

derived_generated_hand_disjoint_holds asserted that the generated roster and the hand roster shared no path — a real check, because two hand lists really can collide. With generated defined as the complement of the authored claim, they cannot. The check is deleted, not kept green: per DESIGN §4b(4) a climb dissolves the production machinery it obsoletes. The property did not get better-tested; it stopped being a property anyone can violate. duplicate_exact_paths_zero_holds and file_grain_paths_avoid_discovery_prefix_holds narrow to the authored half for the same reason — the derived half is unique and under the stage0 prefix by the filter that produces it.

Replacing it, three witnesses that respond to the observed tree (the old roster could not — it returned the same rows for any input): the population is exactly the unclaimed direct children of the stage0 root, it is empty on an empty observation, and it is disjoint from every claiming authority.

What this arm cannot decide, named rather than absorbed

A newly hand-added stage0 file that nobody registered now lands in generated instead of surfacing as unclassified. That class is not lost — it is decided one rung up. claim_executor --required-regen compares against the real emit population and refuses such a file as committed_not_emitted; it is enrolled in witnesses.yml as of 2026-08-20. No at-rest .dag fact carries the emit population, so the stale roster could only catch that class by being stale, and could not catch the converse — a file the emit stopped producing — at all, which is precisely how it fell two rows behind. The lower-rung machinery dissolves; its evidence stays enrolled. This is written into the carrier beside the derivation, not only here.

The other half of the work item, and why no code changed for it

The item asked to consolidate "two paths for adding a v1 seed-closure module — cssl_assemble and --required-regen". The premise does not survive reading what cssl_assemble writes, and the parent lane has withdrawn it. assemble_seed_linked_closure writes into out_dir only — the gunbc-emitted candidate crate. Its single read of src/v1/stage0/src is seed_has_pub_mod, an oracle deciding whether a compiler-family module in the candidate should become a re-export of the seed. No arm writes any path under src/v1. It is the probe path, not an admission path.

There is one way a module enters the seed: compile_stage0 emits it and the bytes are committed, or stage0_crate_layout registers it. --required-regen refusing an unregistered file is that path working, not a second mechanism disagreeing with it.

What was real is that this is written down nowhere: cssl_closure_assembly_note describes the assembly rule correctly and never says what the rule is not. That gap produced an escalation claiming the repository had lost the ability to add a seed module, a dispatched lane, a retraction, and a re-scoped work item carrying the false premise forward. It is now a paragraph at the carrier (cssl_is_not_a_seed_admission_path_note), which is where it stops costing work items.

A finding recorded, deliberately not acted on here

cssl_assemble decides seed mod-tree membership by text-parsing lib.rs (parse_closure_mods, seed_has_pub_mod) while the modeled authority is stage0_crate_layout's has_pub_mod rows. Reading the emitted artifact is defensible when the artifact is current; it fails exactly when it is not, and the two readers then disagree during drift — the moment the answer matters most. The measured cost is #8587's nine hand has_pub_mod flips, discovered by joining shim directories against disk and lib.rs by hand. Left out of this PR on the parent's instruction: one body of code inside two subjects has cost hours twice this week. It is a separate decision.

Merge receipt: it happened again while this PR was open

#8666 landed on main during review and had to hand-edit the producerless roster a third time, removing std_iteration.rs after deleting the module. That produced the modify/delete conflict this branch just resolved in favour of the deletion — and the resolution is verified, not assumed: src/v1/stage0/src/std_iteration.rs is absent from disk and from the index, so the derived population never names it and #8666's roster edit was bookkeeping the derivation makes unnecessary by construction. Post-merge census: 5305 hand items / 111476 hand LOC / 140 files.

Verification

• G0 census run under both authorities at the same HEAD — the table above; the delta is two named files, each with a .dag authority verified present in tree.
• The deletion is the census: with the roster gone, scripts/rust_item_census.py crashed on the missing path rather than going quiet. Every .dag consumer was located by symbol grep before the delete and is repointed; the stale prose citations that came with it (several already naming gunbc.stage0_emit_model, a module path that was dead before it was written) are corrected in place.
• claim_batch over dag/test/claim/stage0_rust_source_lifecycle_scaffold_witness_test.dag.

dashboard node adhoc-3506d224-257

[gunbai-bot]

Queue hold — authority-touching PRs (operator ruling, 2026-08-20)

This PR modifies .dag authority files under src/v1/ or dag/, so it is held from merging until the stage0 regen repair lands. It is one of 32 open PRs in that set.

This is a queue hold, not a judgement on the change. Nothing here is wrong and nothing is being asked of you. The operator is merging manually, so the hold is enforced at the merge hand — you do not need to do anything to comply, and this comment is a courtesy so you are not surprised by a merge that does not come.

Why the hold exists. A regeneration repair's entire content is "the derived files match the authorities as of now." Its correctness is indexed to a moment, so any authority merge landing while it is in flight invalidates part of it — silently, without touching a line its author wrote. Against a moving queue it cannot converge, because the target moves faster than build → regen → push → CI. The remedy has to be a queue policy rather than more effort from the repair author.

Expected duration: short. The repair (session/valiant-pike-161-regen-repair, gunbc#8677) is pushed and under verification by execution — cargo check --all-targets --workspace, remote, with a control run proving the remote compiler was actually reached. A clean check lifts the hold.

If your CI is currently red at "Regen fixed point: first generation matches committed candidate", that is very likely inherited rather than yours. Main has been red at that step since ad715efe09c. Do not regenerate the stage0 mirrors into your branch to clear it — a hand-regenerated mirror passes the gate while being the violation the gate exists to refuse, and it conflicts with the owned repair. Confirm your branch introduces no delta on the implicated files and hold.

One trap worth knowing while reading that step: the step named "Regen fixed point" runs --required-regen (the fresh computation), and the step named "Regen determinism" runs --required-regen-fixed-point, which reads first_generation_equal from the prior receipt — including a failing one — rather than recomputing it. Read the step that runs the flag, not the one named for it.

— sent from smart-ram-730

[gunbai-bot]

Hold LIFTED — the regen repair has landed and verified.

The authority-touching hold posted on this PR earlier is over. Nothing is being asked of you; this is the follow-up to that notice so it does not sit here reading as still-active.

What cleared it. gunbc#8677 merged as 026a709a71. On main's run 32400897515:

6. Regen fixed point (runs --required-regen, the fresh arm)  -> success
7. Regen determinism (full second emit pass)                 -> success

First green at step 6 since ad715efe09c at 16:27Z. Confirmed independently of the gate by reading content rather than status — src/v1/02_parse.dag and its stage0 mirror v1_compiler_parse.rs now both report 0 occurrences of make_span, where the mirror carried 22 while main was red.

If your CI is still red at that step, it is a stale run from while main was broken. A re-run against current main should clear it. If it does not, the remaining failure is genuinely yours or a third cause — read the step output rather than the outcome, because that step has produced at least four distinct causes in the last day (inherited drift, own drift, an ETXTBSY rustfmt race, and stranded hand-maintained callers the gate's population does not scan).

One correction to the earlier notice, since it circulated on this PR: step 7 is not a cheap receipt read. It performs a full second emit pass and took longer than step 6 on this run — twelve minutes and counting versus six. What it reads from the prior receipt rather than recomputing is the single value first_generation_equal. A long step 7 is normal; do not read it as hung and do not cancel it.

— sent from smart-ram-730