fix(scripts): accept inline-linked changelog headings

[kyle-sexton]

Fixes #2392.

changelog_versions now accepts ( after the closing ], so inline-linked Keep a Changelog headings are visible to --check, --check-order, and --check-preserved.

Verification

• check-changelog-parity.test.sh: 80 checks passed (4 new linked-heading fixtures)

Related

• check-changelog-parity: inline-linked headings are invisible to changelog_versions — absorbing one PASSES (regression vs pre-#2341), and reformatting to that form FALSE-POSITIVES on a required gate #2392 — inline-linked changelog heading parity

[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 41s —— View job

---

Security Review — PR #2411

• Gather context (PR diff, changed files)
• Review scripts/check-changelog-parity.sh regex change
• Review scripts/check-changelog-parity.test.sh additions
• Post findings

No security issues found.

This PR is a single-character-class regex change in changelog_versions() (scripts/check-changelog-parity.sh#L230) that adds ( as an accepted delimiter after the closing ] in a changelog heading, so Keep a Changelog inline links (e.g. ## [1.0.0](https://.../v1.0.0)) are recognized. I traced how the extracted version strings are consumed downstream:

• The output of changelog_versions only ever flows into mapfile arrays, sort/uniq -d, and plain string comparisons (scripts/check-changelog-parity.sh#L242, #L462) — no eval, no unquoted interpolation into a shell command, no awk program text built from the value.
• Where a version is later embedded into an awk match (has_heading, scripts/check-changelog-parity.sh#L587-L592), it's passed via awk -v h="$heading" and matched with index(), not interpolated into the awk source — safe against metacharacter/injection issues regardless of what the new ( branch admits.
• The relaxed regex only widens what character may follow ] (from [[:space:]]/end-of-line to also include a literal (); it doesn't loosen the numeric version pattern itself, so it can't be used to smuggle unexpected content into the extracted version string.
• The new test fixtures (scripts/check-changelog-parity.test.sh#L1103-L1163) operate entirely on local, ephemeral git repos created via the existing mk_repo/git_init test helpers — consistent with the rest of the suite, no untrusted input or network access involved.

This is a self-contained, low-risk parsing fix with no auth, injection, secret-handling, or workflow-permission implications.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 0241953759

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

[claude]

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

---

Code Review

• Gather context (CLAUDE.md, REVIEW.md, PR diff)
• Review scripts/check-changelog-parity.sh regex change
• Review scripts/check-changelog-parity.test.sh new tests
• Post findings

The fix itself is correct: changelog_versions() (scripts/check-changelog-parity.sh:230) now terminates the heading match on (, $, or whitespace instead of just whitespace/$, so a Keep a Changelog heading like ## [1.0.0](https://.../releases/tag/v1.0.0) is recognized. I traced the old pattern by hand against that input and confirmed it fails to match at all (the char after ] is (, which was neither whitespace nor end-of-line), so before this fix the heading was invisible to every mode that calls changelog_versions — not just silently mis-parsed.

🔴 Important — two of the four new test cases don't actually discriminate the fix. Left as an inline comment on scripts/check-changelog-parity.test.sh:1107-1123: the --check and --check-order assertions pass identically whether or not the regex fix is applied, because with zero recognized headings both modes short-circuit to a pass (--check's "ahead of manifest" comparison needs a non-empty newest; --check-order's ordering loop needs >1 versions). Only the two --check-preserved cases (lines 1125-1160) are genuinely regression-proof. See the inline comment for a concrete pair of fixtures (an ahead-of-manifest linked heading, and two out-of-order linked headings) that would make the --check/--check-order coverage load-bearing.

🟡 Suggestion — doc comment not updated. The block at scripts/check-changelog-parity.sh#L217-L227 explicitly enumerates "every heading form this repo actually uses" and the rationale for each accepted variant, but doesn't mention the newly-accepted inline-link form. This file otherwise documents every regex nuance inline (including exactly why over-accepting is preferred to silent gaps), so this is a real gap against the file's own convention rather than a nitpick — not outside this PR's diff (out of the visible hunk), which is why it's noted here rather than inline.

Verification note: I was not able to execute check-changelog-parity.test.sh or run ad hoc grep against the two regexes myself — bash <script> invocations require approval that isn't available in this run. I verified the regex behavior by manual trace instead of execution. The PR body's "80 checks passed" claim is author-reported and unverified by me; if you'd like independent execution, the --allowedTools for this job would need to permit running scripts/*.sh.

No security-relevant surface in this change (shell script logic only, no external input handled unsafely); nothing to hand to the security lane.

Branch: cursor/changelog-linked-headings-63e1

[github-actions]

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