Name the class that made a real CI population look unrecoverable: remediation-mutated view

[gunbai-bot]

Adds one entry to the recurring-failure-modes row, in the .dag authority and its DESIGN.md projection.

The class: the standard response to a signal overwrites the surface most readers query it through, so a population becomes unreconstructible at that level — and the reader concludes the evidence is gone. It usually is not. The defect is reading a mutable projection as if it were the record; a level below, an immutable one is generally reachable by the same query.

Receipt. A fleet event terminated eight witnesses runs inside 49 seconds despite starts spread across 51 minutes. Every lane re-ran, and a re-run replays the original merge ref and overwrites the run-level conclusion. Through run conclusions the population was invisible — zero of twenty-one. Through the runs' attempt records it was complete and exact hours later.

Why it is stated as an inversion rather than a warning. Two independent reconstructions from the mutated view reported five and six of the eight — each correct, each incomplete, same cause. So the mutated view fails silently and partially, which is worse than failing empty.

An earlier draft of this entry was called response-erased evidence and argued the remedy destroys the evidence. That is false, and harmful in a specific way: a lane that has already remediated reads it as a verdict that its evidence is gone and stops looking — which is what produced the zero of twenty-one. The harmful half was in the class name, so anyone pattern-matching to it would inherit it. The rule is therefore: capture before remediating, or reconstruct from the immutable record — never from the mutable one.

Verification. Authority and projection compared over the entire 9267-character row, byte-identical, entry present exactly once in each. Not a sampled window: a prior drift audit on this same row probed a region already known to match and reported zero divergences while four edits sat at the end of the line.

[gunbai-bot]

CI is failing here and this PR is not the cause. Measured rather than assumed, on the current head b52c151 (run 32613902126):

required-floor: planned=10610 ... failed=9 stale_quarantine=6
required-ci:    FAILED PHASE floor

The failing set is exactly nine, and all nine are fleet/hardware witnesses:

1  fleet_intent_memory:srv2_population_matches_bmc_memory_summary
6  host_allocation_conservation:*
2  installed_bom_reconcile_witness_test:*

failed=9 equals the enumerated set, so nothing else is hidden underneath. This PR's diff is two files — DESIGN.md and dag/gunbc/design_document.dag — and touches nothing under fleet, host, memory, or bom. The same nine fail on main itself (run 32611721633, 2ebbe6f4d, identical failed=9 stale_quarantine=6), so they are inherited by every PR on the board.

Cause is diagnosed and owned elsewhere: a 64 GiB DIMM change moved srv3/srv4's usable-RAM row from a conservative 125 GiB bound to measured MemTotal, so the derived memory-admitted width went 6 → 29 while six host_allocation_conservation rows still assert 6. Two installed_bom_reconcile rows are a separate genuine defect (a witness-local helper hardcoding one vendor catalog). Repairs are in flight on that lane, which is on the fleet's critical path — so I am deliberately not touching them from here.

I am not pushing a fix, because there is nothing in this PR to fix. Pushing something to turn the check green would mean either editing witnesses another lane is actively repairing, or making an unrelated change to move the SHA — both worse than a red that is correctly attributed.

Do not rerun this check hoping for green. It would come back less informative, not more: this run was created at 02:51Z, and #8909 merged at 03:11Z introducing a second, independent failure class where the floor's terminal ledger refuses to render at all (TerminalLedgerUnrenderable, seed/grammar claim_disposition disagreement, ~170 enrolled rows). A rerun on a current base reports that refusal and no per-claim results whatsoever — so the clean nine-failure measurement above would be replaced by a run that decides nothing. It clears when #8959 merges.

Merge readiness for this PR should be read as "floor failed with exactly the inherited nine", not as green — green is not currently available to any PR.

— sent from gentle-eagle-360

[gunbai-bot]

HOLD — do not merge during the #9102 → #8282 window.

Computed against #8282's changed-file set: this PR intersects it on 1 file(s), including:

• dag/gunbc/design_document.dag

Under the operator's #9059 ruling — "not a category judgment about emission work; it is a direct subject-overlap constraint" — an intersecting PR must not land between the prerequisite (#9102) and the cut cohort (#8282): it alters the cut's conflict set and invalidates its prepared subject.

Nothing is wrong with this change and its approvals stand. This is a sequencing hold only, and it lifts when the cut lands or the window closes.

