ci: keep the judge changeable, and let ordinary pull requests merge

[The01Geek]

A policy-update change: it modifies the verification workflow itself, so it lands on
its own, judged by the verifier currently on main rather than by the one it installs.

An adversarial audit of the cutover plan found two defects, both of which would have
taken effect the moment distribution-verify became the required status check.

1. The judge could never be changed again

The policy-update/* ceremony documented for changing the verifier existed only in
prose. In code, the branch exemption fired solely when no part of the judge was on
base. Once installed, every pull request touching it would fail — including the ceremony
meant to change it. The repository would have been permanently unable to update its own
verification logic except by an admin bypass or by removing the required check, i.e. the
exact controls this design exists to tighten.

There is now an arm for it. The control is that such a branch is judged by the
previous base verifier and requires human review — not that the diff is forbidden.

2. Any ordinary pull request would have been unmergeable

Once a release lands, main carries .release/files.sha256, and the verifier reports a
digest mismatch for every edited file. A README typo or a community patch would have
failed the required check with no way to pass it.

Full artifact verification is now scoped to what is actually being published — a
release/* branch, or a push to main. An ordinary pull request is exempted with a
stated notice rather than silently skipped.

Why now

The pending release candidate carried these fixes, and the base-equality rule correctly
refused it: a release must not change its own judge. Landing them here first means the
release can then carry judge bytes identical to base, which is precisely what lets it
be judged by a verifier it cannot modify.

[prflow-implementer]

/prflow:review

[github-actions]

PRFlow Review — PR #2141

Status: ✅ Reviewed
Diff profile: small_diff + config_only (Phase 1+2 skipped intentionally)
Run: View run
Reviewed HEAD: 053f403
Last updated: Phase 4 complete

Blueprint

• Phase 0.5 — diff classified
• Phase 1/1.5 — checklist (skipped: small_diff + config_only)
• Phase 2 — verification (skipped)
• Phase 3 — review agents returned
• Phase 4 — verdict aggregated
• Terminal completion

Verdict: APPROVE WITH ADVISORY NOTES (shell-correct, CI-green cutover; one behavior-inert comment falsehood and one intentional security-boundary tradeoff to note before merge)

The change adds two guarded early-exit arms to distribution-verify.yml: (1) a policy-update/* head-ref arm that skips the judge-unchanged loop so the verifier can be intentionally changed, and (2) a ${GITHUB_EVENT_NAME}:${HEAD_REF} arm that runs full artifact verification only for pull_request:release/* or push:*, exempting ordinary pull requests. Both arms are shell-correct and their case patterns are exhaustive for the workflow's push/pull_request triggers, both fail safe on an unmatched event (fall through to full verification), and arm 1 is correctly placed after the bootstrap/partial-judge integrity guards. All required CI checks (including distribution-verify itself) are green on the reviewed head.

Issue Compliance

No related issue found — requirement compliance not checked; scope not-established.

Verification Checklist Results

Checklist skipped intentionally (Phase 0.5: small_diff + config_only — a deliberate low-risk-diff engine profile, not a failure). No caveat applies (rule 4b).

Code Review Findings

🟠 Important / Major

1. Arm 2 defers all artifact verification for ordinary pull requests to the post-merge push run. This workflow is its own repository's "required status check on main", yet after this change every non-release/* pull request hits pull_request:*) … exit 0 and never runs verify-release.py; the only path that verifies the digest manifest for a normal change is the push:* event, which fires after the merge has landed. So a pull request that corrupts or falsifies .release/files.sha256 / .release/source.json passes the required PR check green and is only caught post-merge on main. This is the intended tradeoff (an ordinary PR would otherwise digest-mismatch every edited file once a release lands), and the push:* run is a genuine backstop — so the defect is eventually caught — but the merger should (a) confirm main branch protection tolerates a window where a push-verify failure lands on main unreverted, and (b) consider making the skip notice state that verification is deferred to the post-merge push run rather than reading as "verified". (raised by 1/4 agents) [suspected over-grade: shape 3 — single-source from silent-failure-hunter, no corroboration; observable fail-direction is post-merge detection with a real push:* backstop, milder than a Critical]

🟡 Suggestion / Minor

1. The added comment "The control here is that such a branch is judged by the PREVIOUS base verifier and reviewed by a human" is false against HEAD. For a same-repo pull_request event, GitHub Actions runs the workflow definition (and inline run: scripts) from the head/merge ref, not the base branch — so the new escape-hatch arm is what executes, and the branch is judged by its own modified verifier plus human review, with no base verifier running. This is directly evidenced by this PR's own distribution-verify: success: on the base main verifier the judge-unchanged loop would have failed on the changed distribution-verify.yml, so a green result is only reachable via the head arm self-exempting. The claim is a documented_falsehood, but it is behavior-inert — the shell arm behaves identically whether the comment is true or false (first-conjunct held), no tool parses the comment to decide behavior (limb-one held: the only distribution-verify references in the suite are name-membership pins), and the workflow ships to no external consumer (limb-two held: not copied by install.sh/vendor-slice) — so the Phase 4.1.5 behavior-inert prose cap caps it at Suggestion and it does not gate the verdict. It is still genuinely wrong and worth fixing: reword to describe the actual control (this arm deliberately permits the judge diff and relies on mandatory human review of the policy-update/* PR), or move the ceremony rationale to internal docs. Note the pre-existing header comment (line 8, not in this diff) carries the same mistaken model. (raised by 1/4 agents) [inertness: first-conjunct=held limb-one=held limb-two=held; evidence: grep of lib/ scripts/ install.sh .github/ found only name-membership pins in lib/test/run.sh (Make the cloud-tier workflow runner configurable via a DEVFLOW_RUNNER variable (enable self-hosted runners) #582/Shipped skill bodies point at the repo-internal matcher probe, and no lint can see it #1402) and a doc mention in verify-release.py; no install.sh/vendor-slice copy of distribution-verify.yml]
2. The first added comment block is 6 physical lines and is rationale/derivation prose ("Without this arm the judge becomes permanently unchangeable…"), exceeding the prevention-only three-line ceiling for workflow/YAML comments. Trim to at most three lines naming the concrete wrong change the arm prevents; relocate the derivation to internal docs. (raised by 1/4 agents)
3. The second added comment block is 5 physical lines and is derivation/worked-example prose ("Once a release has landed, main carries .release/files.sha256 and EVERY edited file…"), likewise exceeding the ceiling. Trim to at most three lines stating the prevented wrong change. (raised by 1/4 agents)
4. Arm 1 reduces the sole automated judge-integrity control to a branch-name check — naming a branch policy-update/* fully disables the judge-unchanged loop via exit 0. This is by design (the compensating controls are that a same-repo pull_request cannot alter the running gate at merge time in the way the design assumes, plus mandatory human review), so no change is required, but the dependency on genuinely-mandatory review of policy-update/* PRs is now load-bearing and should be explicit in branch protection. (raised by 1/4 agents)

over-grade annotation: one finding flagged (Important arm-2 finding — shape 3, advisory only; does not change the verdict).
truthfulness sweep: one finding classified (the arm-1 rationale comment; routed to the Phase 4.1.5 behavior-inert prose cap, not the self-contradicting-diff carve-out — capped at Suggestion, no REJECT).
intra-diff contradiction scan: no contradiction found (the diff's "every… fails" / "EVERY edited file…" phrases describe the prior broken state and the scoping rationale, with no contradicting same-symbol limitation note).

Verdict Criteria applied

• Phase 1+2 intentionally skipped (small_diff + config_only) → rule 4b: no caveat.
• No verification-checklist FAIL/INCONCLUSIVE (checklist skipped).
• The one documented_falsehood is behavior-inert (Phase 4.1.5 cap) → capped to Suggestion, outside the self-contradicting-diff carve-out, drives no REJECT at the critical threshold.
• No finding at or above the critical verdict threshold → rule 6: APPROVE with (advisory) notes.

Notes for the consumer / gotchas

• The policy-update/* cutover rests the judge-integrity guarantee on human review rather than an automated check; the false "base verifier" comment (Suggestion 1) risks a maintainer under-scrutinizing exactly these PRs. Fixing that comment is the highest-value follow-up even though it is non-blocking.
• Verification-evidence advisory: this is a standalone human/policy PR with no linked issue or workpad, so the Verification evidence: marker advisory is out of scope (no durable implement-run surface to read).

[prflow-reviewer]

Verdict: APPROVE WITH ADVISORY NOTES — full report in PR comment

The complete review report (checklist results, findings, details) is in the
PRFlow Review progress comment on this PR.