Prose authored into the generated artifact is deleted by the next correct regeneration

[gunbai-bot]

DESIGN.md on main carries 1,295 bytes that no .dag authority produces. They were authored straight into the generated file:

• The emit-stage blocking population is countable and still unbounded: a census whose count cannot travel without its exit status #9418 (08d3c7aff81) — the bound-shaped closure failure-mode entry, and two fragments of the emit-stage census receipt
• The GitHub ruleset stops being a web setting and becomes a converged .dag authority #9404 (efc092566d9) — the THAT BOUNDARY MOVED repo_ruleset clause

So any correct regeneration deletes them. #9427 regenerated DESIGN.md during a conflict resolution and lost them — that run was correct, and the loss was already sitting on main. This is the third orphaned-prose incident in this session; the generated artifact is writable, so prose lands there rather than in the authority and survives only until someone regenerates.

Repair

Rehomed each passage into the authority that owns it, then regenerated:

passage	authority
bound-shaped closure	gunbc.recurring_failure_mode — ordinary roster row between positional_citation and authority_substitution
THAT BOUNDARY MOVED (line 147)	gunbc.design_document
emit-stage census receipt (line 151)	gunbc.design_document

Lines 147 and 151 now come back byte-identical to what main had committed.

Drift in the other direction — the more useful finding

Regenerating showed the authorities already carried content the generated files did not:

• diagnostic_name_mechanism_silent (3,445 chars) had never reached DESIGN.md
• three docs/plans/ files stale against their authorities
• two never committed at all

Both directions are the same missing wall: GeneratedArtifactDriftGate exists and is dispatchable from tools.ci_gates, but has no production caller, so nothing compares the generated tree against what the authorities produce.

Evidence

• zero tokens lost from DESIGN.md; the line-140 diff against main is one insert with zero deletions
• the three token differences in two plan docs are authority rewrites main had not regenerated, not drops
• regenerated with a binary built from this commit's tree — v1_compiler_infer* had changed since my previous build, so an older binary would not have been trustworthy

What is not claimed

This does not re-enroll the drift gate. That is a separate change under its own operator agreement. Until it lands the class sits at review diligence, and a fourth incident is writable today exactly as the first three were.

[gunbai-bot]

Verified and fixed in dd04d3d — review 56662 is correct.

docs/plans/import-namespace-program.md did carry the v2-corpus-self-host body under its own title. Measured at identity grain rather than by eye:

• the gunbc.plans.import_namespace_program authority's own section_3 text (3. The landing order, and why grammar is last) appears 0 times in its rendered output
• gunbc.plans.v2_corpus_self_host's section_3 appears in both files

Cause — not this change, and not the authority

Both plan modules declare the same ten bare module-scope names (status_block, section_1…section_9). The resolver collapses same-named module-scope fns into one global slot, so import_namespace_program_body() calls section_N and reaches the other module's definitions. The authority is correct and complete; the renderer cannot reach it.

That is exactly the defect #9393 repairs, and it is open. Until it lands, regenerating this path cannot produce a correct artifact.

What I did

Removed the file rather than landing known-corrupt bytes — the same call as review 56457 on #9392, where sweeping unread projections into an unrelated repair was the error.

docs/plans/v2-corpus-self-host.md is kept, and the distinction is measured, not assumed: its rendered body contains its own authority's section_3, so it is the module the collapsed slot resolves to and its output is correct. Dropping it too would delete a correct artifact for the sake of looking consistent.

Stated gap

This leaves the tree not fully derived on one path. After #9393 lands, regenerating produces the correct import-namespace-program.md and it should be committed then. I have not silently deferred that — it is why the removal commit names #9393 as the blocker.

The core repair in this PR is unaffected: the 1,295 bytes of orphaned DESIGN.md prose are still rehomed into their authorities, with zero tokens lost and zero deletions against main.

— sent from merry-bear-547

[gunbai-bot]

Merged main (b5af75f4d) — conflict resolved in 4ad61976924. Worth reading before merging, because the conflict contained a second instance of the defect this PR repairs.

#9405 rewrote the same two gunbc.design_document rows this branch was rehoming prose into. Main's DESIGN.md no longer contains the orphaned passages either: #9418 landed its emit-census result into the generated file only, never the authority; #9405 then edited the authority and regenerated, and the orphan was deleted as a side effect. Same mechanism, caught a second time on the same file while repairing the first.

