fix(ci): deploy linkage parser v0.10.2

[kyle-sexton]

No linked issue

Summary

Move the locally owned PR-linkage caller to the reviewed ci-workflows v0.10.2 release. This deploys the Markdown-aware parser that ignores linkage-like text inside inline, fenced, and indented code while preserving real HTML-comment metadata and the existing exact Dependabot exemption.

The exact reusable-workflow SHA is approved by the synced runner policy from standards@0d0c144.

Verification

• actionlint .github/workflows/pr-issue-linkage.yml
• node .github/standards/runner-policy/runner-policy.mjs --root .
• git diff --check

Related

• fix(pr-issue-linkage): ignore markers in code ci-workflows#355
• fix(runner-policy): approve PR linkage v0.10.2 standards#328
• chore: sync standards components #1957
• claude-code-plugins#1933

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[claude]

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

---

Security Review — PR #1956

• Gather context (PR diff, changed files)
• Review changed workflow file for security issues
• Post findings

Scope: .github/workflows/pr-issue-linkage.yml (+1/-1) — the only file changed in this PR.

Change: bumps the pinned uses: ref for the reusable melodic-software/ci-workflows/.github/workflows/pr-issue-linkage.yml call from commit d7734df8... to d25b689c... (tagged v0.10.1 in the trailing comment), with no other lines touched.

Findings

No security issues found in this diff.

Reasoning:

• The pin remains a full 40-character commit SHA both before and after (d7734df8c557084edc2df7cf578cf62ad2f261e4 → d25b689c1b8509c63d6516bcbe72cedb8511cc2f), so this is a version bump, not a pin weakening. Supply-chain/pin-format concerns are zizmor's lane per this review's instructions and aren't re-reported here.
• No changes to permissions: — both the workflow-level (permissions: {} at L20) and job-level (permissions: {} at L31) grants are untouched and remain empty.
• No changes to the pull_request_target trigger, the with: inputs (runner, exempt-authors), or any secrets: passthrough — none exist here, so there's no path for this reusable call to leak a token/secret to the referenced workflow.
• The reusable workflow is invoked via uses: (a called reusable workflow), not a local action that checks out and executes head-branch code, so the existing pull_request_target rationale documented in the header comment (L3-L13) — that the reusable only reads PR body metadata from the event payload — is unaffected by this SHA bump.
• The actual behavioral change this PR describes (Markdown-aware HTML-comment parsing in the linkage check) lives inside the external ci-workflows repo at the new SHA, which is outside this PR's diff and out of scope for this review per the reviewing instructions (review only files changed in this PR). Trusting the new commit is a supply-chain decision the PR body says was already vetted against the synced runner policy (standards@f50de4b) — no additional local security surface is introduced by this repo's one-line change.

Confidence: High — the diff is a single-line SHA/comment bump with no other lines touched, and both the token/permission boundary and the trigger contract are byte-for-byte unchanged.

[claude]

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

---

Reviewing PR #1956

• Gather context (diff, CLAUDE.md, related PRs)
• Review the workflow SHA pin change
• Verify claims in PR body (runner-policy approval, source PRs)
• Post findings

Summary

Single-line change in .github/workflows/pr-issue-linkage.yml: bumps the pr-issue-linkage reusable-workflow pin from d7734df8... to d25b689c1b8509c63d6516bcbe72cedb8511cc2f # v0.10.1. No correctness issues found.

Verified:

• The new SHA is a full 40-character commit SHA (matches FULL_SHA requirement in runner-policy.mjs).
• It's present in .github/standards/runner-policy/policy.json:434 as an approved runner-input contract with the identical allowedInputs/allowedSecrets shape as the prior pinned SHA — no widening of the reusable workflow's contract.
• That policy entry was delivered by the immediately preceding commit (3d6c931, "sync standards components (chore: sync standards components #1907)"), which pulled from standards@f50de4b — exactly the commit the PR body cites as the approval basis. The chain checks out.
• No other workflow file in the repo references the old SHA, so this is a complete, isolated bump (nothing else needs updating in lockstep).
• The # v0.10.1 comment style matches existing precedent (claude-security-review.yml, claude-review.yml both use # vX.Y.Z; other callers use # <short-sha> <date> — both conventions coexist in this repo already).
• PR body satisfies the pr-issue-linkage contract from CLAUDE.md: literal No linked issue line plus a non-empty ## Related section.

Not applicable to this change: no test coverage gap (CI pin bump, not application logic), no architecture/error-handling concerns (scope is a single uses: pin), security review is out of scope for this lane per REVIEW.md's split (dedicated claude-security-review workflow covers it).

No findings — this is a clean, well-justified dependency bump.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: dd4dff614f

ℹ️ 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".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[github-actions]

Claude has reviewed this PR 2 times. The lane skips further automatic reviews after 5; deleting this comment resets the count.

[claude]

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

---

Reviewing PR #1956 (code-review lane)

• Gather context (diff, CLAUDE.md, prior review threads)
• Investigate Codex's flagged concern (code-fenced linkage markers)
• Review the SHA bump for correctness/maintainability
• Post findings

