ci: add the distribution verification workflow and its verifier - #2139
Conversation
Lands before the release so the judge exists on the protected base branch: a release candidate must carry verifier and workflow bytes identical to base, so a pull request cannot modify the thing evaluating it. The workflow enforces that comparison itself. Adds two files and changes nothing else. Requests only contents: read, needs no secrets, and treats candidate content as data - it imports, sources and executes nothing from the tree under review. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
… non-candidate tree The base-comparison step could never be satisfied by the pull request that adds the judge, and a tree without .release/ metadata - the normal state of main before the first generated release - was treated as a failed candidate. Bootstrap is accepted only when no part of the judge is on base and the branch is policy-update/*; a release/* branch missing provenance still fails hard. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ntories Adding a workflow file obliges updating every inventory that enumerates the workflow set, in the same change: #582 the three-way partition must cover every .github/workflows/*.yml; distribution-verify is plugin-internal, never shipped to consumers #1402 the never-shipped set is the copy-loop complement, so it gains the same entry #936 verify-release.py names devflow-review.yml in its forbidden-workflow set, which is a surviving reference to a deleted workflow and belongs in that machine-consumed inventory These three literals are the drift-proof record of the workflow membership; leaving them stale would silently widen or narrow what the audit covers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…rify The #1402 set is asserted at two sites - once over the real sources and once with /dev/null sources to prove the print flag never consults them. Both carry the membership literal, so both move together or the second goes red alone. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
/prflow:review |
PRFlow Review — PR #2139Status: ❌ REJECT Blueprint
Findings (live)
Completeness-critic (Phase 3.1.5): FORBIDDEN_WORKFLOWS ⊇ independent workflow enumeration; REQUIRED_DIRS matches vendor-slice.sh; check_manifest/check_digests are genuine bidirectional set-equality — no finding. Verdict: REJECT — a diff-added comment states a false universal (self-contradicting diff), and the new 434-line security-boundary verifier ships with zero testsIssue ComplianceNo related issue found — requirement compliance not checked. (PR body cites #582/#936/#1402 as context, not Verification Checklist Results17 passed, 1 failed, 0 inconclusive — 0 via lite probe, 18 via agent.
✅ Passed items (17 of 18) — click to expand
Code Review Findings🔴 Critical
🟠 Important / Major
🟡 Suggestion / Minor
over-grade annotation: finding flagged — Critical #2 (shape 3, advisory). Verdict Criteria applied
Run telemetryPer-phase Subagent effectiveness traceIteration 1
|
Add the distribution verification workflow
This is the first of two pull requests in the PRFlow distribution migration. It
adds exactly two files and changes nothing else.
.github/workflows/distribution-verify.ymlmain..github/verify-release.pylib/test/run.shWhy a third file
Adding a workflow obliges updating every inventory in this repository's own suite
that enumerates the workflow set, in the same change:
#582— the three-way partition must cover every.github/workflows/*.yml.distribution-verifyis plugin-internal: never shipped to a consumer.#1402— the never-shipped set is the copy-loop complement, so it gains thesame entry.
#936—verify-release.pynamesdevflow-review.ymlin itsforbidden-workflow set. That is a surviving reference to a deleted workflow and
belongs in the machine-consumed inventory of such references.
No test logic changes; only three inventory literals. Those literals are the
drift-proof record of workflow membership, so leaving them stale would silently
widen or narrow what the audit covers.
Why this lands separately, before the release
The verifier must exist on the protected base branch before it judges anything.
If it arrived in the same pull request as the release, that release would be
installing its own judge — and the workflow's central rule is that a candidate
cannot modify the thing evaluating it.
That rule is enforced mechanically: on every pull request the workflow compares its
own two files against the base branch and fails if either differs. An intentional
change to the verifier therefore lands as its own preparatory pull request, judged
by the previous verifier, exactly like this one.
What it does
.gitand verifies that copy. Candidate content istreated as data: nothing from it is imported, sourced or executed.
paths, file modes, line endings, symlinks, Windows-invalid filenames, case
collisions, size budget, provenance integrity, and relative-link resolution.
contents: read.Effect on this repository today
None. It adds a workflow that passes on the current tree and takes no action.
Nothing about the plugin, its version, its install path, or consumer behaviour
changes here.