Neither side was taken whole.

row	resolution
CI bullet	main's newer text is the base (it adds the emitted-closure cargo phase and the partition-crate boundary); the lost repo_ruleset clause is re-inserted between two anchors present verbatim on both sides, so the splice is positional, not editorial
emit-stage bullet	main's newer text is the base (it adds the NARROWED RATHER THAN RETIRED narrowing); its POPULATION: UNCOUNTED AND UNBOUNDED clause is replaced

That replacement is the one editorial call, and it is evidence-backed rather than a preference. gunbc.emit_stage_blocking_population_census exists on main carrying census_run_invocation, and #9418 landed before #9405 — so a census was taken while the authority still said it had not been. The clause was stale, not merely older. Main's own new fact (two specimens escaping by three distinct modes) is preserved beside the census result.

DESIGN.md is regenerated from the merged authority, never hand-merged — and the generator was rebuilt from the composed tree first, because #9416 changed lambda type-variable binding in the compiler and regenerating with the old binary would not have been the generator that executes here.

Evidence

• zero tokens lost against this branch's pre-merge DESIGN.md
• three lost against main — UNBOUNDED., bound., recording. — all punctuation-attached remnants of the two sentences deliberately rewritten above, with no content behind them

The two-sided check is what made this trustworthy: my first resolution passed against main and had silently dropped a whole sentence from my own side (the src/v2-as-primary measurement). A one-parent check would have shipped that.

— sent from merry-bear-547

[gunbai-bot]

Fixed in 9d4a0c8 — review 56834 is correct and this was my defect, not a disagreement.

The merge commit 4ad61976924 regenerated every artifact via main_wet, which writes all 72 committed artifacts unconditionally. That silently reverted dd04d3d01's deliberate deletion of docs/plans/import-namespace-program.md.

Re-verified at identity grain rather than assumed:

• v2_corpus_self_host's section_3 text in the file: 1
• import_namespace_program's own section_3 text: 0

Same corruption, same cause — the bare-name collision #9393 repairs.

What I got wrong, since the mechanism will repeat for anyone else

I treated regeneration as safe because it is derived. But a derived operation cannot know that one of its outputs is deliberately uncommitted — main_wet has no notion of an artifact under repair. So this deletion is not durable across a regeneration and must be re-applied after every one until #9393 lands. That is a property of the interim state, not a defect in the gate.

It also sharpens why #9393 is worth merging ahead of this: while it sits open, every regeneration on any branch re-adds a document that presents one plan's content under another's authority, and nothing in the tree reports it.

docs/plans/v2-corpus-self-host.md stays, on the same measurement that removed its sibling: its rendered body contains its own authority's section_3, so it is the module the collapsed slot resolves to and its output is correct. Dropping a correct artifact for symmetry would remove real content.

— sent from merry-bear-547

[gunbai-bot]

CI is red here on two breaks inherited from main, neither of which this PR touches. No fix can be pushed to this branch, because nothing on this branch causes either one.

dag/gunbc/fleet_fan_wiring_witness.dag:754  duplicate declaration 'srv3_wiring_with_a_duplicated_header'
dag/product/fabric/contention.dag:23        name 'grant_duration_seconds' not found in module 'product.fabric.supply'
dag/product/fabric/contention.dag:280       non-exhaustive match: missing variant(s) UnobservedGrantDuration
dag/product/fabric/contention.dag:421       non-exhaustive match: missing variant(s) QuoteNotPriceableWithoutDuration
dag/product/fabric/contention.dag:463,469   function 'grant_duration_seconds' not found in scope

Verified against main, not inferred from the log

• dag/product/fabric/supply.dag on main contains grant_duration_seconds only inside a // comment ("It was called grant_duration_seconds and returned a bare…"), removed as a declaration in b20ac7ad44f; contention.dag line 23 still imports it
• fleet_fan_wiring_witness.dag on main declares srv3_wiring_with_a_duplicated_header twice (lines 447 and 754), both blocks byte-identical
• compiling dag/product/fabric/contention.dag directly from main's content reproduces 5 blocking errors

The required floor resolves the whole corpus, so either error refuses the phase for every open PR regardless of its diff. That is why this shows up here.

Both are being fixed elsewhere

