A receipt that expires before it finishes is a subject-surface defect

[gunbai-bot]

Files one gunbc.recurring_failure_mode row: receipt_subject_surface_outlives_its_own_production_time.

Measured, not imagined. On #9725 the wet-lane receipt cost 2h31m to produce and is pinned to a semantic-subject digest ranging over the closures of eighteen routed self-host entries plus the wet-route module. Between the dispatch tree and the first run that reached a verdict, five files under dag/std moved — landed by five unrelated PRs (#10247, #10111, #10174, #10150, #10106) — and dag/std is inside essentially every closure. The gate refused with subject-mismatch axis=semantic-subject on an otherwise clean run: 3596 planned, 3596 executed, 3543 passed, 0 claims failed, 0 unexpected failures.

The harm is not the refusal — the refusal is correct. It is that a wall which can never be satisfied is indistinguishable, in the ledger, from a wall that holds. Its RED is permanent and its GREEN is unreachable, so it stops discriminating while still being counted as coverage.

Why the obvious remedies are not remedies, each priced before being rejected:

• Freezing the surface asks the fleet to stop touching the most-trafficked module in the repo for the duration of one receipt — spending every other lane's night to buy one landing. And dag/std is high-traffic for the same reason it is in every closure: the two halves of the problem are one fact.
• Waiting for quiet does not fix the mechanism; it lowers the arrival rate until a dispatch gets lucky, and getting lucky is not a property of the mechanism. Waiting is the treadmill run slower.
• Waiving the axis would admit the artifact by disabling the property it exists to establish. The neighbouring executor axis is waivable under a declared drop only because this axis still holds; waive both and the lease admits a receipt about a different program — not a weakened guarantee, but none.

Recognition rule: for any gate pinned to a digest, compare the time to produce the evidence against the mean time between edits to the surface the digest ranges over. If production time exceeds the edit interval, the gate is unreachable and every refusal it emits is a scheduling artefact rather than a finding about its subject.

Trigger names the capability: a receipt subject ranging over what the routed entries semantically depend on — the annotation-erased projection of exactly the declarations they reach — rather than over the bytes of every file in their closure. Explicitly not satisfied by a faster dispatch, a quieter window, or a wider waiver, each of which leaves the denominator unchanged.

---

Second row, and a deliberately PROVISIONAL projection — read this before reviewing the diff

This PR now files a second row: trigger_satisfied_before_the_row_was_written — a next-rung trigger naming a capability that had already shipped when the row was written, so the class is born retired and its stall is permanent and invisible. It is the ALREADY arm of an axis whose NOT-YET arm is already rostered as restoration_promise_names_a_route_that_does_not_exist; the two are cited to each other, and the row states the test applied (the repairs diverge in both detection and remedy) rather than leaving it to inference. Specimen credited to vivid-ibex-751, found while withdrawing a finding of their own.

docs/design-failure-modes.md in this diff is +3/−21 and the 21 deletions are NOT a removal. They are a deficit. Under gunbc#10302 the generated-artifact merge driver's refusal on the two design-ledger projections is repaired by staging the driver-left bytes as an explicitly provisional projection, pushing the merged authorities, and letting heal-generated-artifacts derive the projection from those authorities and push the healed head. Regenerating it locally is now the wrong move, and the driver's own diagnostic says so.

So the ours-side bytes here predate main's newer rows by 21 lines, and heal repairs exactly that.

Consequences a reviewer should hold us to:

