[kyle-sexton]

No related issue: prerequisite contracts that unblock the automated claude-lanes repin in #715.

Summary

Registers the nine ci-workflows reusables at the v0.38.2 tag
cf316d12b4a14fbdb96a339b7ad00ce935a8cad4 in
components/runner-policy/policy.json. Without these entries, the automated repin
#715 fails check-policies. The sync job's routing reads needs, and
pr-review/pr-review-security carry reviewed allowedCallerPermissions
grants, so their new SHA cannot be auto-approved.

Fix

• policy.json: nine new keys. Each body is a verbatim copy of its 2531d56
  (v0.38.1) entry, text-spliced (121 insertions, 0 deletions). A JSON comparison
  confirms each copy equals its source.
• README.md: review note for v0.38.2.

v0.38.2 adds ci-workflows#696 and #697 on top of v0.38.1. Together they touch only
pr-require-checks.yml, its aggregate-results action, a test and the README.
All nine registered workflow blobs are byte-identical between 2531d56 and
cf316d1 (confirmed with git rev-parse <sha>:<path>). No input, secret, caller
permission or runs-on routing moved. The 2531d56 entries stay until every
consumer repins.

Verification

• git diff --stat 2531d56 cf316d1 in ci-workflows: only the six files above.
  Blob comparison of the nine reusables: all identical.
• npm run test:runner-policy: 297/297 pass. npm run lint:runner-policy: pass.
• With chore(claude-lanes): re-pin callers to ci-workflows v0.38.2 #715's patch applied on top locally, npm run test:runner-policy passes
  297/297 (previously 4 failures in CI), and CI_REPOSITORY_VISIBILITY=public npm run lint:runner-policy passes.
• Pre-commit hooks pass: markdownlint, biome, typos, gitleaks, editorconfig.

Related

• chore(claude-lanes): re-pin callers to ci-workflows v0.38.2 #715 (repin this unblocks)
• feat(runner-policy): add ci-workflows v0.38.1 contracts #713 (same change for v0.38.1)

🤖 Generated with Claude Code

https://claude.ai/code/session_01S6P1ZfQhbydBZNKz2LUfnf

---

Generated by 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	✅ Completed 2026-10-06T03:04:17.503685Z	14a5a89	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.

[claude]

Claude finished @kyle-sexton's task in 1m 41s —— View job

---

Security review complete — no issues found

• Gather context (PR diff, changed files)
• Review components/runner-policy/policy.json changes
• Review components/runner-policy/README.md changes
• Check instruction-surface deletions (none — purely additive diff)
• Post final findings

Scope: components/runner-policy/policy.json (+121/-0) and components/runner-policy/README.md (+5/-0), diffed against origin/main.

Findings: none.

This PR only adds nine new keyed entries to policy.json, registering the existing nine ci-workflows reusables at the v0.38.2 tag cf316d12b4a14fbdb96a339b7ad00ce935a8cad4, plus a corresponding README note. It is purely additive — zero deletions in either file, so the instruction-surface-deletion lens doesn't apply.

I verified the PR's own claim by diffing each new entry against its 2531d56 (v0.38.1) counterpart already in the file:

• intake-triage.yml, pr-review.yml, pr-review-security.yml, intake-label-needs-triage.yml, pr-scan-dependencies.yml, maintenance-sync-standards.yml, pr-audit-workflows.yml, pr-automerge-dependabot.yml, pr-run-checks.yml — each new @cf316d1... entry's allowedInputs, allowedSecrets, and allowedCallerPermissions/minimumCallerPermissions are byte-identical to its @2531d56... source entry. No new secret references, no widened caller permissions (notably pr-review.yml/pr-review-security.yml, which carry id-token: write, are unchanged), no new runs-on/routing behavior.

GitHub Actions hardening concerns (pinning, trigger types, expression injection) are zizmor's advisory lane per this review's scope and are not re-reported here; nothing here touches workflow trigger types or run: blocks regardless.

[claude]

Claude finished @kyle-sexton's task in 2m 43s —— View job

---

Review: feat(runner-policy): add ci-workflows v0.38.2 contracts

• Gather context (diff vs origin/main, policy.schema.json, prior v0.38.0/v0.38.1 README entries)
• Verify the PR's core claim: each new @cf316d12b... entry is a verbatim copy of its @2531d56a... sibling
• Check README prose follows the established per-release pattern and schema conformance
• Scope security findings out (this repo runs pr-review-security, per REVIEW.md)
• Post findings

Independently verified:

• Programmatically diffed all 9 new policy.json entries against their 2531d56 counterparts (key-for-key, value-for-value via jq) — confirmed byte-identical except the SHA in the map key, matching the PR's claim.
• Confirmed exactly 9 old-SHA and 9 new-SHA contract keys exist (no missing/extra entries, no duplicate keys).
• README.md addition at components/runner-policy/README.md:1116 follows the exact same structure as the existing v0.38.0 (README.md:1088) and v0.38.1 (README.md:1108) paragraphs for this lockstep-registration pattern.
• Schema (policy.schema.json) requires routing/runnerInput/allowedInputs/allowedSecrets on runnerInputContract entries; all new entries satisfy this (inherited, since they're exact copies of already-valid entries).

Not independently verified (author-claimed only): the external ci-workflows repo diff between 2531d56 and cf316d1 (that pr-require-checks.yml/aggregate-results are the only files touched, and that all nine workflow blobs are byte-identical) — I don't have access to that repository from this sandbox, so I can't confirm it beyond what's stated in the PR description. The npm run test:runner-policy / lint results in the PR body are also author-claimed; I wasn't able to execute them here (command execution wasn't approved in this environment).

No correctness or maintainability findings. This is a mechanical, additive data registration that mirrors prior lockstep PRs (#713 and the v0.38.0 precedent) exactly, and the one load-bearing claim I could check — that the new entries are true verbatim copies — holds up under direct comparison.

[github-actions]

claude-security-review has reviewed this pull request through 14a5a89; a later push is reviewed from there.

[github-actions]

claude-review has reviewed this pull request through 14a5a89; a later push is reviewed from there.