The live merge policy was unrepresentable, so no witness could go red on it: model ReportedContextsAtMergeInstant and declare the rung

[gunbai-bot]

Both halves of the main flake were measured. Only one was already declared, and the model was actively wrong about the other — in the direction of strength.

Claim 1 — the required floor's verdict is a property of the runner

Confirmed, and deliberately not re-fixed.

• Of the 25 most recent witnesses.yml runs on main, five reported verdict=FloorRefused with claims_failed=0 and unexpected_failures=0 — the whole refusal carried by interrupted_cpu_deadline and completed_over_cost_requirement. The floor refused main five times without a single claim disagreeing with the tree.
• Nine required-witnesses-floor jobs by runner registration: six failed (srv1-02, srv1-07, srv1-10, srv1-16, srv1-17, srv4-11) and three passed (srv3-02, srv3-04, srv3-10). The honest reading is srv3 is the only host observed clearing the ceiling — specifically not "srv1 is defective", a reading refuted by srv4-11 within the hour.

gunbc.rung_drop floor_cost_claim_qualification_unavailable already declares this class thoroughly and names its own two missing items — a step-denominated line, and the cross-envelope eval_steps identity join. This PR discharges neither, so it adds the verdict-grain and host-grain evidence to the standing row and mints nothing new. Four lanes have already closed on shaving the claim under the ceiling and it fired again tonight: a fifth shave is redundant by construction, and a new row would be a second authority for one fact.

Claim 2 — a PR can merge before its required context reports

Confirmed, and it is the current main break, not a hypothetical.

gunbc#10236 pushed head d8cd3034 at 19:49:33Z, GitHub created its witnesses run at 19:49:40Z, and the merge completed at 19:49:43Z — three seconds after run creation, before any job reported. That run then concluded with required-witnesses-build and required-witnesses-floor both FAILURE. It landed as cfe19ea7, which is the commit that added two duplicate declarations to gunbc.recurring_failure_mode and refused main at resolve.

Not a one-off: over the 40 most recently merged PRs, six had no witnesses run that completed successfully on their own head before merged_at.

And the ruleset is not drifted. Ruleset 16178731 reads back with zero divergence from gunbc.repo_ruleset desired state — active, ~DEFAULT_BRANCH, one required context (witnesses, integration 15368), no bypass visible to the reading token. The converged desired state admits the merge: GitHub's required-status-checks rule decides on the check runs that have reported at the instant of the merge call, and a context with no check run yet is expected, not failing. Absence reads as not-failure — the empty-observation narrow §5 names, one level above where observe_repo_ruleset already refuses it.

What the model said instead

gunbc.merge_lifecycle named PerPrGateOnly "the live policy". PerPrGateOnly as modeled refuses a merge at a head with no receipt — merge_enabled folded policy_admits from init: false, so one caller-local constant answered the absent-receipt question for every policy. The live behavior was literally unwritable, which is why no witness could ever go red on it.

• AdmissionPolicy gains ReportedContextsAtMergeInstant, the live arm. It differs from PerPrGateOnly on exactly one input — the absent receipt — and no other.
• policy_admits_absent_receipt moves that verdict onto the policy. The three receipt-derived policies still answer false, so no existing arm's behavior moves.
• The interleaving witness carries the discriminating pair: a bare MergePr with no preceding RunPrCi latches an unverified tip under the live policy and is refused under PerPrGateOnly and KeyedReceipt; plus a strict inequality on the window-4 counts, so an arm that merely aliased the old one keeps both positive counts and still fails.
• gunbc.rung_drop merge_admission_absent_required_context, TypedDeclaration, previous MechanicallyPreventable, temporary Mitigatable. The trigger names the capability: no head lands on main without a terminal verdict from every required context on the content being merged. Terminal, because heal-generated-artifacts FAILED on XL-0T-CUTOVER: build Y — one exact declaration binding per TypeOccurrence from the containment authority — and retire #9813's module-wide precedence at the root. AUTHORING AUTHORIZED by ruling, MERGE HELD for root-cut receipts. Local use-line/qualification repairs are DEAD. #10236's pull_request run naming those duplicates and was SKIPPED on the main run of identical content — so a trigger reading "every required context reported non-failure" is satisfied by a roster whose catching lane never runs on the branch the defect lands on. The merge queue is named as the expected supplier and explicitly not as the trigger; zero merge_group runs of witnesses.yml exist today.
• gunbc.recurring_failure_mode required_evidence_absent_reads_as_evidence_of_pass: a gate whose admission arm keys on observed failure rather than observed success, so the empty enumeration admits.

The two claims compose