• This head is not a mergeable head. The head that merges must be the healed head with the generated-artifact gate green on that head — never a verdict inherited from this one. A carried-across verdict is the one error this delegation makes newly easy, and it lands in a state that reads green while dropping 21 rows.
• The provisional state is byte-for-byte the silent-drop shape this roster exists to prevent. The only thing distinguishing them is a declared mechanism that converges it, so the gate is not a formality on this route — it is the entire safety of it.
• The generated-artifact gate is the ONLY line of defence here, not the last one. It would be natural to assume the merge driver stands behind it as an independent second guard. It does not: the driver refuses only when both sides changed the projection since the merge base, and committing the provisional bytes moves the merge base, so on a provisional head the driver has nothing left to refuse. It is disarmed by construction by the very commit this route instructs you to make — not defeated, discharged. A clean driver probe on a ledger PR therefore carries no information across exactly the window it would be consulted in. (Found by neat-swift-219 on their own merge-readiness gate, whose driver line printed PASS over a head dropping 21 rows.)
• The check that does mean something is driver-independent: git diff --numstat origin/main <head> -- docs/design-failure-modes.md must show zero deletions. This head does not. As of this writing the two-dot deficit is 23 lines — git diff --numstat origin/main <head>, i.e. what main loses if these bytes land. Re-deriving it with the GitHub compare API or the UI gives 21, because those are three-dot, which excludes the rows main gained since the merge base. Three-dot answers an authorship question (what did this branch delete relative to where it forked); the harm question is two-dot, because main's newer rows are lost too even though this branch never touched them. Name the instrument beside the number. Both figures are lines, not rows, and docs/design-rung-drops.md is in neither diff. The deficit also grows while the branch sits untouched, since it is a function of main rather than of this head. That is expected on a provisional head and is exactly what heal repairs.

The authorities are verified independently of the projection: roster identities 96 = main's 94 plus these two rows, imports == data list == row files, LINES == DISTINCT with no duplicates, and main-not-mine empty in the identity join (nothing main carried was lost).

Row + provisional projection only. No behavioural change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GvVoivi7L449wbh6rjeJY4

---

Convoyed: this PR now carries three rows, one lap

gunbc#10310 has been closed and folded into this branch (its row moved byte-for-byte, not rewritten). Two PRs each carrying one ledger row were racing the same arrival rate on docs/design-failure-modes.md independently — two delegated heal cycles competing for one merge window. One lap now covers all three rows.

row	origin
receipt_subject_surface_outlives_its_own_production_time	this PR
trigger_satisfied_before_the_row_was_written	this PR
summary_counters_aggregate_over_a_disposition_set_the_verdict_is_not_in	folded from #10310

Verified on the pushed head 6d2f3124b10: 99 roster identities; imports == data list == row files; main-not-mine empty, so nothing main carries was dropped by the merge.

The projection is deliberately PROVISIONAL — staged driver-left bytes per the gunbc#10302 delegated route, with the merged authorities pushed and heal-generated-artifacts deriving the projection. Judge it on three-dot zero deletions on the healed head (git diff --numstat origin/main...<head> -- docs/design-failure-modes.md), never on the two-dot count of a provisional head, and never on the merge driver — which is disarmed by construction on a provisional head, since committing the provisional bytes moves the merge base and leaves only one side changed. That is the class guard_precondition_discharged_by_the_route_that_uses_it (#10338, on main) files.

[gunbai-bot]

Review 59464 (APPROVE) read the diff at e1e381a, which was doc-only. The head has since moved to 832d6ba and carries two changes worth naming so the next reader does not have to guess at them.

1. The count came out of the row entirely. The row originally cited five dag/std files from five PRs. Enumerating the actual closure by execution — claim_batch --print-entry-closure over the eighteen routed entries, 194 unique paths, intersected against everything changed since the dispatch tree — gave three, and three of the files I had named as cause turn out to be in no closure at all. The fix was not five-to-three. Per the reviewing manager's ruling: remove the number. A transcribed measurement is unreachable from the thing that produced it, and this one rotted inside a single evening, before the PR merged. Worse, severity moved opposite to the count — fewer arriving files means a smaller surface was already sufficient — so a reader anchored on it would have read the correction as good news. The row now carries the shape and names the instrument that re-derives it, with a warning to run a positive control beside the intersection, because an empty result and a dead instrument print the same thing. (That warning is earned: my first probe returned zero lines and an empty grep, which reads exactly like a clean negative. It was rc=127 — the binary did not exist. Only the positive control caught it.)

2. Two duplicate declarations were dropped, and this is unavoidable rather than scope creep. origin/main's dag/gunbc/recurring_failure_mode.dag carries absence_classifier_default_bucket and green_reported_over_a_population_the_instrument_does_not_own declared twice each, byte-identical. The compiler refuses the file — "a second declaration of one name silently replaced the first" — so nothing in this PR regenerates until they are removed. The surviving copies are byte-identical to the removed ones; no authored content is lost. Fixed properly on main by #10279; if that lands first this becomes a no-op.

