fix: recognize security: commits as patch-releasing in commit-analyzer

[wyre-agent-fleet]

Discovered exercising the auvik canary (#41, merged 9f0ccf9): squash-merging a security:-titled PR collapses to one commit on main whose header type is 'security', not 'fix' — commit-analyzer's default Angular preset doesn't recognize it, so no release fired despite genuine fix: commits inside the PR. Adds an explicit releaseRules entry (security -> patch). This commit's own fix: type is what should trigger the release once merged, exercising the rule for real.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Advanced

Run ID: a6110f2b-82a6-4ac7-a719-5123409e8c70

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

_{Comment @coderabbitai help to get the list of available commands.}

[asachs01]

Code Review Summary

Verdict: Approve (no blocking issues)

Reviewed by Hermes Agent (automated PR sweep). headRefOid e9287a351d3d632cf32726bb88c3bda2efcefa27

Correctness

• Adds an explicit releaseRules entry (security → patch) to the @semantic-release/commit-analyzer config in .releaserc.json. This is exactly the fix needed: semantic-release's default Angular preset doesn't map a security: commit type to any release type, so squash-merging a security:-titled PR silently produced no release even when the PR contained real fix: commits.
• Scoped narrowly — only adds the missing rule, doesn't touch existing behavior for fix/feat/etc.
• The PR body notes this is validated by having its own commit use fix: type, which should trigger a release once merged — good self-verifying design.

Security

• No secrets, no injection surface — config-only change to release tooling.

Code Quality

• Minimal, well-scoped diff (7 lines added, JSON config only).

Testing

• No dedicated test for .releaserc.json (not unusual for semantic-release configs — the real verification is the next release run). No objection given the low blast radius.

Looks Good

• Clear PR description ties root cause (squash-commit type not recognized) to the fix.
• Change is idiomatic semantic-release config (releaseRules array is the standard extension point).

[asachs01]

Claude Code Review

Verdict: Approve

Small, well-scoped change to .releaserc.json: adds a commit-analyzer releaseRules entry mapping conventional-commit type security to a patch release. This directly matches the stated problem (squash-merged security:-titled PRs weren't recognized by the Angular preset, so no release fired) and is self-validating — this PR's own fix: commit exercises the new rule once merged.

Critical

None.

Warnings

• None found in the diff itself. One thing to watch operationally: this only maps security → patch; if a future security fix warrants minor/major semantics, this static mapping won't distinguish severity. Not a blocker given how narrow the fix is.

Suggestions

• Consider adding a one-line comment in .releaserc.json (or in the CHANGELOG, per repo convention) explaining why security is patch-only, so future maintainers don't "clean up" what looks like a redundant rule.

Looks Good

• Change is minimal, targeted, and directly addresses a real gap (default Angular preset commit-analyzer doesn't recognize security as release-worthy).
• No secrets, no test surface change beyond release tooling config — appropriate given this is release-config-only.

[asachs01]

Code Review Summary

Verdict: Approve (small, correct, self-verifying fix)

Critical

None.

Warnings

None.

Suggestions

• Consider whether other non-Angular commit types used in this org's convention (if any beyond fix/feat/security) should also get explicit releaseRules entries now, rather than discovering each one via a missed release — this PR is itself evidence that undocumented/non-standard commit types silently fall through the default Angular preset.
• The PR body notes this fix's own fix: commit is what should trigger the release once merged — that's a reasonable de-facto verification, but there's no automated test asserting releaseRules parses/matches as expected (e.g. a unit test feeding a security: commit through commit-analyzer's config). Not blocking for a single-line config change to a well-trodden semantic-release plugin.

Looks Good

• Root cause correctly diagnosed: squash-merging a security:-titled PR collapses to one commit whose type isn't recognized by the default Angular preset, so @semantic-release/commit-analyzer didn't fire a release despite real fixes inside.
• The fix is minimal and uses the documented @semantic-release/commit-analyzer releaseRules option correctly — wrapping the plugin name in an array with config object is the standard semantic-release plugin config shape.
• security -> patch is a sensible severity mapping (not minor/major), consistent with how fix is treated by default.
• No new supply-chain risk: this only affects local commit-message classification logic within an already-trusted release pipeline; no new external code/dependency introduced.

---

Reviewed by Claude Code

[github-actions]

🎉 This PR is included in version 1.3.3 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