Three failure-mode rows for the 2026-09-03 19:49 main outage

[gunbai-bot]

main was red from 19:49Z for roughly eighty minutes: gunbc.recurring_failure_mode
declared absence_classifier_default_bucket and
green_reported_over_a_population_the_instrument_does_not_own twice each, which
refused generated-artifact resolution and reddened the BUILD lane (not the floor).
#10278 (1af8892) repaired it with a four-line deletion. This files the classes;
it repairs nothing and builds no check.

ROW 1, RANKED FIRST -- head_landed_by_hand_before_its_own_verification_reported.
#10236 (cfe19ea) merged at 19:49:43Z, three seconds after the only run on its
merged head was created at 19:49:40Z; that run concluded FAILURE at 20:30:34Z, and
gh api reports merged_by: briansrls -- a HUMAN merge. The row says so explicitly
rather than naming an automated gate, because a broken automation and a missing
constraint on a person acting inside their own authority are different findings with
different repairs. It states that it SUBSUMES the detection-timing classes: if a head
can land before its checks conclude, no detection improvement changes the outcome.
Branch protection is named as UNMEASURED -- session tokens get 403 on it -- so the
row claims nothing about the ruleset. Distinguished from
required_evidence_absent_reads_as_evidence_of_pass, which is a defect in an admission
arm's quantifier; this row is the absence of any arm between the actor and the landing.

ROW 2 -- append_only_carrier_re_adds_what_its_own_base_already_carries. The two names
were first added by #10166 (2bba578) at 07:29Z; #10236 added both a second time,
its whole diff on the file being +4 lines. git merge-base --is-ancestor 2bba578d56e cfe19ea7f48 holds, so the branch re-added declarations its own base already carried,
and text merge reported nothing because both sides are insertions at different offsets.
The row quotes the carrier's own header premise -- "two lanes editing the SAME class
still conflict -- which is correct, because that is real disagreement about one fact"
-- and names why it holds for EDITS and fails for APPENDS, which is the only operation
an append-only roster performs. It also records why the projection-fidelity gate stayed
green: the projection maps over the roster, which names each identity once, so a
duplicated declaration renders nowhere. Distinguished from
premise_that_a_shared_subject_means_disagreement, which quotes the same sentence about
a different loss (author time, not a refusal).

ROW 3 -- verdict_stale_at_the_merge_instant, scoped as ANCILLARY and explicitly not
this outage's cause. #9981 (8b2323f) merged at 20:29Z with a verdict 52 minutes
stale, onto a tree already broken for forty minutes; it added a new identity colliding
with nothing. Filed anyway because the class is real and this specimen is clean.

All three carry rung found at, ceiling with its reason, and a next trigger named as a
capability. Rows 1 and 3 both name
gunbc.guarantee_stall merge_admission_terminal_verdict_stall and row 3 says the one
construction discharges both.

MODEL-SIDE ONLY: three row declarations, three roster lines, and the regenerated
projection. No v1 seed change.

RECEIPT: gunbc run --source-root dag --source-root src/v2 --entry dag/gunbc/instruments/generated_artifact_gate.dag --function main_wet exits 0 against
a gunbc built from this tree, and its only diff is the three appended rows in
docs/design-failure-modes.md.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01NF46KAHEcLoqEyMqzPWNZ9

🤖 Generated with Claude Code

https://claude.ai/code/session_01NF46KAHEcLoqEyMqzPWNZ9

---

LIVE SPECIMEN, MEASURED ON THIS PULL REQUEST ITSELF, of main's
append_only_carrier_whose_serialization_shares_a_merge_region — recorded here rather
than filed as a row, because that row already owns the class and a second would be the
fork this PR renamed a row to avoid.

Merging origin/main at 78932411548 conflicted on exactly one path,
dag/gunbc/recurring_failure_mode/roster.dag, in both of its blocks: main had appended
discriminating_arm_built_but_never_enrolled and this branch had appended its three.
The appends are disjoint — different rows, different subjects, no shared fact — and they
collided anyway because the serialization puts every append in one merge region. The
resolution was a mechanical ordered union, main's row first by landing order so the
projection prefix does not move. That is the third such merge on this PR, and none of the
three carried any disagreement to resolve.

So the class blocking this change is the one the change documents the dual of: a conflict
carrying no information, holding up the PR that files the collision-producing-no-conflict
case beside it.

[gunbai-bot]

review 59994: fixed in e377b88 — the finding was real, and the answer to "or confirm the grammar concatenates" is BOTH.

The grammar does concatenate: gunbc run --source-root dag --source-root src/v2 --entry dag/gunbc/instruments/generated_artifact_gate.dag --function main_wet exits 0 before and after the fix, and the regenerated docs/design-failure-modes.md is byte-identical across the commit — that diff changes no projected byte. So it was not a parse failure, and the module resolves.

It was still a defect, in the way this carrier specifically cares about. Without the commas those six receipts are ONE list element. gunbc.recurring_failure_mode's own header calls the per-element trailing comma load-bearing rather than style: a missing one drags the preceding receipt into the conflict region and destroys the minimal three-way merge geometry that two separate repairs of this carrier were spent buying. Five commas added, nothing else touched.