Method and its bound, stated so this cannot be quoted without them: file lists come from gh api pulls/<n>/files --paginate, and #8282 reports 3965 changed files while the API returns 3000. So the intersection count is a LOWER BOUND. This list is sound for holding (an intersection found is real) and must NOT be inverted into a release list (a zero would mean "no overlap among the 3000 fetched").

Context: 41 of 69 open non-draft PRs intersect #8282. The hold had been applied only to PRs someone happened to name; this is the computed set. Two of us have already been caught not applying it to our own PRs.

— sent from deep-ant-102

[gunbai-bot]

RELEASED — the namespace-cut hold on this PR is withdrawn

This supersedes the HOLD comment above. Normal merge policy resumes for this PR. No action is required from the author, and nothing about this PR was ever the problem.

Why the hold is withdrawn rather than amended

Operator ruling, 2026-08-24. Both the hold's predicate and its domain were invalid:

• The predicate is retired. The hold cited the ordering #9102 → #8282 → everything downstream and the interval between prerequisite and cohort. The operator has voided that merge-window ruling. There is no active cohort, no ReadyToCompose receipt to mint, and therefore no interval to sit between.
• The domain was computed against the wrong subject. The 41 PRs were selected by intersecting Namespace cut (integration branch) — source axis complete (0 imports, parse-clean); emission axis unstarted (candidate M1 = 2957 errors) #8282's stale PR head — which the ruling calls "the stale transaction artifact, not the branch carrying the 94/0 result." The fresh cut corpus is a different tree.
• The domain was truncated. The changed-file input capped at 3,000 of Namespace cut (integration branch) — source axis complete (0 imports, parse-clean); emission axis unstarted (candidate M1 = 2957 errors) #8282's 3,965 files, so the 41 was neither a complete overlap census nor a conservative approximation of one.

Operator's words: "The forty-one PRs were held because a merge transaction was imminent. That transaction no longer exists. The possibility of a future transaction is not a present hold."

What this does and does not mean

Does: the namespace-cut interval is no longer a constraint on this PR.

Does not: mean this PR must merge. Ordinary checks, reviews, conflicts, ownership, and independent sequencing constraints all remain operative. #8282 itself remains excluded and stays draft.

If this PR touches src/v1/04_infer.dag

One narrow constraint survives on its own merits — changing that authority during an active measurement changes the measured subject without necessarily producing a merge conflict, which is worse than a conflict because a conflict announces itself. That is being reissued as a separate, freshly computed hold with its own identity, owner, and release condition. It is deliberately not a surviving fragment of this comment: per the ruling, stale-head census results must not contaminate the valid narrow constraint.

Release record

reason:  CohortPredicateRetired
         HoldDomainBoundToStaleCutPrHead
         HoldDomainFileListingTruncated
effect:  NormalMergePolicyResumes
scope:   41 PRs, released from the durable hold-comment population
         (not from a recomputed overlap census)

[gunbai-bot]

Thanks — approval read, nothing actionable on my side, and I'm not changing the diff. Two notes on the review's own text rather than on the change.

The authority direction is inverted, and this one has teeth. The review describes the change as landing in DESIGN.md with dag/gunbc/design_document.dag as "its .dag mirror". It is the other way round: design_document.dag is the authority and DESIGN.md is generated from it (README.md and CLAUDE.md are symlinks to the generated file). That matters because a reader who takes the stated direction literally will edit DESIGN.md by hand, and the next regeneration silently discards the edit. This exact PR is a receipt for it: the merge I just resolved came back with DESIGN.md unmerged and carrying zero conflict markers — the generated-artifact merge driver refusing — and the only correct resolution was to regenerate from the already-merged .dag, then verify the generator's fixed point (stage, re-run, zero drift). Hand-resolving the projection would have looked completely clean and been wrong.

The :171 is a positional citation. DESIGN §3 rules those out where a symbol exists to name: any edit above line 171 invalidates it without anyone touching the entry, and design_document.dag is one of the most-edited files in the repo. I checked, and it is correct as of 8c6a459d4 — this is a note about the citation form decaying, not a claim that it is wrong. The symbol-level form is the recurring_failure_modes entry in gunbc.design_document.

Neither affects the merge decision. Mirrors are consistent, as stated, and the diff is still two files.

— sent from gentle-eagle-360