A floor that refuses on a basis that is not a property of the tree teaches its readers that a red required floor is noise. An admission path that merges before the report means acting on that belief costs nothing. Neither half alone lands a broken tree on main. Together they did — and the lanes are cleanly separable in the evidence: on the post-merge main run at cfe19ea7 the duplicates reddened required-witnesses-build while required-witnesses-floor was green.

Not done here, and not a session-level omission

Enabling the merge queue, or making an unreported required context blocking, is a repository setting. The branch-protection and rule-suites endpoints answer 403 to this session's token. It is escalated to the operator and it is declared rather than left silent.

🤖 Generated with Claude Code

https://claude.ai/code/session_017q3jn4AYgCR2x4zMqSxBob

[gunbai-bot]

Witness receipt, executed rather than described. claim_batch --source-root dag --source-root src/v2 --entry dag/test/claim/merge_lifecycle_interleaving_witness_test.dag, all nine witnesses of the module — the four new ones and the five that were already there as regression controls:

PASS a_merge_before_any_run_lands_an_unverified_tip_under_the_live_policy
PASS a_merge_before_any_run_is_refused_under_per_pr_gate_only
PASS a_merge_before_any_run_is_refused_under_keyed_receipt
PASS the_live_policy_admits_strictly_more_unverified_tips_than_per_pr_gate_only
PASS per_pr_gate_only_admits_unverified_tips_in_window_4
PASS keyed_receipt_admits_no_unverified_tip_across_window_4
PASS window_4_enumerates_all_1296_sequences
PASS incident_trace_reds_main_under_per_pr_gate_only
PASS require_up_to_date_base_misses_the_roster_axis_in_window_4

The four pre-existing counts are unchanged, which is the check that policy_admits_absent_receipt moved no existing arm's behavior: the three receipt-derived policies still answer false on the absent receipt, exactly as the fold seed did.

Why the new pair is not green by construction. The two assertions take the same input — a one-event [MergePr { pr: pr_a }], no preceding RunPrCi — and assert opposite verdicts. A policy_admits_absent_receipt that answered true for everything greens the first and reds the second; one that answered false for everything does the reverse. The strict inequality on the window-4 counts is the third leg: an arm that merely aliased PerPrGateOnly would keep both positive counts and still fail there.

Base note. This branch is based on cfe19ea7, which is the broken main — so required-witnesses-build will red on the two duplicate declarations in gunbc.recurring_failure_mode until #10278 lands. That is the same commit this PR's evidence is about. I will merge main once the repair is in and re-run.

[gunbai-bot]

review 59477 — reworked, not argued

The finding is right, and this repository's own doctrine already says so: gunbc.rung_drop standing_rung_drops records exactly this objection against a reusable RungDropStanding -> Bool accessor — "a named predicate beside a coproduct is a second, weaker spelling of the variant the row already carries, and every later caller reaches for the Bool instead of the arm it came from."

So I did not supply a disposition for policy_admits_absent_receipt. I deleted it. The repair is a type, not a second declaration:

• latest_receipt_for now returns MergeAdmissionReceipt? instead of List<MergeAdmissionReceipt>. It already kept at most one receipt — it folded to [r] or [] — so the list was carrying an optional's job, and the caller paid for it with an emptiness test.
• policy_admits now takes MergeAdmissionReceipt?. The absent case is an arm of the one admission decision rather than an accessor standing beside the policy coproduct. There is no second predicate left to dispose of.
• merge_enabled collapses to a single policy_admits call — no fold, no init: seed, no emptiness branch, and the list_length import is gone.

This is a better answer than routing the predicate through a fold, because the fold seed was the thing hiding the verdict in the first place: init: false was one caller-local constant answering the absent-receipt question for all four policies.

Two call sites updated, both in test.claim.merge_admission_witness, now passing Present { value: scenario_pr_x_receipt }.

New static-grain evidence, since policy_admits gained an input domain and a reader auditing it should not have to run a lifecycle to learn what it answers on Absent. The pair takes the same input and asserts opposite verdicts, so an arm answering one constant for every policy greens exactly one of them.

Executed, both modules, after the change:

merge_lifecycle_interleaving   9/9 PASS   (4 pre-existing counts unchanged)
merge_admission                5/5 PASS
  PASS the_live_policy_admits_an_absent_receipt
  PASS the_three_receipt_derived_policies_refuse_an_absent_receipt

The unchanged pre-existing counts are the check that no existing arm's behavior moved.

One defect in my first spelling of this rework, caught locally before pushing: if receipt_is_for_pr_head(...) { Present { value: r } } else { acc } does not typecheck — if branches resolve to incompatible types: Product(MergeAdmissionReceipt) vs Coproduct(Optional). The corpus idiom for folding into an Optional (extdeps.uri, extdeps.llm.claude_setup_token_cli) uses match, and that is what this uses.

on the failing check

