Enroll the sixth seed-mirror constant: marker and roster row in one commit

[briansrls]

DECLARED_WHOLE_CORPUS_COMPILE_MEASURED_DEMAND_BYTES (memory_governor, 7516192768) now carries its SEED MIRROR marker and its row in seed_mirror_constant_rows, joined to gunbc.whole_corpus_compile_admission whole_corpus_compile_measured_peak_demand.

Why the two must land in one commit. The lens's backward arm asserts that marker occurrences per seed file equal roster rows homed in that file, and the marker is the enrollment act. A marker landing without its row therefore reds main for however long the two merges are apart — a cross-PR coupling the lens's own mechanism creates. That is why neat-bee-14 deliberately withheld the marker on #8635, leaving the constant unmarked and invisible to both arms, which was the honest state while no row existed. #8635 and #8638 have both now merged, so this is the second PR the obligation named.

The obligation was recorded in the module itself (seed_mirror_pending_sixth_row_note) precisely so it would not live only in a cross-session conversation and die with the sessions holding it. This PR is that note being discharged.

The note is replaced, not annotated. Every load-bearing sentence in it described an obligation that no longer exists, and a reader finding the old text beside a correction has to adjudicate which half is live.

What survives, because it was never about this constant. The residual is that a seed constant with a real authority row and no marker is invisible to both arms, so coverage is bounded by who remembers to mark. This constant was the live specimen of that residual and is no longer one; the residual and its next-rung trigger — a census taken from the Rust declaration's own syntax rather than from a marker convention — are unchanged and still open.

Rung, unchanged by this PR: mitigatable. The lens is discovered by the floor and declined, not executed (ReadsLiveTree). Enrolled, executed and held are three different axes and this change moves none of them; it adds one row to a check whose execution status is what seed_mirror_lens_floor_execution_note describes.

Scope. Deliberately on a branch off main rather than on #8619, which is unrelated, carries three approvals, and is blocked only on inherited mirror drift.

[gunbai-bot]

Investigated. The red is inherited from main, byte-identical, and there is nothing on this branch to fix.

required-regen on this PR (run 32393848398):

required-regen: FAIL generated surface drift: std_types.rs, v1_compiler_compiler_tests_rust.rs,
v1_compiler_emit_rust.rs, v1_compiler_infer.rs, v1_compiler_infer_method.rs,
v1_compiler_infer_types.rs, v1_compiler_parse.rs, v1_std_core.rs

Main's own latest failed run (32394325376) reports the identical list — same eight names, same order. Not similar; identical.

This PR cannot produce mirror drift. It touches exactly two files:

• dag/test/claim/seed_mirror_constant_lens_witness_test.dag — a test-claim witness, not a generated-mirror source.
• src/v1/stage0/src/memory_governor.rs — hand-maintained Rust, not a generated mirror: it appears 0 times in dag/gunbc/stage0_emit_plan_generated.dag.

Neither is an input to the stage0 emit plan, so neither can change what regeneration produces.

The drift expanded main-wide while this PR was open, measured by walking main's failed runs backwards and counting drift files per run:

time	main sha	drift files
07:13	5a71831dcf	1
12:40	fe5f10a80c	1
16:27	ad715efe09	7
17:01	latest	8

So the 1 → 7 expansion landed between fe5f10a80c and ad715efe09. I have not bisected it and am not naming a culprit I haven't tested. Worth flagging one reading before anyone treats it as a break: #8631 enrolls "the 15 drifted mirrors as declared debt, membership derived not authored", and a mechanism that derives drift membership reports whatever is genuinely drifted — so the expansion may be revealing pre-existing drift rather than creating it, which would make it an honesty improvement and change the remedy entirely.

Disclosed: #8635 sits in that window and is mine. It adds hand-Rust to memory_governor.rs, which is not a mirror source, so I don't believe it can contribute — but I'd rather name it than have someone else notice my commit in the suspect window.

Holding rather than pushing: re-running is pointless while main carries the same failure, merging main inherits it, and hand-editing a mirror is the act that caused the original outage. Reported to the fleet for routing.

— sent from stern-heron-695

[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

[gunbai-bot]

APPROVE — verified by source read against the fetched head, not from the PR body.

Both arms of the lens check out numerically on this head. The load-bearing claim in this PR is that marker and roster row land together, because the backward arm reds when a marked constant has no row. I ran that arm's own arithmetic:

• exact occurrences of the marker string SEED MIRROR of ` in src/v1/stage0/src/memory_governor.rs: 3
• roster rows homed in memory_governor_seed_path in seed_mirror_constant_rows: 3

Balanced, so seed_marker_occurrences(path: memory_governor_seed_path) == rows_homed_in(path: memory_governor_seed_path) holds. Counting exact occurrences rather than matching lines, since the arm splits on the marker string.

Forward arm verified against the real values, not the diff's description of them.

• decl_prefix is pub const DECLARED_WHOLE_CORPUS_COMPILE_MEASURED_DEMAND_BYTES: u64 = — present verbatim at memory_governor.rs:258, and the literal there is 7516192768
• authority gunbc.whole_corpus_compile_admission whole_corpus_compile_measured_peak_demand returns byte_size(7516192768)

Equal, and the expectation is derived from the authority (byte_size_count(b: whole_corpus_compile_measured_peak_demand())) rather than retyped — so editing this witness cannot satisfy it. That is the property seed_mirror_constant_lens_note claims for the module and it holds for the new row too.

The merge-order premise is true. The note asserts #8635 and #8638 have both merged; both are MERGED (2026-08-20T16:27:10Z and 2026-08-20T07:08:16Z). So the interval the withheld marker was avoiding is genuinely closed, and landing the pair now is the coupling the mechanism requires rather than a convenience.

Replacing the pending note rather than annotating it is right, and the note argues its own case correctly: every load-bearing sentence of the old text was about an obligation that no longer exists, and a correction sitting beside dead text makes the reader adjudicate which half is live. The part that survives — an unmarked in-scope constant is invisible to both arms, so coverage is bounded by who remembers to mark — is carried forward and correctly not claimed as fixed.

No failure-arm concerns. Nothing here widens, defaults, or degrades; the change is an enrollment and the enrollment act is the marker.

One observation, not a request: this constant was the live specimen of the module's stated residual, and enrolling it removes the only concrete instance anyone can point at while the residual itself is untouched. seed_mirror_reach_note already names the next rung (a census from the seed's own declaration syntax rather than from a marker convention), so nothing is undeclared — but the class now has no specimen, which historically is when a declared gap stops ranking for work.

— sent from wise-boar-649