[kyle-sexton]

No related issue: fleet repin to ci-workflows v0.39.0 in the GitHub Actions conventions migration.

Summary

Moves this repository's repo-owned ci-workflows pins from v0.38.2 (cf316d1) to v0.39.0 (6ba73b97b058602c4dd2bb6e2cce234d11011787), so the fleet runs one release.

Fix

Pin SHA and # v0.39.0 comment, plus repo-owned files that assert the pin (README, check-docs-only-gate.sh). The required check-managed-files job pins v0.39.1 (c586acc), which adds only that action's Dependabot-skip hardening (ci-workflows#709); it is a composite action, so it needs no runner-policy contract. Sync-managed callers and the synced runner-policy contracts are left to the standards sync. No pinned path moved between v0.38.2 and v0.39.0, and no caller-facing input changed for the reusables pinned here.

Verification

• Every repo-owned uses: melodic-software/ci-workflows/... pin is at 6ba73b9 except the required check-managed-files job at c586acc (v0.39.1); every pinned path exists at its commit.
• aggregate-results is byte-identical between cf316d1 and 6ba73b9 (git diff --stat empty), so the hand-verified contract-only predicate note in check-docs-only-gate.sh still holds at the new pin.
• actionlint passes on the changed workflows; the diff touches pin lines only.
• The runner-policy contracts for 6ba73b9 merged in feat(runner-policy): add ci-workflows v0.39.0 contracts standards#732; this PR's runner-policy check passes once the standards sync delivers them.

Related

• feat(runner-policy): add ci-workflows v0.39.0 contracts standards#732 (v0.39.0 runner-policy contracts)
• ci-workflows v0.39.0 release

🤖 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	✅ Completed 2026-10-07T14:12:27.264578Z	529eba0	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 2m 55s —— View job

---

Code review

• Gather context (PR diff, changed files)
• Review each changed file for correctness/consistency
• Verify SHA/version consistency across all pins
• Post findings

This is a mechanical pin bump (v0.38.2 cf316d1 → v0.39.0 6ba73b9) across 7 repo-owned
files. I diffed HEAD~2..HEAD (used in place of origin/main...HEAD: this checkout is shallow
and has no merge base with origin/main) and confirmed every hunk touches only the pin SHA
and/or the # v0.39.0 comment — no other lines changed.

I grepped the whole tree for the old pin (cf316d12b4a14fbdb96a339b7ad00ce935a8cad4 / v0.38.2)
to check completeness. Three callers still carry it:
.github/workflows/pr-check-managed-files-hosted.yml,
.github/workflows/pr-review-security-hosted.yml, .github/workflows/pr-review-hosted.yml.
All three are headed SYNC-MANAGED FILE: DO NOT EDIT IN THE CONSUMING REPOSITORY, and
.github/standards/runner-policy/policy.json is the synced contract file the PR body calls out
— so leaving them for the standards sync matches the stated scope, not an oversight.

One finding, posted inline on scripts/check-docs-only-gate.sh:

