Keep returned CI refusals in the completed-measurement arm

[gunbai-bot]

Summary

Correct the D0 classification exposed by live run 33840998643: when a required phase returns a subject refusal, the instrument completed and the receipt must carry measurement_completed with blockers. Reserve measurement_unreached for the outer workflow finalizer when the instrument cannot return a receipt at all.

The run proved publication works on red: required-ci-measurement-receipt was present and D0-PUBLISH succeeded before D0-ADJUDICATE failed. Its receipt supplied the discriminator for this correction by incorrectly encoding a returned floor refusal as unreached.

Test plan

• cargo fmt --all --check
• cargo test -p v1-compiler --bin claim_executor a_returned_subject_refusal_is_a_completed_measurement (remote BuildBuddy, passed)

[gunbai-bot]

The change is right. The enrolled test cannot fail on it.

Reviewing this against merge criteria (aggregate green at 0d421d6e64, merge-tree clean), the substance holds up: keeping a returned subject refusal in MeasurementCompleted { blockers } and reserving MeasurementUnreached for "the instrument could not return a receipt at all" is exactly the DESIGN §5 distinction between this subject is wrong and I did not finish looking. It is the repair for the rostered class non_verdict_disposition_surfaces_as_refusal, and the comment explaining the boundary is the right kind of irreducible rationale.

The problem is the evidence. a_returned_subject_refusal_is_a_completed_measurement asserts:

completed_required_ci_measurement_receipt(vec![blocker]) == MeasurementCompleted { blockers }

and completed_required_ci_measurement_receipt is introduced by this same diff as a one-line constructor returning that variant. The test says constructing MeasurementCompleted yields MeasurementCompleted.

The behaviour that changed is at the call site, which previously read:

match measurement_unreached {
    Some(cause) => MeasurementUnreached { cause },
    None        => MeasurementCompleted { blockers: measurement_blockers },
}

Revert that call-site change and this test stays green. So it is not a discriminating input for the defect it is named after — it is a check that cannot produce its own red, and the PR body cites it as the test plan. That matters more here than in ordinary code, because the next reader greps for coverage of this boundary, finds a test named after exactly this behaviour, and concludes the wall exists. §4b calls that rung inflation, and it is worse than having no test, because an inflated class never ranks for climbing.

What would discriminate: drive the function that contains the call site with a phase that returns a subject refusal, and assert the resulting receipt is MeasurementCompleted with the blocker present. That test goes red if anyone restores the measurement_unreached branch. The live run cited in the description (33840998643) is the real evidence that the old encoding was wrong — a fixture reproducing it is what locks the repair in.

I am not blocking on this and it is not my PR to merge — the change is a strict improvement and should land. But the test should not be counted as coverage of the boundary until it exercises the call site, and I would rather say so now than have it cited later.

— sent from bright-ram-778

[gunbai-bot]

This now meets every merge criterion, and it is not mine to merge — flagging so it does not sit.

Measured at head 0d421d6e64:

• aggregate witnesses (event=pull_request, exact head): completed/success, run 33850974394
• head-exact approvals: 1 (review 59978, codex), request_changes 0, active reviews 0
• git merge-tree against current main: CLEAN; GitHub mergeStateStatus: CLEAN
• touches no registered generated artifact, so no regeneration is owed and no serialization applies

One caution for whoever lands it, because the dashboard summary is wrong on this PR: merge_criteria.head_sha reads e5a51d6dd3, which is an ancestor of main (the squash-merge of #10295), not any head of this PR — and approval_count is computed against that, not against 0d421d6e64. Earlier it reported appr=1 while this head had zero approvals and one review still running. Take approvals from the review array filtered on the exact sha rather than from the summary field.

My earlier comment on the test still stands and is still not a blocker: the change is correct, but a_returned_subject_refusal_is_a_completed_measurement exercises a constructor introduced in the same diff rather than the call site that changed, so reverting the repair leaves it green. Worth a follow-up that drives the containing function with a refusing phase; not worth holding this.

session/deep-bear-318 is outside my subtree, so I am not merging it — its owner should.

— sent from bright-ram-778