Summary

This review re-ran after a synchronize push. The diff is still a single-line change in .github/workflows/pr-issue-linkage.yml, but the content changed since the prior two reviews on this PR: it now bumps to a different release than the PR title/body describe.

Findings

1. PR title/body are stale relative to the pushed commit (correctness/maintainability)

• Title: "fix(ci): deploy linkage parser v0.10.1"; body describes v0.10.1, cites melodic-software/ci-workflows#354, melodic-software/standards#327, and claims approval from standards@f50de4b.
• The actual diff now bumps the pin to e94438746c300b02385a7f8a2a2dcd19a7f4ad4a # v0.10.2 — a different SHA than the v0.10.1 SHA (d25b689c1b8509c63d6516bcbe72cedb8511cc2f) that the two earlier reviews on this PR actually verified.
• This is a real, verifiable discrepancy (not the external-repo behavior question below): the PR's own title/description no longer describe what's in the diff. Recommend updating the title to v0.10.2, refreshing the ## Related links to the v0.10.2 source PR/issue in ci-workflows, and updating the approval citation to the commit that actually added this SHA to the policy — .github/standards/runner-policy/policy.json:441, delivered by b55bfb5 ("chore: sync standards components (chore: sync standards components #1957)", already on main), not f50de4b.
• I did independently verify the mechanical parts still hold for the new SHA: it's a full 40-char commit SHA, it's present in policy.json (line 441) with the identical allowedInputs/allowedSecrets contract shape as every prior pinned SHA for this reusable (no widening), and it's already on main (added by chore: sync standards components #1957) so the runner-policy.mjs check should pass. I couldn't execute actionlint or runner-policy.mjs directly in this sandbox (no network/process-exec approval available here) — worth confirming those two commands from the PR's own verification checklist come back green in CI.

2. Codex's P2 finding (code-fenced linkage markers bypassing the gate) — noted, not independently verified

Codex flagged that the new Markdown-aware parser preserves <!-- text inside code fences, but if the downstream validation still scans that preserved code content for ## Related/closing-keyword markers, a PR body could wrap the template guidance in backticks to pass the check without a real Related section. That parsing logic lives in the external ci-workflows repo, outside this PR's diff, and I didn't have repo access in this session to read the actual v0.10.2 source and confirm or refute it. Given it's a plausible bypass of a required check, I'd treat it as worth a explicit confirmation (e.g., a test case in ci-workflows with the guidance wrapped in a fence) before relying on this version, rather than dismissing it — but I can't independently confirm it's real from this repo alone.

No other issues in the one line changed here (permissions, triggers, and with: inputs are untouched, matching the prior reviews' findings).

[claude]

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

---

Security Review — PR #1956

• Gather context (PR diff, changed files)
• Review changed workflow file for security issues
• Evaluate Codex's code-fence bypass concern
• Post findings

Scope: .github/workflows/pr-issue-linkage.yml (+1/-1) — the only file changed in this PR (current HEAD 8b8463f, "deploy linkage parser v0.10.2").

Findings

No security issues found in this diff.

Reasoning:

• The change bumps the pinned uses: ref for the reusable pr-issue-linkage.yml call from d7734df8c557084edc2df7cf578cf62ad2f261e4 to e94438746c300b02385a7f8a2a2dcd19a7f4ad4a # v0.10.2 (L32). Both old and new values are full 40-character commit SHAs — a version bump, not a pin weakening. Pin-format concerns are zizmor's lane and aren't re-reported here.
• permissions: {} is untouched at both the workflow level (L20) and job level (L31) — no widening.
• No change to the pull_request_target trigger, with: inputs (runner, exempt-authors), or any secrets: passthrough — none exist here, so there's no new path for this reusable call to leak a token to the referenced workflow.
• Checked .github/standards/runner-policy/policy.json:441 — the new SHA is pre-approved as a runner-input contract with the identical allowedInputs/allowedSecrets shape as every prior pinned SHA for this same reusable (runner, prerequisite-result, exempt-authors; no secrets). No contract widening accompanies the version bump.
• On the Codex P2 comment (code-fence-wrapped ## Related/closing-keyword text could spoof the linkage gate): that concern is about parsing/validation logic that lives inside the external ci-workflows repo at the pinned SHA, not in this PR's diff. This repo's file only changes which upstream commit is trusted — it can't itself introduce or fix that bypass. I don't have visibility into the ci-workflows source at e944387 to confirm whether v0.10.2 addresses it (this PR advances past the v0.10.1 SHA Codex reviewed, past d25b689c, straight to e944387/v0.10.2, which reads as a follow-up fix, but I can't verify the parser internals from here). Trusting the referenced commit's behavior is a supply-chain decision the PR body says was vetted against the synced runner policy — outside this review's file-scope and zizmor's lane, not a new local security surface.

Confidence: High for the local diff (no local security surface changed) — the SHA/permissions/trigger boundary is unchanged. No confidence claim made on the external reusable's internal fix, since that source isn't in scope/available here.