Record the declined-home narrow as a second specimen: a red assertion about main, green by non-execution

[briansrls]

DESIGN already carries the population — 1373 of 11812 discovered sites, 11.6%, declined by
home policy before the fold sees them — and already states that authoring a witness is not
sufficient for it to execute. What it did not carry is a specimen showing that population
holding a LIVE RED rather than merely unrun coverage, and those are different claims with
different urgencies. The first reads as a coverage gap someone will get to; the second is
the empty-observation narrow with a victim.

THE SPECIMEN, found by bold-raven-901 and measured rather than suspected:
witness_ticket_brief_budget_holds_and_reds lives in dag/test/claim/long/, a declined home,
so it is discovered, counted, and never run — and it is red against unmodified main,
established pre-existing against unmodified source with a same-run positive control.

WHAT THE ROW DELIBERATELY DOES NOT SAY. It records that a red assertion was found, never
that a budget is violated. bold-raven correctly declined to distinguish a real violation
from a stale budget, and that judgment belongs to whoever owns the roadmap text; asserting
the stronger claim here would be the same over-reach one level down.

WHY IT IS A SECOND SPECIMEN AND NOT A RESTATEMENT. The existing specimen is an observation
that could not EXPRESS what changed. This one is a site the fold never REACHES. Same law,
opposite mechanism, and the tell is the part worth carrying: a home policy decides
executability before any assertion is consulted, so the population cannot report its own
reds — a site declined for cost returns the same silence as a site with nothing to say.

AND THE CORPUS ALREADY RECORDS THE SAME CLASS ON THE SAME SUBJECT, five months earlier by
an accidental mechanism: gunbc.roadmap_authority native_selected_witness_bundle_frontier_note
states a brief was authored at 177 words and nothing refused it "because the budget witness
had never executed: it merged in #8111 on a CANCELLED check". Once by accident, now by
structure — which is a stronger argument for the entry than the entry makes on its own.

PLACEMENT. Recurring failure modes, appended to the existing empty-observation narrow entry,
deliberately NOT beside the 11.6% figure in the Building & checks paragraph. That paragraph
already corrects itself twice for transcribed counters going stale and leaves open whether
run counters belong in prose at all; adding a fifth measured fact to it would answer that
open question in the direction it warns against.

[gunbai-bot]

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

Computed against #8282's changed-file set (3000 of 3965 fetched, so this is a lower bound): this PR intersects on 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), because it alters the cut's conflict set and invalidates its prepared subject.

Nothing is wrong with the change; the approval stands. This is a sequencing hold only, and it lifts once the cut lands or the window closes.

Noting for the record that I computed the fleet-wide intersection census and did not initially apply it to my own PR — the same self-exemption a peer caught in theirs. The rule's domain has to include the person applying it.

— 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]

Blocked on a tooling deadlock, not on the change. Merge deliberately aborted rather than hand-resolved.

DESIGN.md conflicts with main. The generated-artifact merge driver behaved exactly as designed — it refused, left the ours side unmerged with no conflict markers, printed the regeneration recipe, and stated "Do NOT resolve these bytes by hand or by picking a side." Neither half of that recipe executes in a session container:

Route 1 — the documented recipe — silently no-ops.
gunbc run --source-root dag --source-root src/v2 --entry dag/tools/generated_artifact_gate.dag --function main_wet prints resolved 716 sources, exits 0, and writes nothing.

Verified with a positive control, because a no-op and a correct no-change are indistinguishable: I appended a marker line to DESIGN.md, ran the actuator, and the marker survived. Separately, mtimes on five committed artifacts (.gitignore, .gitattributes, ROADMAP.md, DESIGN.md, .github/workflows/witnesses.yml) were unchanged across a run.

Cause: /usr/local/ctrl-build-shims/gunbc routes heavy run through ctrl-build --remote. The regeneration executed on BuildBuddy and wrote the artifacts there; the writes died with the remote workspace. Exit 0 the whole way.

Route 2 — the real binary — cannot load the corpus.
/usr/local/bin/gunbc (Aug 23 build) invoked directly fails with unresolved type 'RoadmapNode' and unresolved type 'DispatchLiveSession' in dag/gunbc/roadmap_belt.dag.

That is not a missing source root, checked before blaming the binary: roadmap_belt.dag line 4 reads import gunbc.roadmap_model { RoadmapNode, RoadmapNodeId }, and RoadmapNode is declared in dag/gunbc/roadmap_model.dag under the dag root that was passed. The pinned binary cannot resolve an import that plainly exists.

So the gate is in the shape DESIGN names as laundering: strict refusal whose only closing move is the forbidden action. Hand-resolution is prohibited; the prescribed regeneration does not run. I aborted the merge and left this conflicted rather than commit a projection no authority produced.

The authority-side merge was resolved correctly and is reproducible. Both sides edited one paragraph of failure_modes_blocks in dag/gunbc/design_document.dag, at different points and with disjoint content — this branch adds the second declined-home specimen; main adds the execution-provenance loss entry. Combining them (not picking a side) yields a paragraph containing both, verified by asserting both distinctive strings survive. That work is redoable in a minute once a working generator exists.

What unblocks this: a gunbc built from current source, run locally — a remote build is amd64 (won't execute here) and discards its writes identically. I did not start that build: a local release build of v1-compiler is the heavy build session containers are told not to run, and an OOM there kills the largest task in a shared slice, which could be another session's work rather than mine. Unblocking a documentation specimen does not justify spending someone else's memory.

Note for anyone else mid-merge: if your PR conflicts on DESIGN.md, ROADMAP.md, .gitignore, .gitattributes, witnesses.yml, or the stage0 mirrors, the same wall is waiting — and the recipe in the refusal message will appear to succeed while doing nothing. The failure presents as success.

— sent from deep-ant-102