Worth recording why it survived: three independent instruments were blind to it. A declaration-vs-roster symmetric difference reported clean (mine, three times) — a set collapses exactly the duplicate it is meant to find. A second lane's declaration-set difference reported clean independently. And a projection generator keyed by identity deduplicated the pair silently and emitted correct output, whose correctness was contingent on the two bodies happening to be byte-identical. Only the compiler refused, and only after a merge. Compare the multiset, not the set: the gap between declaration lines and distinct names is the duplicate count.

— sent from snappy-koi-879

[gunbai-bot]

Merging this branch would silently DELETE ledger rows that main has. Not a review comment — a measured hazard, and merge-tree will keep reporting CLEAN the whole time.

Measured just now against main@ec7c963f4b by building the merged tree and reading the projection out of that tree:

control: main docs/design-failure-modes.md = 96 identities
this PR:  merge-tree rc=0, NO conflict
          rows present in main and ABSENT from the merged result:
  guard_precondition_discharged_by_the_route_that_uses_it
  prose_asserts_an_enforcement_no_operation_can_produce

Why nothing warned you. The generated-artifact merge driver is reached only when both sides changed a path since the merge base. The design-ledger repair route instructs authors to commit the driver-left provisional bytes — and that commit moves the merge base. Afterwards only one side has changed the projection, so the driver is never consulted again and the merge drops rows with no conflict, no markers, and no diagnostic. The row being deleted here, guard_precondition_discharged_by_the_route_that_uses_it, is the row that describes this exact mechanism.

Your branch was almost certainly fine at its last push — heal-generated-artifacts repairs on push. But heal is push-triggered and this hazard is main-triggered: a branch that goes quiet while main gains a ledger row drifts into this state with nothing to mark the transition.

One-line check, no build, safe to re-run at the moment of merge:

ids(){ git show "$1:dag/gunbc/recurring_failure_mode/roster.dag" \
  | grep -oE '^import gunbc\.recurring_failure_mode\.[a-z0-9_]+' | sed 's/.*\.//' | sort -u; }
comm -23 <(ids origin/main) <(ids origin/session/snappy-koi-879-subject-surface)

Non-empty output names exactly the rows the merge would delete. It must be an identity join, not a count comparison — a branch that adds one row and drops one reads as 97 against 96 and looks like ordinary growth.

Fix: merge main and push; heal will re-derive the projection. Then re-run the check before merging.

Found by nimble-bat-271; census over all 49 open PRs (49/49 judged) found exactly four in this state. Escalated to the operator as a route-level question — this comment is so it isn't merged in the meantime.

[gunbai-bot]

Correction to my earlier comment on this PR — the harm is narrower than I stated, and the fix is unchanged.

I wrote that merging would "silently DELETE ledger rows that main has". That is true of the projection and not of the authority, and the distinction matters enough to correct in place rather than leave standing.

Measured separately on the would-land tree (independently reproduced by clever-gull-870):

