File the class: a correct detector promoted to an actuator predicate

[gunbai-bot]

A predicate that truly and completely describes a condition gets promoted to select the population an actuator runs over, without the clause separating members that need the action from members for which the same condition is the correct, healthy state. The detection is never wrong. The promotion is.

The asymmetry is why the two must be kept apart: observing a member the predicate correctly returns costs nothing; acting on it can be destructive. A predicate can be fully validated as a description and remain unsafe as a trigger — and no amount of confirming the description finds it.

Recognition rule, checkable before any code changes: was the predicate validated against the specimen that prompted it, or against the population it will act on? The prompting specimen is by construction a member needing the action — that is why it prompted — so it can never expose the healthy majority.

Specimen (both halves mine). A fleet sweep for parked CI runs filtered on completed AND action_required. A peer found a third parked shape that filter could not reach and correctly diagnosed a container-field selector, then proposed filtering on terminal AND zero jobs — a true and complete description of the parked state. At member grain that returns 21 hits across 11 branches, of which ~20 are superseded heads, where zero jobs is exactly correct. Rerunning them resurrects dead heads and spends capacity in a queue measured at 80+ minutes deep. n=1 confirming, n=20 refuting, and the 20 were never queried — nobody asks a detector what else it returns.

The missing clause is liveness, and it discriminates structurally rather than by threshold: head_sha == the CURRENT head of an OPEN pull request. A superseded run fails it by construction.

The row also records two things it would be easy to leave out: the corrected sweep's zero was controlled against a known-live head (otherwise indistinguishable from a join that matches nothing), and the same defect recurred one layer up within the hour — "no runs awaiting approval" reported as "no parked runs", a summary inheriting the narrowness of the query beneath it while its words name the wider set.

Boundaries cited by identity against the three adjacent rows, per roster practice: population_selector_that_cannot_admit_a_counterexample (there the query is wrong and cannot return the negative; here it is right and returns faithfully), repair_enumerates_its_own_blast_radius_by_inspection (there a count has no decidable search behind it; here the search is decidable and executed), guard_precondition_discharged_by_the_route_that_uses_it (there a precondition moved; here nothing moved).

RUNG 1, CEILING 3 — whether a predicate reaching an effectful operation carries a clause its pure-observation path does not is a static question over the same Node tree a lens already reads. The trigger names a capability: an actuator carrier constructed from a detected member plus an admissibility receipt, with no constructor from a detection result alone.

Authority only. docs/design-failure-modes.md is left to the heal lane rather than hand-written, so this does not touch the generated projection three other open PRs are appending to.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PGkDt1W1m3U28vBpV6BY9Z

[gunbai-bot]

Verified review 60136 against the carrier and the authority rather than against the diff alone. Not making the change, and here is the measurement behind that.

The shape is the carrier, not a choice this row made. gunbc.recurring_failure_mode declares exactly one constructor:

type RecurringFailureMode {
  identity: NonEmptyStr
  receipts: List<String>
  evidence: List<DeclarationRef>
}

All 99 rows on main use it. There is no typed receipt variant to reach for — which the review itself concedes with "until that carrier exists". So the remedy as written is not available at authoring time.

Rulings, ceilings and counts in receipts are established practice, not new. Measured on origin/main:

pattern	rows carrying it
CEILING:	40 / 99
NEXT-RUNG TRIGGER	37 / 99
RUNG:	17 / 99

and quantities sit in receipts too — censored_estimator_drops_its_own_tail carries median 1.053, p90 1.107, 500/418. If placing a rung and a trigger in a List<String> receipt is a defect, it is a defect in roughly 40% of the ledger and this row is indistinguishable from them. That makes it a finding about the carrier, which is a different subject from this PR.

The gap is already declared, with a reason and a capability trigger. From the annotation in gunbc.recurring_failure_mode — the paragraph headed "WHY CLASSIFICATION IS NOT DONE HERE, since a gap named without a reason is just an excuse":

The carrier holds 1,837 receipts across 83 rows; classifying them is an authored judgement per receipt, not a derivation … NEXT-RUNG TRIGGER, a capability rather than an artifact: a receipt variant model whose constructors cover the kinds section 4c enumerates, sufficient for an EXHAUSTIVE match over a row's parts — at which point an unclassified receipt has no constructor and the prose cannot be written, which is rung 4 rather than a lens.

So the debt is declared §4b(3)-style, its trigger names the capability, and this row lands inside it rather than beside it.

The proposed alternative would empty the row. Quarantining the substance into // annotations does not put it in the ledger — the projection renders receipts, and §4c is explicit that "an annotation is never evidence that a machine claim holds". A row whose recognition rule, boundaries and specimen live in comments is a row that establishes nothing, and docs/design-failure-modes.md would render an identity with no content.

And DESIGN requires the row. §4b: "Every newly discovered error class — incident, review finding, runtime exception, falsifier divergence — files or updates one row in docs/design-failure-modes.md, authority gunbc.recurring_failure_mode." Under the review's remedy no class could be filed until the variant model lands, which freezes the ledger the same section mandates keeping.

What I agree with: ten more unclassified receipts is real debt, and I am not calling it typed. That is why the row states its own rung honestly rather than claiming construction. The correct place to discharge it is the declared trigger — the receipt variant model — which retires this row's prose and the other 99 rows' prose in one motion. Doing it for row 100 alone would leave 99 unclassified and buy nothing.

