A plan's own scale receipt had rotted 83%, and regenerating it would have deleted 2198 characters of DESIGN.md

[gunbai-bot]

Two authority defects, found together because fixing the first surfaced the second.

1. The cli_run hollowing plan transcribed its own scale

gunbc.plans.cli_run_hollowing_plan §0 carried 26,773 lines / 976 fns, measured 2026-07-23. Live today: 48,979 / 1,545 — rotted ~83% while reading as current. That is precisely what DESIGN's 2026-08-24 ruling forbids (name the instrument, never transcribe its output), and a plan's own scale receipt is the worst place to break it: a reader sequencing Chunk F budgets against a file that no longer exists at that size.

The numbers are deleted, not updated — updating buys one correct reading and the same rot. §0 now names the instrument and keeps only the durable fact, which needs no magnitude: the file has grown at every measurement so far, because v1 lanes absorb host bridges faster than v2 lanes subsume them.

Five rows named mechanisms that no longer exist, which is premise contamination rather than staleness — a reader plans real work against them:

Row named	Reality
gunbc.ci_floor_plan	deleted by the 2026-08-15 floor cut
src/v2/workflow/ci_floor_plan.dag	deleted by the same cut
regen_stage0	deleted at the root by the regen cut

The floor row is the one that mattered: it named claim_executor as the authority cli_run's floor runtime dissolves onto. That inverts the current direction — claim_executor is what this lane is deleting — so the row pointed backwards into a dying carrier. Each is re-pointed at its live successor with a note saying what died, so the correction cannot be mistaken for original text.

2. DESIGN.md carried 2,198 characters that no authority held

Regenerating deleted the clause landed 2026-08-26 — "AND THE TRIGGER MUST NAME THE CAPABILITY, NOT AN ARTIFACT THAT WOULD CONTRIBUTE TO ONE" — because it was authored into the generated artifact instead of gunbc.design_document.

It is rehomed into the authority at its original position, between the §4b(3) declared-drop sentence and meta-obligation (4). DESIGN.md regenerates byte-identical to main — nothing in the artifact changes; what changes is that the clause now has a home that reproduces it.

This is the second orphaned-prose incident in one evening (the first was 1,733 characters of the recurring-failure-modes dichotomy paragraph). Both were caught only by diffing regen output against main rather than trusting a clean exit, and the drift gate that would catch them is itself on the floor cut's unguarded list. There is an irony worth naming: the clause nearly lost is about declared drops being retired only by triggers that name the real capability, and it was unprotected because the mechanism protecting it is a declared drop with no re-add.

Separate subject, declared rather than hidden

The same regeneration converges three pre-existing drifts on main: .gitattributes gains the merge-driver bindings for two doc projections plus !merge for target_invocation_host.rs; two projections main lacks entirely are written; host-effect-orchestration.md gains a RunnerLocalHost variant. These are authority-ahead-of-artifact on main, not introduced here. Verified no prose is lost in any of them.

Verification

• DESIGN.md byte-identical to main after the rehoming
• Regeneration idempotent — a second run produces no further diff
• The 83% figure is stated as a measurement at this commit, not a standing fact; the instrument named in §0 re-derives it

— sent from merry-bear-547

[gunbai-bot]

Finding confirmed, and it is worse than a duplicate — it is a compiler defect producing silently wrong generated output. The two files are removed from this PR. (review 56457)

Verification

sed -n '2,114p' import-namespace-program.md | md5sum  ->  96b5cceeb1f3795236f779f810e4527d
sed -n '2,114p' v2-corpus-self-host.md      | md5sum  ->  96b5cceeb1f3795236f779f810e4527d

Byte-identical bodies; only line 1 (title) and line 115 (dissolution trigger) differ. Exactly as reported.

But the authority is correct — so this is not an authoring duplicate

dag/gunbc/plans/import_namespace_program.dag section_1 reads:

1. The end state — "The import concept does not exist." Not narrowed, not simplified — absent.

That is a genuine, correct import/namespace program. The projection instead contains v2_corpus_self_host's section_1:

1. The goal, and what it buys — "v2 compiles the entire v2 corpus, and the emitted Rust builds."

So nobody copy-pasted a body. The generator resolved section_1 to the wrong module's function. Both authorities landed in the same commit (#9352, 1e8e94ba11d), both define module-scope status_block / section_1 … section_9, and one module's definitions won globally for both projections. The per-module Plan record fields — title and dissolution trigger — are uniquely named, which is precisely why those two lines are the only ones that survived correctly. That pattern is the signature of the defect, not a coincidence.

This is the name-resolution hole DESIGN §4b already documents as an open structural gap — "a census-AMBIGUOUS type name resolves by silent last-import-wins instead of refusing" — here firing on function names, and its output is not a refusal but a plausible-looking document with the wrong contents. That is the fabricated-plausible-output failure (§5) in the generated-artifact path.

What I changed

Both files are removed from this PR. They are produced by the regeneration, so declining to land them leaves the tree un-converged — and that is the correct state: converging it would mean committing bytes I have now measured to be wrong. Landing a known-corrupt authority projection because "regen produced it" is exactly the reasoning this repo's generated-artifact discipline exists to refuse.

The .gitattributes merge-driver rows for those two paths stay, because that file is itself generated and regeneration re-adds them. They are inert while the paths are absent.

On your second finding

import-namespace-program.md:115 naming current_landing_order "step 5" with no such symbol in the file is a true observation about a false artifact. The line-115 trigger is the one part of that file that came from its own authority, and its referent lives in the authority module, not in the projection body — which is only visible because the surrounding 113 lines are the wrong document. I have not repaired it here: with the body corrupted, the resolvable-trigger question cannot be answered against this artifact at all. It should be re-checked once the projection is correct.

Not claimed

I have not fixed the resolver defect, and I am not filing this as done. What this PR now contains is unchanged from its stated subject — the stale receipt, the five dead-mechanism rows, and the DESIGN.md rehoming — minus two files that should never have been swept in with them. The defect is on main since #9352 and needs its own lane; I will raise it separately rather than widen a planning PR into a compiler fix.

Thank you for catching it. I swept those two files in as "pre-existing drift the same command produces" and did not read their contents.

— sent from merry-bear-547