• The unobserved-duration trigger fires: contention refuses to rank rather than substituting a worst case #9488 (already open) removes contention's reference — verified 0 remaining on its head
• One data declaration authored twice: main's floor lane is red for every PR #9500 (opened just now) removes the duplicate declaration — The unobserved-duration trigger fires: contention refuses to rank rather than substituting a worst case #9488 does not touch that file, so main stays red after it merges; both are needed

This PR needs no change. It will go green on a re-run once those land. I am deliberately not pushing anything here: a no-op commit to trigger CI would cancel the running cycle and produce a second ~35-minute failure on the same inherited break.

— sent from merry-bear-547

[gunbai-bot]

Do not merge this before #9393, and do not read a green CI here as evidence that the artifact population is consistent.

I merged current main (dc76571d90f) into this branch to pick up #9488's repair, since the previous red was inherited — the parse phase refused on dag/product/fabric/contention.dag:23:19 importing grant_duration_seconds, which is main's break and not this diff.

Worth recording, because it cost an hour and I nearly reasoned the other way: a re-run does not pick up a base repair. gh run rerun --failed replays the run's original merge ref. Main was repaired at 19:25:43 UTC; the rerun started 19:34 UTC and refused with the byte-identical diagnostic for a symbol that had already been restored. A new SHA was the only route to an honest green.

The blocking dependency

Running the drift gate locally against this tree refuses:

generated-artifact drift/validation failed: docs/plans/import-namespace-program.md

That is correct behaviour and it is not fixable from this branch. Two authorities genuinely conflict here:

• reviews 56662 and 56834 required this file be deleted — it is emitted carrying v2-corpus-self-host's entire body, so committing it commits corrupt generated content;
• the drift gate requires every expected artifact be present and match its authority.

Both are right. The file cannot be correctly present until the bare-name collision that corrupts it is repaired, which is exactly what #9393 does — its title names this file. So the ordering is a real dependency, not sequencing etiquette:

1. merge A module must reach its own declaration: same-named module-scope fns collapsed into one global bare slot #9393
2. merge main into this branch, regenerate, commit the now-correct import-namespace-program.md
3. then this is gate-clean and mergeable

Why the CI signal cannot be trusted for this

witnesses.yml contains zero references to the generated-artifact gate — it is on DESIGN's unguarded list following the 2026-08-15 floor cut. So a green here means the parse phase and the witness floor passed. It does not mean the artifact population is whole, and on this tree it demonstrably is not. That gap is the reason I am writing this down rather than relying on the checks.

Approvals on this PR were dismissed by the new head. I am not requesting re-review until step 2 above is done, since the tree will change again.

— sent from merry-bear-547

[gunbai-bot]

Fixed in 5b7a1ca4bd. Review 57000 is correct on every point and I've deleted both files rather than regenerating them.

Verified before acting, since the finding contradicted what I'd built:

• dag/gunbc/plans/import_namespace_program.dag and dag/gunbc/plans/v2_corpus_self_host.dag both declare projection: PlanIsAuthorityOnly
• neither markdown exists on main
• this PR was adding both

The timing is the whole explanation, and it clears the regenerator:

when	what
22:23:43Z	I regenerate — the carrier said emit, and main_wet correctly wrote the file
22:46:26Z	#9415 lands PlanIsAuthorityOnly for both carriers, in the same change that enrols the generated-artifact phase
later	I merge main. The post-merge regeneration correctly writes neither file — main_wet honours the ruling — but my git add -A preserved the leftovers from the pre-ruling pass

So this is not a main_wet defect and nothing about the regenerator needs changing. The work was right when done, and the base moved under it — the same shape as #9500 earlier today, where an approved diff turned destructive without a byte changing on its branch.

The part I want to own rather than explain away. DESIGN's generated-artifact adjudication says: before a new adjudicator's first red is closed by producing the thing it says is missing, establish that the thing was ever supposed to exist. The gate's red here was absent, not drifted, and I closed it by producing the file — precisely the move that paragraph forbids. I merged that sentence into DESIGN.md myself a few hours ago while resolving the CI-row conflict, quoted it in the merge commit, and did not apply it to my own diff.

One correction to something I said earlier on this PR: I wrote that a green here could not establish artifact consistency because witnesses.yml carried no reference to the generated-artifact gate. That was true when measured and is now superseded — #9415's sixth phase adjudicates exactly this, and it is what would have caught these two files.

After deletion: drift gate exits 0 with 0 refusals, and the diff no longer adds either path.

— sent from merry-bear-547