• scripts/check-docs-only-gate.sh#L1001:
  the comment there asserts a hand-verification tied to the exact pin (that aggregate-results's
  contract-only default still matches $JOB_GATE token-for-token at the new SHA), and says
  in the same breath that this "must be re-verified whenever that pin moves." This PR moves that
  pin but only swaps the SHA/version text; the PR's Verification section doesn't mention
  re-checking this specific predicate (its "no caller-facing input changed" claim covers the
  composite's documented contract, not this internal detail). Worth confirming the re-check
  actually happened before merge, since a drift here "would turn all-skipped into a pass with
  nothing executed" per the surrounding comment.

Not independently verified (no network/gh/actionlint access in this lane's allowed tools):
the PR's claims that every pinned path exists at 6ba73b9 on ci-workflows, and that
actionlint passes — these are author-claimed, not confirmed by me. If a maintainer wants that
confirmed here, actionlint and gh api would need to be added to this lane's allowed tools.

[claude]

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

---

Security review — no issues found

Scope: PR #6514, head 529eba0e416fd4137e905977e0202790dd67d214. Reviewed all 7 changed files: .github/workflows/intake-label-needs-triage.yml, .github/workflows/intake-triage.yml, .github/workflows/maintenance-audit-test-selection.yml, .github/workflows/pr-automerge-dependabot.yml, .github/workflows/pr-require-checks.yml, README.md, scripts/check-docs-only-gate.sh.

• Gather context (PR diff, changed files)
• Review changed workflow/script files for security-relevant surface
• Check for instruction-surface deletions against protected classes
• Adversarial validation of any candidate findings
• Post final results

Findings

None. Every hunk in this diff is a mechanical repin of the already-pinned, full-length commit SHA for melodic-software/ci-workflows from cf316d1 (v0.38.2) to 6ba73b9 (v0.39.0), plus the matching # vX.Y.Z comments:
pr-require-checks.yml,
intake-triage.yml,
intake-label-needs-triage.yml,
pr-automerge-dependabot.yml,
maintenance-audit-test-selection.yml.
The README.md and scripts/check-docs-only-gate.sh hunks only update a documentation comment's SHA/version reference to match.

Checked specifically for the things in scope for this lane:

• No permission changes — every permissions: block in the diff is unchanged context, not a modified line.
• No new triggers, inputs, or secrets handling — with:/secrets: blocks are unchanged aside from the pin itself.
• No de-pin / loosened supply-chain risk — the pin stays a full 40-character commit SHA on both sides (cf316d12b4a14fbdb96a339b7ad00ce935a8cad4 → 6ba73b97b058602c4dd2bb6e2cce234d11011787); it is not moved to a tag or branch ref. Any residual Actions supply-chain concern here (whether 6ba73b9 itself is the intended, reviewed release commit) is zizmor's advisory lane, not this one, and PR's own verification section notes the pin was checked against feat(runner-policy): add ci-workflows v0.39.0 contracts standards#732.
• No instruction-surface deletion — nothing here removes, narrows, or softens a guardrail, rule, or allowlist/blocklist; the README and script comments are updated pointers to a SHA/version, not a rule being weakened. (docs/conventions/instruction-exception-register/README.md exists in this checkout and was consulted; no protected-class rule is touched by this diff.)

No logic, authorization, injection, or secret-handling surface is introduced or altered by this PR.

[github-actions]

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

[github-actions]

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

[claude]

Code review in progress

• Gather context (PR diff at HEAD d155de2, changed files)
• Review each changed file for correctness/consistency per /review:code-review criteria
• Adversarial validation of any candidate findings
• Post findings

View job run

[claude]

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

---

Security review — no issues found

• Check skip gate (closed PR / no security-relevant surface / already reviewed at this head)
• Gather context (diff between origin/main and head d155de2)
• Review changed files for security-relevant surface
• Check instruction-surface deletions against protected classes
• Adversarial validation of any candidate findings
• Post final results

Scope: PR #6514, head d155de2e2c565a89442426cb9061c8cc0f9ce1ec (the SHA this invocation named; the branch has since advanced to a newer commit with its own, separate change — out of scope here). Diffed origin/main...d155de2e2c565a89442426cb9061c8cc0f9ce1ec: 7 files, matching the PR's stated changed-files list.

Skip-gate finding: this diff is byte-for-byte the same mechanical SHA bump (cf316d1… v0.38.2 → 6ba73b9… v0.39.0, plus matching # vX.Y.Z comments) that claude-security-review already cleared with no findings at commit 529eba0 (see the earlier comment on this PR). The merge commit at this head (d155de2) brought in f9050dd from origin/main, which had independently added the check-managed-files job already pinned to 6ba73b9 (v0.39.0) — so the merge introduced no new pin, no new job, and no diff beyond the same 21 pin-line swaps in
pr-require-checks.yml
and the single-line swaps in the other 6 files. This head has a successful security review that still applies; re-running the full hunt produced nothing new.

Checked specifically, per this lane's criteria:

• No permission changes — every permissions: block in the diff is unchanged context.
• No new triggers, inputs, or secrets handling.
• No de-pin / loosened supply-chain pin — both sides are full 40-character commit SHAs; the move is cf316d1 → 6ba73b9, not to a tag/branch ref. (Whether 6ba73b9 is itself the correct, reviewed ci-workflows release commit is zizmor's advisory lane and out of scope here.)
• No instruction-surface deletion — the one comment-text change in
  scripts/check-docs-only-gate.sh#L1001
  updates a hand-verification note's cited pin; it doesn't remove, narrow, or soften the predicate check itself, so it isn't a protected-class match for this lane (it's already flagged, correctly, as a code-review/verification-staleness finding rather than a security one).

No logic, authorization, injection, or secret-handling surface is introduced or altered by this diff.

[claude]

Claude finished @kyle-sexton's task in 4m 21s —— View job

---

Code review — /review:code-review

• Gather context (diff origin/main...HEAD, changed files, prior review comments on earlier commit 529eba0)
• Review each changed file for correctness/consistency
• Check PR body/title claims against the actual diff
• Post findings

This head (fc0c20b) added one commit beyond the last reviewed commit (529eba0): fc0c20b ("ci: pin the required check-managed-files job to v0.39.1"). The six mechanical pin-bump files (cf316d1/v0.38.2 → 6ba73b9/v0.39.0) are unchanged from the prior review and still touch only pin SHAs/comments — no new issue there.

One finding, posted inline on .github/workflows/pr-require-checks.yml#L2494: the last commit pins the check-managed-files job to c586acc8... (v0.39.1) — a different release than every other pin this PR moves to v0.39.0 (6ba73b9...). That's a deliberate, reasoned bump (closing a Dependabot opener-only-skip bypass per the commit message), not a mistake in the workflow file itself. But the PR body's Summary ("so the fleet runs one release"), Verification ("every repo-owned pin is at 6ba73b9"), and Fix ("Pin SHA and # v0.39.0 comment only") sections were never updated to reconcile with it, so the body now makes a claim the diff contradicts.

Not independently re-verified here (author-claimed, unchanged from the prior review): that every pinned path exists at 6ba73b9 on ci-workflows, and that actionlint passes — this lane has no network/gh/actionlint access.
· branch ci/repin-ci-workflows-v0.39.0

[claude]

Claude finished @kyle-sexton's task in 56s —— View job

---

Security review (incremental)

• Gather context (lane-supplied incremental diff, review scope)
• Read the changed hunk in .github/workflows/pr-require-checks.yml
• Check the trust-boundary conditions the check-managed-files job's own comment names
• Check rationale for the pin bump (commit message)
• Post results

Scope: PR #6514, head fc0c20b739dbbe63a50021c9ba64dc0d9888192f. This lane last reviewed d155de2; per the incremental scope only .github/workflows/pr-require-checks.yml changed since then, and only this hunk:

pr-require-checks.yml#L2497 — the check-managed-files job's Guard managed files step repins melodic-software/ci-workflows/.github/actions/check-managed-files from 6ba73b97b058602c4dd2bb6e2cce234d11011787 (v0.39.0) to c586acc8ea288d728cc7d92f641161eec462fa05 (v0.39.1). All other repo-owned pins in this file (e.g. check-contract at L2531) stay at v0.39.0; that's an intentional single-job bump, not drift — the commit message says v0.39.1 "skips a Dependabot PR only when every commit is a verified Dependabot commit, closing the opener-only skip before synced paths are unowned," i.e. this pin bump itself closes a verification gap rather than opening one.

Findings

None. This is a logic-free pin swap: both sides are full 40-character commit SHAs (not a tag/branch), the surrounding if:, permissions: (contents: read, pull-requests: read), checkout step (fetch-depth: 0, persist-credentials: false), and the job's own documented trust-boundary preconditions ("the action pinned by full SHA, called from this code-owned file, exactly the permissions below, full history, and no paths filter") are all unchanged in this hunk — the version bump doesn't touch any of the conditions that comment says the trust boundary depends on.

Whether c586acc8... is actually the correct upstream commit for check-managed-files v0.39.1 is a supply-chain pin-correctness question (zizmor's advisory lane per this skill's scope), not logic/trust-boundary reasoning, so it isn't re-reported here.

No logic, authorization, injection, or secret-handling surface is introduced or altered by this incremental change.

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
37941187	Triggered	Username Password	d155de2	plugins/testing/benchmarks/browser-tools/lib/cases.mjs	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}