[kyle-sexton]

No related issue: registers the reviewed contract for the ci-workflows v0.65.15 release.

Summary

This PR registers the ci-workflows v0.65.15 intake-triage.yml contract at 30b251532b2e9f7e0c4215e1dee5be0d3c688743, so callers can pin to that release. The release makes priority labels exclusive in the triage apply step (ci-workflows#896).

Fix

• policy.json: the v0.65.15 intake-triage.yml entry copies its v0.65.13 (ba7af78d291f10bd75651857a0db2357c23df0fe) entry forward. The earlier pins stay.
• README.md: one sentence about the v0.65.15 contract.
• runner-policy.test.mjs: a test that the v0.65.15 entry equals the v0.65.13 entry and that exactly one contract sits at the new sha.

Verification

• node --test components/runner-policy/runner-policy.test.mjs components/claude-lanes/repin-policy-lockstep.test.mjs passes 392 of 392; npm run lint:runner-policy passes.
• Parsed with a YAML library, on.workflow_call inputs, secrets and outputs and every job's permissions: are identical between v0.65.13 and v0.65.15, except the floor-label input description ("applied exactly one" became "picked exactly one"). Input names, types, defaults and required flags are unchanged. The description edit is what makes the auto-approval surface diff report "inputs changed".
• Left out: every other workflow, which this PR does not register.

Related

• ci-workflows#896 is the change this release ships.
• #885 registered v0.65.14, and this PR follows the same shape.

🤖 Generated with Claude Code

[github-actions]

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

No findings. The new intake-triage.yml@30b2515… entry in policy.json is textually identical to the existing @ba7af78… (v0.65.13) entry: same inputs, secrets and caller permissions. The test asserts that equality and that exactly one contract sits at the new SHA. The README sentence matches what the entry does. The PR body meets the contract (No related issue: line plus all four sections). No closing issue exists. Paved-path rows, path-scoped rules and plugin manifests did not apply to this diff.

Not independently confirmed: the author-claimed test run (392/392), the lint run, and the claim that the upstream v0.65.15 workflow's inputs, secrets and permissions match v0.65.13. I had no sandboxed way to run them or fetch the upstream workflow. I checked the policy.json entry by reading it, and only the diff text for the test and README changes.

[github-actions]

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

Security review: PR #891 (head 5c4c9a9)

No security findings.

critical-findings: 0

Scope. The PR touches three files in components/runner-policy/: README.md, policy.json and runner-policy.test.mjs. It adds an approvedReusableWorkflowContracts entry for intake-triage.yml@30b251532b2e9f7e0c4215e1dee5be0d3c688743 (ci-workflows v0.65.15).

What I checked.

• I compared the new entry in policy.json (lines 468–494) line by line with the existing v0.65.13 entry at ba7af78d… (lines 441–467). They are identical: the same routing, role, allowedInputs, allowedSecrets and allowedCallerPermissions (contents: read, issues: write).
• The entry grants nothing new. It adds no input or secret, widens no caller permission, and leaves routing unchanged.
• The README note and the new test both state the same "copy forward unchanged" claim. The test asserts deep equality with the previous entry and exactly one entry for the new SHA. That is consistent with the policy diff.
• The new key is a full 40-character commit SHA, not a mutable tag, so the pin stays strict.
• Nothing here touches the trust controls this lane lists: no trusted-actor list, lane-token scope, kill switch, token-broker rules, merge holds, or .github/actions/ change. No instruction surface was deleted or softened, and no plugin manifest changed.

Not verified. I could not confirm from this session that 30b2515… is the commit the v0.65.15 tag in melodic-software/ci-workflows points to. The sandbox blocked my gh api call to that repository. The entry only widens trust to a workflow at that SHA, and its permissions equal the previous approved entry's. So this is a provenance check for the maintainer or the repo's existing pin-validation CI, not a finding.