[kyle-sexton]

No related issue: owner-approved request to make pr-pipeline-sandbox a sync target

Summary

This adds melodic-software/pr-pipeline-sandbox as a standards-sync target. The sandbox is a public test bed for claude-code-plugins' PR-pipeline lanes. It already carries hand-copied claude-code-plugins payloads under .github/standards/, and those copies have drifted from main: runner-policy is at schemaVersion 4 with fast-uri 3.1.8, and the dependabot-policy and github-actions-conventions vocabulary copies are older than main.

Merge waits for the owner's App installation grant. The owner has to add pr-pipeline-sandbox to the melodic-standards-sync installation (144867070) in the UI first, following the github-iac "Standards sync selected-repository procedure" ("Add an existing organization repository": approve the manifest change, grant, then merge). Until the grant exists, the sync's exact-set attestation fails closed by design.

Fix

• distribution/sync-manifest.yml: a new target block between medley and provisioning.
  • Managed: dependabot-policy, github-actions-conventions, managed-files-guard-caller, node-runtime, runner-policy and trusted-actors.
  • Locally owned: claude-review-hosted-caller and claude-security-review-hosted-caller. The sandbox's copies are pr-review-cli variants with a kill-switch job and hold inputs.
  • The lychee non-target note now says the sandbox has no lychee lane, instead of saying it is not a sync target.
• components/runner-policy/runner-policy.test.mjs: records the sandbox's visibility (public) in TARGET_VISIBILITY.
• distribution/README.md: adds the sandbox to the runner-policy consumer list.
• distribution/sync-manifest.test.sh: changes the target count from 14 to 15 and the runner-policy consumer set from six to seven.
• components/code-review-rules/README.md: the sandbox-topic skip no longer says the sandbox is "no convergence target". The filter itself is unchanged, because the sandbox does not take review-instructions.

The first sync would change these files in pr-pipeline-sandbox. Its blobs were compared byte for byte with the standards sources:

• Already identical: .node-version, runner-policy package.json and repository-policy.schema.json, github-actions-conventions vocabulary.schema.json, and both trusted-actors files.
• Updated: runner-policy package-lock.json (fast-uri 3.1.8 to 3.1.9), policy.json and policy.schema.json (schema 4 to 5), and runner-policy.mjs. Also dependabot-policy policy.json and github-actions-conventions vocabulary.json.
• Created: .github/workflows/pr-check-managed-files-hosted.yml.

The sandbox reads runner-policy only as an npm manifest its lanes install. It has no .github/runner-policy.json and no analyzer gate, so the schema 5 policy changes no gate result there.

Verification

• bash distribution/sync-manifest.sh validate: Manifest valid: 47 components, 15 targets.
• bash distribution/sync-manifest.sh plan --targets melodic-software/pr-pipeline-sandbox: 13 mappings over the six managed components. The two locally-owned callers are reported as not modified.
• harness/shell/run-tests.sh distribution/sync-manifest.test.sh: pass.
• harness/shell/run-tests.sh components/managed-files-guard/managed-files-guard.test.sh: pass. This includes the hosted caller's paths union, which stays unchanged because the sandbox's destinations are a subset of claude-code-plugins'.
• harness/shell/run-tests.sh components/code-review-rules/code-review-rules.test.sh: pass.
• npm run test:runner-policy: 226 pass, 0 fail.
• All of the above were re-run after merging origin/main (refactor: rename conventions/ to standards/ #930).

Related

• The paired github-iac PR adds the sandbox to the documented selected-repository set.
• Follow-up in pr-pipeline-sandbox, not done here: the header of its .github/workflows/pr-check-managed-files.yml says "The sandbox is not a sync-manifest target". That comment becomes stale once this merges.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VcupojYKhHyDni9LuAXBuX

[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-31T05:44:55.555142Z	ea435e6	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 needs no new review of 5e967f430c44b99d30f1a6abb46d43dffea7e825: every file in scope matches docs-only-paths.

Security review: PR #933 (head ea435e6)

No security findings.

critical-findings: 0

I read the full diff with gh pr diff 933. The wrapper supplied no diff, PR-context or settled-threads files, so there was no settled-thread dropping and I used the default trusted-path globs. I did not check the sandbox repository's visibility: that gh api call needed approval and I skipped it.

What changed: melodic-software/pr-pipeline-sandbox becomes a sync target in distribution/sync-manifest.yml. It takes six managed payloads: dependabot-policy, github-actions-conventions, managed-files-guard-caller, node-runtime, runner-policy and trusted-actors. Its two review callers are locally-owned. The rest of the diff is docs and test expectations (target count 14→15, runner-policy target list, TARGET_VISIBILITY entry, README wording).

Trust-control check (trusted-actors sync):

• The sync writes components/trusted-actors/trusted-actors.json into the sandbox as .github/standards/trusted-actors/trusted-actors.json.
• The list contains only the owner, its bots and its GitHub Apps, which matches the owner threat model.
• The diff changes no trusted-actor entry and no check-trusted-trigger logic, token scope, kill-switch read or merge hold. Nothing here widens who is trusted.
• I could not read the sandbox's current copy of the list. If it was narrower than the canonical list, the sync would widen it, but only to the owner's own actors. That is no part-2 impact (no leak, compromise or charge), so it is not a finding.
• managed-files-guard-caller is the same hosted-only payload every public target carries.

Other checks:

• No new secrets, tokens, workflow triggers or permissions: changes. The diff has no .github/workflows or .github/actions changes.
• No plugin manifest changes, so there are no manifest <field> lines.
• No instruction-surface deletions. The AGENTS/REVIEW-style rules are untouched, and the README edit only rewords a prose rationale for the sandbox topic filter, which still excludes the repo from review-instructions.
• The TARGET_VISIBILITY entry marks the sandbox public in the runner-policy test. I did not verify the repo's actual visibility. A mismatch would make the test fail, not open a security path.

Owner threat model note: the diff removes or weakens none of the named friction holds.

[github-actions]

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

Incremental review of distribution/README.md since ea435e6. I found no issues, so I reported no findings.

The change makes the consumer-adoption paragraph exempt pr-pipeline-sandbox. It says the sandbox takes the runtime only as the npm manifest its PR-pipeline lanes install, runs no runner-policy gate, and defers adoption until it gains one.

I checked that this matches the rest of the PR:

• The sandbox stays in the "exactly these enrolled targets" list (distribution/README.md:206). That matches expected_runner_policy_targets in distribution/sync-manifest.test.sh:693, the TARGET_VISIBILITY entry in components/runner-policy/runner-policy.test.mjs:5716, and the sandbox block in distribution/sync-manifest.yml.
• The manifest comment above that block says the sandbox has "no repo-local .github/runner-policy.json or gate job yet, so the handoff in distribution/README.md is not done there". The new wording says the same.
• No closing issue applies, because the PR body states No related issue. I did not run any tests; the PR's verification claims are the author's and I did not verify them.