Worth noting what this says about the wall: that header also states nothing enforces the shape and it is held by the paragraph alone, and names the capability that would — a producer carrying each declaration's source extent, sufficient to refuse a row of this type whose elements are not severable. This landed exactly as that paragraph predicts: caught by a reader, not by a check.

— sent from merry-hawk-143

[gunbai-bot]

review 60061: APPROVE, nothing to fix — one factual amendment for whoever lands this, because the review describes docs/design-failure-modes.md on this head as the regenerated projection and on this head it is not.

After the merge with main, both sides had changed that projection since the merge base, so neither side's bytes are the projection of the merged authorities. The generated-artifact merge driver printed its declared route and I followed it: the driver-left ours bytes are staged as provisional and were deliberately NOT regenerated locally, which step 2 of that route explicitly forbids. heal-generated-artifacts derives the real projection from the merged authorities and pushes the healed head.

So the committed projection on a27ed439 is knowingly stale in two ways: it carries the pre-rename identity append_only_carrier_re_adds_what_its_own_base_already_carries (renamed to duplicate_declaration_arrives_through_a_clean_merge when main landed a row whose name opened with the same four words), and it lacks main's own new row. The .dag authorities are correct and complete; the markdown catches up when heal runs.

That is not a hole to worry about. The generated-artifact phase compares every committed projection against its authority and refuses on Drifted or Absent, it routes to the Build lane, and the aggregate needs [build, floor] with if: always(), refusing anything that is not success — including skipped and cancelled. If heal never runs, this reds rather than lands.

Verification of the merged authorities was done without breaking that route: the gate was run over the merge commit in a throwaway worktree (exit 0, only the projection differs) and discarded. This branch was not regenerated.

— sent from merry-hawk-143

[gunbai-bot]

CI status on 2dd5108, investigated: the two failing checks are not caused by this diff, and there is no fix for me to push.

• required-witnesses-build: success.
• heal-generated-artifacts: skipped, correctly — nothing left to heal.
• required-witnesses-floor: failure, with the floor itself clean (verdict=FloorClean … claims_failed=0 unexpected_failures=0 on the prior run). It exits at adjudication REFUSED standing=measurement_completed blockers=2, and the two blockers are FAILED PHASE parse (16 error(s)) and FAILED PHASE namespace-wave-admission (no head index) — the second downstream of the first.
• witnesses aggregate: failure, because a lane was not success.

All 16 parse refusals are in dag/test/claim/emit_copy_qualification_witness_test.dag lines 483–500, each source annotation names no subject: no module item follows it. That file ends with a trailing standalone // block attached to no declaration — what §4c says the .dag realization refuses. It was left there by #10390 when three rows were deleted, its bytes at origin/main (97345e5) are identical to the copy on this branch, and nothing in this PR touches it. Every branch that merges main reds the same way.

The repair is already owned twice over — #10414 (re-attach) and #10420 (delete) are both open — so a third attempt from here would be waste, and editing another lane's cut is not mine to do. Worth knowing for whoever lands this: #10414's run shows parse clean but still fails on namespace-wave-admission (NotEvaluated), so the annotation repair alone may not green the floor; re-read the phase list rather than assuming.

This PR is content-complete and parked: six approvals, the one REQUEST_CHANGES long superseded and fixed, projection union verified at this head (all three new rows plus main's own, in index and body). It is blocked on a main defect it did not cause.

— sent from merry-hawk-143

[gunbai-bot]

review 60183: the finding was correct and is fixed in 031be0e32412dd0bebed73427bcf3a2b5f5958e8.

The row did contradict itself. It said the actor acted "with no constraint that could have stopped them" and, four receipts later, that it does not claim protection was absent, misconfigured, or bypassed. merged_by plus two timestamps establish an uncertified landing; they do not establish which admission path permitted it. Asserting the path from that evidence is the fabrication §4b keeps off the ladder as external reality — the review's citation is the right one.

Narrowed to what was observed. The invalid state is now the landing itself: at the instant of the landing there is no concluded run for the landed ref. The row states explicitly that which path permitted it — an absent constraint, a constraint that treats an unreported required context as not-failing, or a bypass — is a separate question the actor and timestamps do not settle.

The actor stays, as an observation about who, not about what stood in the way. It fixes who the repair must reach: a repair aimed at an automated arm changes nothing for a landing no automated arm performed.

And the unmeasured receipt now separates two things it had fused, which makes the row stronger rather than weaker. This filing could not read protection (session token, 403). The repository does record the answer, so it is cited rather than left as a hole: gunbc.merge_lifecycle holds that gunbc.repo_ruleset desired_ruleset_rules read ruleset 16178731 back with no divergence — active, default-branch-scoped, one required context — and that the merge was admitted anyway, because the platform decides required contexts on what has reported at the merge instant and an unreported context is expected rather than failing. On that authority a constraint existed and admitted, which is exactly why the row is about an uncertified landing and not a missing gate.

The sibling-row distinction is restated on the same basis: required_evidence_absent_reads_as_evidence_of_pass is about an admission arm's quantifier; this row is about the landed state, reachable by paths that arm never touches.

Re-verified: the generated-artifact gate exits 0 over the new commit in a throwaway worktree, and the derived projection carries the corrected text and no longer contains the struck claim.

— sent from merry-hawk-143