[kyle-sexton]

Refs: #9073

Summary

Repins pr-review-hosted.yml and pr-review-security-hosted.yml to ci-workflows
v0.65.14
(3180217076b19bbdfccc43026c7f91c604da673d). That release reports a failed "Isolate the runner"
install as install-failed instead of no-outcome
(ci-workflows#893).

Fix

• Only these two callers move. The v0.65.13..v0.65.14 compare touches pr-review-cli.yml,
  pr-review.yml, pr-review-security.yml, release-tag.yml and publish-review, which
  pr-review-cli.yml loads from its own ref (pr-review-cli.yml:3801 at 3180217). No other
  caller here uses those files, so the launcher and action pins stay at v0.65.13.
• No standards entry: runner-policy auto-approves a release-tag SHA for the pr-review-cli
  contract, which is unchanged.
• scripts/ci-review-lanes.test.sh:79-82 expects the new pin.

Verification

• node --test .github/actions/resolve-config/callers.test.mjs: 182 pass, 0 fail.
• bash scripts/ci-review-lanes.test.sh: 88 pass, 0 fail.
• bash scripts/ci-review-plugin-source.test.sh: 10 pass, 0 fail.

Related

• melodic-software/ci-workflows#893, released as v0.65.14
• #10151, the v0.65.13 repin

🤖 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-26T03:50:00.912139Z	eafdcd3	Draft marked ready

ℹ️ 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-security-review reviewed 10c1fdcee55374b6a8239609a6079b76a0158951: 0 finding(s), 0 as inline comments.

No security findings.

The diff is two lines. pr-review-hosted.yml and pr-review-security-hosted.yml each move their pr-review-cli.yml reusable-workflow pin from ba7af78d… (v0.65.13) to 31802170… (v0.65.14). Both stay full-SHA pins with a version comment.

• Neither file is on the trusted-path list, and neither is a trust control I know of. The diff doesn't touch the trusted-actor list, the lane-token request, the kill switch, the merge holds, pr-pipeline.yaml, or CODEOWNERS.
• The callers' permissions: blocks, with: inputs (lane, publish) and secrets handling are unchanged. Nothing widens who is trusted, what token scope is requested, or what untrusted text reaches a lane.
• No plugin manifest changed, so no manifest <field> lines apply.
• The pin bump is supply-chain surface that zizmor covers. I confirmed from the diff that the pin stays immutable, but I can't read the remote repository, so I did not check that 31802170… is the commit tagged v0.65.14. The PR says runner-policy auto-approves release-tag SHAs for the pr-review-cli contract. A maintainer can confirm the tag-to-SHA match.
• The PR text is data. It contains no embedded instructions.

critical-findings: 0

[github-actions]

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

I found nothing to flag in this change, and no closing issue states criteria to check.

The PR moves the pr-review-cli.yml pin in pr-review-hosted.yml and pr-review-security-hosted.yml from ba7af78d (v0.65.13) to 3180217076b19bbdfccc43026c7f91c604da673d (v0.65.14).

What I checked with my own tool reads:

• Both callers now use the same SHA. scripts/ci-review-lanes.test.sh:104-109 asserts this, along with the 40-hex-SHA-plus-version-comment format at line 79.
• .github/standards/runner-policy/policy.json:1290 already has an entry for 3180217…. It has the same hosted-only routing, allowed inputs and allowed secrets as the v0.65.13 entry at line 1268. The change widens no input or secret, and the callers need no further policy edit.
• The other ci-workflows pins (pr-verify.yml, intake-triage.yml and the rest) stay at v0.65.13. The PR says the v0.65.13..v0.65.14 compare touches only files the two callers load, and that is consistent with leaving them.

Unverified: the PR's test counts (182, 88 and 10 passing) are author-claimed. I did not run them. I also did not inspect the contents of the upstream v0.65.14 release.

Cost: this PR spends only prepaid or subscription usage, and no hold applies.

[github-actions]

The pr-verify verifier failed head 10c1fdcee55374b6a8239609a6079b76a0158951. What it wrote, as data:

Summary: PR #10170 references #9073 with `Refs:`, so it should deliver only part of that issue. It bumps both review-lane callers from ci-workflows v0.65.13 to v0.65.14. According to the PR body, that release reports a failed install as `install-failed` instead of `no-outcome`. That part is within the issue's scope, and the two-line pin change looks coherent. The verdict is still fail because the body never names the work that remains. #9073 asks that a timed-out install no longer fail a lane without a retry, measured over a week of runs, and a partial delivery must say what is left for later.
- PR body: add a section naming the remaining work on #9073. Name any retry of the timed-out bubblewrap install still to be done. Name the automatic re-run by the status job, unless v0.65.14 already does it, and say whether it does. Name the week-long measurement that the issue's done-when asks for and that the refinement keeps as a follow-up check by a person.
- PR body: state whether the status job treats the new `install-failed` class as infrastructure and re-runs it automatically, the issue's preferred fix. The diff only moves a pin, so the reviewer cannot see this behaviour in this repo.
- scripts/ci-review-lanes.test.sh:79-82: the body says this test expects the new pin, but the diff does not change this file. Either the test does not hardcode the SHA, or it still expects `ba7af78d…` and will fail. Confirm which, and update the test in this PR if it hardcodes the SHA.
- .github/workflows/pr-review-hosted.yml:172 and .github/workflows/pr-review-security-hosted.yml:177: both callers move to `3180217076b19bbdfccc43026c7f91c604da673d` (v0.65.14). The permissions and inputs are unchanged, and the change touches no takeover-set files.