[kyle-sexton]

No related issue: registers the pr-review-cli contract at ci-workflows v0.64.2 so claude-code-plugins' review callers can repin to it.

Summary

Registers pr-review-cli.yml@6d6cb798e7cb7560a0f9327d8a22398961c23b31 (ci-workflows v0.64.2).

Fix

v0.64.2 changes only how pr-review-cli's steps read the GitHub API (ci-workflows#869): the PR file list is read once instead of three times, and pulls.get twice instead of three times. Inputs, secrets and routing are unchanged, so the contract copies the v0.64.1 entry forward verbatim.

Verification

• node --test runner-policy.test.mjs in components/runner-policy: 340 pass, including the new copy-forward test.

Related

• Same shape as #851 (v0.64.1).

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	🔄 Running since 2026-10-23T15:28:48.888605Z	c633798	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[github-actions]

claude-review reviewed c633798ca6f019e861211a1b961a54a51e827ecf: 0 finding(s), 0 as inline comments.

No findings.

Scope. The PR adds one approvedReusableWorkflowContracts entry to components/runner-policy/policy.json: pr-review-cli.yml@6d6cb798…. It also adds a copy-forward test in runner-policy.test.mjs.

What I checked.

• I read the new entry (lines 836–856) next to the v0.64.1 entry (lines 815–835). Routing, fixedRunsOn, all 11 allowedInputs and both allowedSecrets entries are identical, so the "copies forward verbatim" claim holds for the file as committed.
• The new test uses deepEqual against the v0.64.1 entry and asserts exactly one key ends in the new SHA. It would fail if the entry drifted or were duplicated.
• The new entry sits after the v0.64.1 one and matches the layout of earlier entries.
• No hold class applies: there is no model or spend change, no trust-gate path, and no security finding.
• No closing issue exists (the PR states "No related issue" with a reason), so there are no acceptance criteria to check. The PR body follows the contract.

Unverified.

• I did not confirm that ci-workflows v0.64.2 (6d6cb798…) really leaves the workflow's inputs, secrets and runner routing unchanged. That claim comes from the PR body, and I did not fetch the upstream ref.
• I did not run the test suite. The "340 pass" figure is the author's claim.

[github-actions]

claude-security-review reviewed c633798ca6f019e861211a1b961a54a51e827ecf: 0 finding(s), 0 as inline comments.

Security review: PR #853 at c633798

No security findings.

critical-findings: 0

Changes reviewed

• components/runner-policy/policy.json adds an approved reusable-workflow contract for pr-review-cli.yml pinned at 6d6cb798… (v0.64.2).
• components/runner-policy/runner-policy.test.mjs adds a test that this entry deep-equals the v0.64.1 entry and that it appears exactly once.

What I checked

• The new entry matches the v0.64.1 entry (9aca743c…) at policy.json lines 815–835 and 836–856. The routing is hosted-only on ubuntu-24.04, the allowedInputs list is identical, and the two secrets map to the same REVIEWS_* repository secrets. It adds no input, no secret, no runner option and no wider routing.
• The new entry pins a full 40-character commit SHA, not a tag or branch, so the approval can't drift.
• The test pins the SHA and asserts parity with the prior entry, so a later divergence would fail CI.

Not verified

• I couldn't confirm that 6d6cb798… is the v0.64.2 tag, or that it changes only how pr-review-cli.yml reads the GitHub API, as the test comment claims. The gh api compare against ci-workflows was not run because it needed approval. The PR's CI and reviewers should confirm the SHA against the tag.
• The PR touches none of the trust-gate paths: trusted-actors, check-trusted-trigger, CODEOWNERS and .gitmodules. It touches no plugin manifest and no standing instruction, so neither the manifest lines nor the instruction-surface lens applies. No hold.