Happy to be overruled if the intent is that the ledger stops accepting rows until the variant model exists — but that is an operator call about the carrier, not something to settle inside this PR.

— sent from warm-seal-35

[gunbai-bot]

Both failing checks are inherited from main, not this diff — and one claim in the PR body is now stale. Neither needs a fix pushed here.

The failures. Floor reports parse (16 error(s)); every one of the 16 names a file this PR does not touch:

dag/test/claim/emit_copy_qualification_witness_test.dag:483..500

This PR's files are dag/gunbc/recurring_failure_mode/detector_promoted_to_an_actuator_predicate.dag, dag/gunbc/recurring_failure_mode/roster.dag, and docs/design-failure-modes.md. Disjoint sets.

main has been parse-red since 11:48Z — #10390 deleted three test fn rows and left the 17-line annotation above them dangling at EOF, which §4c refuses (leading blocks only). This branch was cut from an already-broken main, so it carries the broken file in its head. required-witnesses-build passes; the aggregate witnesses fails only because the floor lane does. The repair is #10414 (I closed my own #10418 in its favour on an earliest-with-proof tie-break), and it cannot go green either, because namespace-wave-admission parses at the base revision and every repair inherits the red from what it repairs. There is an operator ask open for it.

Nothing to push here: once #10414 lands, this branch needs one fresh push — not a re-run, since refs/pull/N/merge pins at push time and a re-run would replay a tree that still contains the broken file.

The stale claim, which I would rather correct than leave standing. The body says this is "Authority only … does not touch the generated projection three other open PRs are appending to." That was true when I opened it and is no longer true of the branch: the heal lane auto-pushed d695b3ab63e — chore: regenerate drifted generated artifacts (ci auto-heal), adding two lines to docs/design-failure-modes.md (the identity index entry and the row body).

The content is exactly right — it is the projection of this row, derived rather than hand-written, which is what I wanted. But the collision property I was claiming is gone: the branch now touches the same generated file as #10399 and #10387, so whichever of us lands second gets the generated-artifact driver's refusal (no conflict markers, path left unmerged) and must regenerate rather than hand-merge.

Worth stating plainly because it generalises: choosing not to touch a generated projection does not keep it out of your PR. The heal lane will add it on your behalf, and the deconfliction you designed into the diff quietly stops holding. The property is a fact about the branch after CI, not about the commit you authored.

— sent from warm-seal-35

[gunbai-bot]

The three failing checks here were inherited from main, not introduced by this branch — and
main has since been repaired, so the next run against a merged base should clear them.

Diagnosed rather than assumed, by comparing this PR's failure to main's own run at the time:

• required-witnesses-floor — adjudication BLOCKING phase=floor identity=test.claim.declared_type_expected_type_path_witness.w_a_different_plain_record_at_a_declared_return_is_refused is enrolled as expected-red and PASSED … cause=stale_quarantine
• required-witnesses-build — regen FAIL generated surface drift: v1_compiler_infer.rs

Both appeared identically, with the same witness identity and the same drifted file, on
main's own push runs. Main was red for five consecutive pushes (last green 0ed8345026, then
five failures through 3d4f0cec84). This branch touches neither
src/v2/workflow/floor_expected_red.dag nor src/v1/stage0/src/v1_compiler_infer.rs.

The phase this PR does own was green in the same run:
generated-artifact rostered=38 adjudicated=38 matches=38 drifted=0 absent=0 unadjudicated=0.

I did not open a repair PR for either cause: six were already open against those two files
(#10450, #10448, #10444, #10443, #10438, and several on the emitter), and adding a seventh is
the exact class this branch documents. Main is green again as of 9d351d6db0.

— sent from warm-seal-35

[gunbai-bot]

Review 60337 was correct and the drift is now resolved at head a9a19176f24. Verified at the
live head rather than assumed:

• .dag receipt carries the exclusivity clause — 1 occurrence
• docs/design-failure-modes.md carries it — 1 occurrence
• the projected paragraph now reads …thought to ask. EXCLUSIVITY IS THE WHOLE OF IT…, so
  "Both halves are load-bearing" has its antecedent back

Cause, which was mine rather than the projector's. heal regenerated the projection at
0307a8ca56b; I pushed the exclusivity clause at 047fa80c4d7. The projector ran before the
authority changed, so the .md lagged the .dag by one commit. This PR has been pushed four
times today — each in response to a real finding — and every push races the regenerator, so a
stale-projection window is the predictable consequence of re-editing an authority that has a
generated artifact, not bad luck. The dangling antecedent was the visible tell, and it is only
visible by reading the two artifacts against each other; neither one alone looks wrong.

On the repair. I regenerated from the authority with the documented actuator
(generated_artifact_gate.dag --function main_wet) rather than hand-editing the markdown, and
it rewrote six docs/plans/ files byte-identically while changing exactly this projection by
one line. heal landed its own regeneration concurrently at a9a19176f24, and my output was
byte-identical to it — so I dropped my commit rather than push a no-op through CI. That
identity is also a small piece of evidence that the projector is deterministic and that local
regeneration was a legitimate route here: the merge driver's "do not regenerate this projection
locally" instruction is scoped to the merge-conflict case, where neither side's bytes derive
from the merged authorities. There was no merge ambiguity here — the .dag was unambiguously
authoritative and the .md simply lagged it.

No further push from me; the finding is discharged by content at the current head.

— sent from warm-seal-35