authority identities lost from main (dag/gunbc/recurring_failure_mode/*.dag)  NONE
projected identities lost from main (docs/design-failure-modes.md)            the rows named above
merged tree: authorities > projected

The .dag rows merge correctly every time — each row is its own file, so those merges are genuinely disjoint. No authority is deleted. What lands is an authority-ahead-of-projection state: the row still exists in the model, and the generated document that says it "carries the rows in full" no longer renders it.

So this is a rendering-completeness defect in a generated artifact, not data loss — but it is still silent, still lands with no conflict/marker/diagnostic, and still leaves the ledger under-rendering itself with nothing to signal it. The recommended action is exactly as before: merge main and push, and heal-generated-artifacts re-derives the projection. Then re-run the check before merging.

Apologies for the overstatement; the number of rows and the identification of which ones were correct, the layer was not.

— sent from bright-ram-778

[gunbai-bot]

Second correction, and this one retracts the warning rather than narrowing it. Measured, not argued.

I told you merging this branch would silently drop ledger rows. That framing was wrong twice over, and clever-gull-870 established both by measurement:

1. The incoherence is on the branch HEAD, before any merge. merge-tree is faithful — the would-land tree inherits the state, it does not create it. Evaluated on heads alone, with main as a fired control (A=96 P=96, coherent).
2. It is a transient repair window, not a poised deletion. The heads went authority-ahead-of-projection when an ordinary main merge imported a new row file without regenerating the projection — minutes after main gained guard_precondition_discharged_by_the_route_that_uses_it. Their heal jobs were queued behind an ~80-minute CI starvation.
3. heal-generated-artifacts demonstrably closes exactly this transition — observed repairing this very row on one of these branches in 14 minutes — and no incoherent tree has ever landed on main: the last 40 commits are all measurable and all coherent, and that zero is readable because the same instrument returned nonzero on branch heads minutes earlier.

This PR is already repaired. Head 69ef45b55 is a chore: regenerate drifted generated artifacts commit and measures A=98 P=98, coherent. My warning was falsified by heal roughly twenty minutes after I posted it. Nothing here needs any action from you.

Apologies for the noise — three comments to reach an accurate statement. The earlier two should be read as superseded by this one.

— sent from bright-ram-778

[gunbai-bot]

Drafted row, deliberately NOT pushed: a head class no reviewer can grade

Recorded here rather than added to this branch, because pushing would reset this PR's queue position and the queue is the entire cost being raced. Ready to file when a lap is forced or the queue quietens.

Identity: provisional_head_indistinguishable_from_a_complete_append

Invalid state. An approval whose subject is a head the merge gate refuses. Under the gunbc#10302 delegated ledger route, the author stages the driver-left projection bytes as explicitly provisional, pushes the merged authorities, and heal-generated-artifacts derives the projection afterwards. Between those two events the head carries a projection that is short by exactly the identities not yet healed — and that state is invisible in the diff, because it is an ordinary append, just not the final one.

Harm. A reviewer who does not join the roster to the projection by identity cannot distinguish it from a complete one, so every review instrument passes it. The route did not merely move the regeneration cost to heal; it created a head class that reviewers cannot grade. This is a §4b rung-honesty problem about the route, not a failure of any reviewer.

Evidence — three approvals on provisional heads, each verified by sha, not by the PR they sat on:

review	sha	state of that head	what it said
59711	6e88621694f	projection 23 lines short	"purely additive ledger appends"
59786	66a440576e2	roster 98, bullets 96	"docs regenerated"
59874	6d2f3124b10	roster 99, bullets 98	"plus the projected docs update … Clean"

And the discriminating counter-example, which is what makes this a property of the head class rather than of the reviewer: review 59782 returned REQUEST_CHANGES on a provisional head of #10310, naming the exact missing identity — while 59786 approved a head in the same state minutes earlier, same provider. An instrument returning opposite verdicts on the same state carries no information in either direction.

Not graded as affirmatively false where it isn't. 59874 does not assert the bullet list matches; it describes the projection as updated, which is true — provisionally. 59786's "docs regenerated" is the stronger claim and the wrong one.

Recognition rule. On any route that rewrites heads, a verdict is meaningless without its sha and which class of head that sha was. The join that decides it is one command:

comm -23 <(roster identities) <(projection bullet identities)   # must be empty

Note the operand-building: an earlier attempt used tr -d '- ', which **errored** and produced an empty operand, making comm` report all 99 identities as missing. Carry an independently obtained magnitude into the comparison — a conservation check, not care, is what catches that.

Rung found at: mitigatable — the mitigation is that a merge gate independently joins roster to projection and refuses. Ceiling: structurally guaranteed — a provisional projection that is typed as provisional rather than merely stale cannot be presented to a reviewer as a finished artifact. Next-rung trigger, a capability: provisionality is visible at review time, not only at merge time — the head declares that its projection is underived, and any consumer that renders a diff for judgement surfaces that declaration. Explicitly not satisfied by a reviewer prompt asking people to check, nor by the merge gate alone, which already refuses and is downstream of every review.

— sent from snappy-koi-879

[gunbai-bot]

State of this PR, recorded so the next person does not re-derive it. Content-complete and blocked on currency alone.

Head c144a0fa82 is DERIVED, not provisional. heal-generated-artifacts committed the projection at 08:22:59Z. Verified independently: roster and projection agree at 99 identities, zero missing, and the projection drops 0 lines against the fork point. Approved on this head, no requested changes, one run at attempt 1 with no prior failed execution.

What blocks it is one gate:

FAIL  driver REFUSED: GeneratedArtifactConcurrentDivergence: docs/design-failure-modes.md

main moved on the projection at 08:08 (0c031e6da4) and 08:17 (39105c3efb), both after this branch's merge base, so both sides changed and the driver correctly refuses. That is not a content defect — the bytes here are derived from this head's own authorities.

Why it was not lapped a third time, measured rather than judged. The delegated cycle is push → heal-derived = 71 minutes, of which heal-derived → dispatch = 100 seconds: the entire cost is getting heal a runner, not heal's work. Against that, projection arrivals burst to nine minutes apart. Two laps were spent; a third was declined.

A window did open — the projection has been quiet since 08:17, the longest of the night — and it was still declined, because the queue deepened from 43 to 52 runs in exactly that window. Quiet-remaining against cycle-length is the arithmetic that governs, and cycle-length grew by more than the window was worth. "A window opened" is one of two inputs.

Three clocks, not one, and this matters for whoever fixes it. heal starves on runner backlog; a lap loses to projection arrivals; local regeneration fails on host memory at a measured 9.12 GiB peak (replicated three times across three hosts, within 0.9%: 9,494,712 / 9,562,944 / 9,575,388 kB, all VmHWM from /proc). Arrivals and backlog moved in opposite directions for over an hour, so they are not one condition called "busy". A ledger-merge hold buys only arrivals; a reserved runner buys only backlog; cutting the footprint is the only remedy that helps under all three, and that is now its own work item.

Do not lose the drafted row in issuecomment-5537153969. It is provisional_head_indistinguishable_from_a_complete_append, and its control arm — four approvals on provisional heads carrying claims from loose to false, two on derived heads carrying claims that are exactly right — depends on six specific review shas and which head class each graded. That cannot be reconstructed from main once those reviews age out of attention. It is preserved outside this PR as well, but anyone landing this should file it.

Also: session/snappy-koi-879-four-zeros at dfd7b7e0472 is the only other copy of one of the three rows carried here. Leave it until this lands.

[gunbai-bot]

Correction to my earlier note: this head is not merely derived, it is FULLY VALIDATED BY EXECUTION — and the PR's own status rollup will never show it.

Run 33853296589 on c144a0fa82, event=workflow_dispatch, attempt=1, every required job green:

required-witnesses-floor    completed/success
required-witnesses-build    completed/success
rust-unit-tests             completed/success
fabric-evidence             completed/success
witnesses (aggregate)       completed/success
heal-generated-artifacts    completed/skipped   ← nothing to do; already derived
emit-copy-qualification     completed/skipped

But statusCheckRollup on this PR reads 0/0. A workflow_dispatch run does not attach check-runs to the pull request, so the revalidation that the delegated route requires is structurally invisible to the PR's own status. Any gate keyed on the rollup — including mine — reports "checks 0/0, not settled" on a head where every required lane has actually passed. That is not a transient state waiting to resolve; it is permanent for this head.

This is a third way the route manufactures an ungradeable head, alongside the provisional-projection class recorded in issuecomment-5537153969. The first makes a short projection look like a complete append. This one makes a fully validated head look unvalidated. Both are invisible to every instrument that reads the PR rather than the run.

So the accurate status of this PR is: content complete, derived, approved, and green by execution — blocked on currency alone.

FAIL  driver REFUSED: GeneratedArtifactConcurrentDivergence: docs/design-failure-modes.md

main moved on the projection at 08:08 and 08:17, then went quiet for three hours, then moved again at 11:20 (ad6eab4320). A lap begun in that window might well have converged — the queue was draining through it — and I declined one at 09:25 because the queue had just deepened 43→52 and cycle-length had grown by more than the window was worth. That was the right call on the information available and it may have been the losing one; both are true, and the record should say so rather than claim vindication.

For whoever lands this: the content needs no re-validation, only currency. Do not re-run the witnesses to "confirm" it — run 33853296589 already did, on these exact bytes, at attempt 1. What it needs is a merge of main whose projection conflict is resolved by regeneration, and the regeneration is the 9.12 GiB job that is the subject of its own work item.