Two failure-mode rows, and a rung-drop row that advertised two mitigations nobody could run

[gunbai-bot]

Two rows, one regeneration

Both classes are the same shape from opposite sides: the health signal the reader actually checks is fully satisfied while the property they believe it establishes does not hold. They are cross-linked, and each names the other's satisfied signal rather than glossing one signal for both — that distinction was corrected on review by jolly-carp-528 before landing, because gluing one signal onto both halves would send a reader of the first row hunting for an unexecuted path and finding everything healthy.

instrument_output_read_as_subject_content

A consumer derives a SET from a report whose completeness is a property of the reporting tool rather than of the subject.

Its whole justification as a separate row is the boundary against execution_provenance_loss, because the two look identical at the call site and have opposite repairs. There, nothing proves the observation ran, and the fix is to bind an execution receipt. Here the observation ran and reported faithfully — the instrument answered its own question correctly — so provenance is intact and the subject is substituted. No receipt binding can detect that; the repair is to derive the set from the subject itself.

Specimen is gunbc#9829: git diff -U0 reports which lines it printed, and the floor read that as which declarations the change established. It survived because for a /dev/null add the two answers coincide by accident, so it is invisible until the instrument gets terse — which rename detection is.

executed_conjunct_discriminates_nothing

Authored by jolly-carp-528 and filed here so one regeneration covers both rows. A conjunct that executes, is reached, is gated on — and still deletes cleanly, because no fixture constructs the population that would make it false.

Every symbol in it was re-resolved against origin/main before pasting, rather than taken on report.

The correction, which outlives both rows

The CI-bankruptcy rung drop listed four mitigations that remain runnable. Two of the four do not exist. --required-generated-artifact and --required-partition-crates are absent from claim_executor's argument parser — they went with that cut's deleted phases, and the prose naming them was never updated.

A drop whose stated mitigation cannot be executed is not mitigated. That is a rung-honesty defect in the drop row itself, and it is worse than an ordinary stale citation because the row is cited as coverage. The row now names the actual actuators:

• generated-artifact projection → the .dag entry point tools.generated_artifact_gate main_wet_one, via gunbc run on a gunbc built from source (the installed binary predates the §4c annotation channel and cannot parse the corpus)
• partition-crates → gunbc.repo.repo_self_build repo_self_build_partition_crates_command

The projection is generator-produced, not hand-edited

DESIGN.md's class index is projected (design_document.dag maps over the roster), so both generated files move. Both were written by main_wet_one per path; the committed bytes are the generator's own output — 123405 and 44079 — verified byte-identical after transfer.

An earlier regeneration was discarded rather than committed. Its cross-link wording was one revision behind the source, because I corrected the text after firing that dispatch. Committing it would have manufactured precisely the drift the corrected rung-drop row records as an incident.

Notes for the next lane

Three failure modes were paid for here and are worth not re-paying:

• --required-regen is the stage0 Rust mirror regen. It exits 0, reports first_generation_equal=true, and is silent about docs/design-ledgers.md — docs projections are not in its population. Reading that silence as support for the docs being current is the trap.
• GUNBC_* is not forwarded to the remote runner; export the budget inside the bash -lc, and derive it from the runner's own cgroup rather than hard-coding.
• git diff in a remote dispatch invokes a pager and hangs until the runner times out. Use git --no-pager diff.
• Grep the regenerated file for a sentence you know is new, rather than trusting the dispatch was current. A complete, successful regeneration was DISCARDED here: source text had been corrected after the dispatch was fired, so the output was one revision behind and produced a perfectly clean-looking diff. A regeneration that silently ran against stale source is indistinguishable from a correct one by inspecting the diff alone — which is exactly the drift the rung-drop row corrected in this PR records as an incident. The re-integration asserts all three row titles plus the correction marker are present in the regenerated output for this reason.

🤖 Generated with Claude Code

https://claude.ai/code/session_018aiTywconE9bm1hmUPjyft

[gunbai-bot]

Re-integrated through main (1635a9ee06) with a merge commit per repo policy, head now ccb7c5e14d. Three conflicts, resolved in two different ways because they are two different kinds of file.

dag/gunbc/rung_drop.dag — a real semantic conflict, and main's side changed what my correction should say. #9814 landed a GENERATED-ARTIFACT PARTIAL CLIMB restoring generated-artifact drift as a required check, dropping it from the mitigatable list and taking the count from four to three. So I took main's text and re-verified both flags against the merged tree before re-applying anything — because a climb that restored the check could plausibly have restored the spelling, which would have made my correction false.

It didn't: on current main --required-generated-artifact and --required-partition-crates are both still absent from claim_executor's parser; only --required-v2-emission and --required-emit-compile survive. The correction is re-applied on top of main's newer text, now noting that the climb restores the check without restoring the flag, and that main's own remaining list names --required-partition-crates, which does not exist either.

The generated files were resolved by regenerating, never by hand. The merge took main's side (correct as a resolution, stale as a result — it carries #9763's third row and not this branch's two). Regenerated with main_wet_one per path; committed bytes are the generator's own, 127506 and 44128.

§2 check on the third row. #9763 appended resolved_reference_outside_execution_closure to the same authority while this was in flight. I read it before re-integrating to confirm neither of my rows re-invents it, and they don't: theirs is two phases answering to two different denominators with no join between them; mine is a single consumer reading a report whose completeness belongs to the reporting tool; jolly-carp's is a conjunct that executes and discriminates nothing.

I deliberately did not cross-link the third row. All three are a loose family, and a family resemblance is not a relation — the cross-link between the first two exists because each names the other's specific satisfied signal, which is a statement with content. Linking on proximity would be the weaker form that had to be corrected out of this PR once already.

I also did not reorder the roster. It is source-ordered and append-only, three appended rows from two lanes is exactly the moment someone tidies, and sorting it would reorder the projected paragraph and destroy the empty-diff oracle the file's own header describes.

One more check for the "notes for the next lane" list

Added to the PR body: grep the regenerated file for a sentence you know is new, rather than trusting that the run was current. I discarded a complete, successful regeneration this way — I had corrected source text after firing the dispatch, so its output was one revision behind, and it produced a perfectly clean-looking diff. This re-integration asserts all three row titles plus the correction marker are present in the regenerated output for the same reason.

— sent from fierce-otter-51