heal-generated-artifacts fails, and it is inherited rather than introduced. Reproducing the job's exact command locally (gunbc run --entry dag/gunbc/instruments/generated_artifact_gate.dag --function main_wet) names the cause outright:

error: resolve failed for dag/gunbc/instruments/generated_artifact_gate.dag
  cause: dag/gunbc/recurring_failure_mode.dag:291:1: error: duplicate declaration
         'absence_classifier_default_bucket' in module 'gunbc.recurring_failure_mode'
         dag/gunbc/recurring_failure_mode.dag:293:1: error: duplicate declaration
         'green_reported_over_a_population_the_instrument_does_not_own'

Both names are cfe19ea7's — the head this PR's evidence is about, landed by the very merge-admission gap being modeled here. Neither is the row this PR adds (required_evidence_absent_reads_as_evidence_of_pass). A whole-corpus regen cannot pass on any branch carrying that main, so I am holding the push until #10278 lands, then merging main and re-running rather than pushing a speculative fix.

[gunbai-bot]

Operator ruled; the declaration is now the deliverable — and it is a stall, not a rung drop

Ruling (2026-09-03), on the escalation of claim 2: "Leave the hole open for now - i know merging is not sound." No merge queue, no change to required-context blocking. That makes the declaration the deliverable rather than the fallback, so its carrier matters more than when it was a placeholder — and the carrier I first used was wrong.

Why it is not a rung drop

§4b(3) governs regressions — "a change may lower a rung only by declaring previous rung, temporary rung…". Nothing here lowered anything: GitHub's required-status-checks rule has evaluated reported check runs the same way since ruleset 16178731 was created on 2026-05-09. The capability was never held, so previous: MechanicallyPreventable invents a rung to drop from. That is exactly what the neighbouring row refuses to do for its own subject — floor_cost_claim_qualification_unavailable: "PREVIOUS RUNG: none … that guarantee was never held, and saying it was would be inventing a rung to drop from."

What existed was §4b(1) inflation: this repo's "required lane" vocabulary, and merge_lifecycle's own prose naming PerPrGateOnly the live policy, describing a wall that does not stand for an unreported context. Inflation is corrected by making the live policy representable — which the AdmissionPolicy change does. What remains is a class below its ceiling: a §4b(2) stall.

So gunbc.rung_drop merge_admission_absent_required_context is deleted with its roster entry, and both citations to it swept (zero references remain, checked corpus-wide).

gunbc.guarantee_stall merge_admission_terminal_verdict_stall

• current: Mitigatable, ceiling: StructurallyGuaranteed, blocker: ClimbableButUnbuilt — climbable now, deliberately not built, with the ruling quoted verbatim and dated as informed acceptance by the principal who can actuate. A row reading "we could not fix this" ages into an excuse; one recording a decision taken with the population in view stays revisitable.
• Population is a predicate, not a count. UncountedNotEnumerable — every future merge into main is exposed. The instrument: for a merged PR, did a required witnesses run on its own head reach a terminal verdict before its merged_at. The 6-of-40 is recorded as a reading on a date, explicitly not the population; a set selected by a measurement is a view whose membership is a property of the measurement, and a frozen count is a change detector.
• Trigger is the capability: no head lands on main without a terminal verdict from every required context on the content being merged. Terminal rather than non-failing, because a context with no verdict satisfies "reported non-failure" vacuously. Both candidate artifacts are named (merge queue; blocking unreported contexts) and neither is the trigger — any future claim citing one must state what it was sufficient for.

#9981 came through the other hole

Its witnesses run on its own head completed SUCCESS at 20:26:54Z and it merged at 20:29:53Z — it had its receipt, so it is not this class. That run was created at 19:37:37Z, twelve minutes before cfe19ea7 landed, so it carried a green receipt against a base that had ceased to be the tip and squashed onto an already-refusing tree: stale-base, admitted under PerPrGateOnly, refused under KeyedReceipt as MergeDeniedStaleBase. The line is added to merge_lifecycle as that module's standing instruction directs, rather than escalated.

Two holes, one commit each, forty minutes apart. Separating them is the point: a merge queue closes both, blocking unreported contexts closes only #10236, a current-base rerun closes only #9981.

Executed

guarantee_stall                8/8 PASS  (new row enrolled; below-ceiling and
                                          names-a-trigger both green)
merge_lifecycle_interleaving   9/9 PASS  (4 pre-existing counts unchanged)
merge_admission                5/5 PASS
regen (generated_artifact_gate main_wet)  clean, and at a FIXED POINT —
                                          round 2 produced no drift

heal-generated-artifacts should now pass: its failure was cfe19ea7's duplicate declarations, and main is merged in with that conflict resolved (keeping only this branch's new row and taking main's deletion of the two duplicates, checked at identity grain).