A refusal is only a refusal if it survives its caller: file the class a correct producer and a re-absorbing consumer produce together

[gunbai-bot]

Files refusal_reabsorbed_by_intermediate_default, and — added on the merge of main — two further ledger appends. All three are gunbc.recurring_failure_mode changes on one head, deliberately, because CI runner supply is the binding constraint today and a second head costs a full validation epoch.

1. refusal_reabsorbed_by_intermediate_default (the original subject). A producer returns its typed refusal at an explicit inability boundary and an intermediate consumer reads that outcome as permission to substitute a default, so the composed path fabricates an answer while every individual frame is locally defensible. Site-local review is structurally blind to it: the producer's diff shows a correct refusal being added. Measured on #10146, where the first repair was itself an instance of the class it was fixing.

2. NEW ROW upstream_carrier_substituted_for_the_consumer_selected_subject. A claim about a downstream consumer is derived from an upstream carrier because the carrier is easy to count, while nothing binds the carrier to the subject the consumer actually processed. Both specimens are mine, and both were stated as findings before they were checked:

• a projection census run on branch head H, reported as a statement about what CI accepts — when the pull_request consumer judges the composed tree T = merge(M, H). Re-measured on T: clean, every row present.
• merge latency modelled as raw head count × one CI cycle, when the resource is consumed by started validation epochs. Measured at 0.29–0.88 started runs per distinct head, never 1.

This is an identity substitution across a consumption boundary, not an imprecise proxy — a distinction that matters because "measure the proxy more carefully" is exactly the move that entrenches it. Bounded explicitly against instrument_output_read_as_subject_content, where the defect is the reporting tool's completeness rather than a transformation of the subject.

3. SPECIMEN appended to incidental_denominator_as_wall, not minted as a second row. One capability retires both — declaring and enforcing the relied-upon invariant — so a fresh authority would have been a failed decomposition under §2. #10337 keys brand declaration identity on span.file, and offered a bounded disposition on the ground that the key is file-keyed where the authority is module-keyed. Measured before admitting the debt: 4754 .dag files, zero declaring more than one module, with a control confirming the regex matches. File→module is injective, so the offered gap does not exist and the drop row was refused rather than written. But the equivalence is a corpus property that nothing enforces — no authority declares it, no diagnostic fires if it breaks — which is this row's shape and generalizes it past mutating bytes to identity keys.

On the merge resolution — CORRECTED, and the correction narrows what this PR claims. The projection was resolved by taking the target side verbatim rather than staging the driver-left bytes, which are the ours side and delete rows. That part stands.

What does NOT stand is citing #10383's printed set-difference as verification of this candidate. That command reads git show HEAD:$merged_path, and after the route's step 1 changes the worktree, HEAD still denotes the PRE-MERGE branch commit — not the checked-out bytes, not the index candidate, not the merge tree. So it verifies an ancestor carrier while claiming to verify the candidate. My run of it did carry a positive control (99 identities actually read from docs/design-failure-modes.md, so it was not the vacuous case — the same extractor reads ZERO identities from docs/design-rung-drops.md, whose identities are prose headings, and there it compares empty against empty), but a real population read on the wrong object is still the wrong subject.

So the honest standing of this local evidence is a no-deletion intention over a real population, not a verdict about the composed candidate. The authority for that is the exact-head pull_request aggregate on the composed tree, and this PR waits for it. The canonical local route is not the one I merged: it is to merge the authorities, regenerate the projection from that merged authority tree, run the generated-artifact drift gate on those bytes, and stage the derived projection — which answers the question by construction. A repair demoting #10383's printed fallback follows separately. The tree is therefore authority-ahead-of-artifact by exactly this branch's own rows, which is the state heal repairs and the generated-artifact gate can see. Roster conservation asserted at 101 imports / 101 entries.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WgiDD3VoavwLrcu832nJ2V

[gunbai-bot]

This red is inherited from main and will not be fixed by anything in this PR. Not pushing.

CI flagged required-witnesses-build failing at 6d5489b. Measured rather than assumed — a run can carry two reds, one inherited and one real, so I checked for both:

FAILED PHASE regen (1 failure(s))          <- exactly one
required-ci: regen FAIL generated surface drift: v1_compiler_infer.rs
distinct phase failures: regen             <- only one phase

This PR does not touch that file. Its complete file list:

dag/gunbc/recurring_failure_mode/incidental_denominator_as_wall.dag
dag/gunbc/recurring_failure_mode/refusal_reabsorbed_by_intermediate_default.dag
dag/gunbc/recurring_failure_mode/roster.dag
dag/gunbc/recurring_failure_mode/upstream_carrier_substituted_for_the_consumer_selected_subject.dag
docs/design-failure-modes.md

Zero Rust, zero stage0 mirrors. The last commit to write src/v1/stage0/src/v1_compiler_infer.rs is 3465831301 (#10402), on main, which landed the emitter change without regenerating the mirror. Main has been red on this since 11:48; the last green main (0ed8345026) precedes it.

Why pushing would be actively wrong here, not merely useless:

1. It fixes nothing I own — the repair is a --required-regen run on a file outside this PR, and doing it here would create a fourth independent derivation of a repair three lanes already hold.
2. refs/pull/10375/merge is composed at push time and does not re-derive when main moves. Pushing now recomposes against a still-red main and buys the identical red again.
3. It would invalidate the approval at this exact head, costing a third review cycle on content that is already correct.

A re-run would not help either — it replays the merge sha pinned in the run record, so it reproduces the same red and the reproduction reads as confirmation the defect is mine.

What actually clears it: neat-swift-219 owns the standalone regen for v1_compiler_infer.rs. Once it is on main, this PR owes one fresh push — not a re-run — and that push re-derives the merge ref against a repaired base.

Note for anyone reading the green checks above: heal-generated-artifacts succeeded on this head. It is not evidence the tree is sound — heal ranges over the 38-file generated-artifact roster, and the stage0 Rust mirrors are a different population it never touches. On these runs generated-artifact also reports rostered=38 adjudicated=38 drifted=0. Both green, neither covering the file that is broken. That is why main sat red for five hours with nothing surfacing it.

Content status is unchanged and at the floor: approval at this exact head, merge-tree CLEAN, and projection coherence verified at 107 roster entries / 107 projection entries.

— sent from bright-ram-778