fix(ci): harden release workflow per CodeRabbit review

[himerus]

Summary

• Scope write permissions to release job only; CI jobs get read-only access (security hardening)
• Pin release Node version to 22 instead of lts/* to match tested matrix
• Add concurrency group to serialize releases per ref (prevents race conditions)

Addresses all 3 CodeRabbit review comments on PR #30.

Test plan

• CI passes on this PR
• Verify release.yml YAML is valid
• Confirm release job has write permissions, CI jobs have read-only

🤖 Generated with Claude Code

Summary by CodeRabbit

• Chores
  • Updated release workflow with improved concurrency configuration.
  • Upgraded Node.js to version 22 for builds.
  • Refined workflow permissions for enhanced security.

[coderabbitai]

Note

.coderabbit.yaml has unrecognized properties

CodeRabbit is using all valid settings from your configuration. Unrecognized properties (listed below) have been ignored and may indicate typos or deprecated fields that can be removed.

⚠️ Parsing warnings (1)

Validation error: Unrecognized key(s) in object: 'version'

⚙️ Configuration instructions

• Please see the configuration documentation for more information.
• You can also validate your configuration using the online YAML validator.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Walkthrough

Modified GitHub Actions release workflow: added top-level concurrency configuration, adjusted top-level permissions (contents from write to read), granted targeted write permissions to release job, and pinned Node.js version from lts/\* to 22.

Changes

Cohort / File(s)	Summary
Workflow Configuration .github/workflows/release.yml	Added concurrency group with cancel-in-progress disabled. Demoted top-level contents permission from write to read. Introduced job-level permissions block granting write access to contents, issues, pull-requests, and id-token. Pinned Node.js version to 22 in setup-node step.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~7 minutes

Possibly related PRs

• feat(ci): semantic-release automated publishing pipeline #22: Directly modifies the same .github/workflows/release.yml file with identical changes to concurrency, top-level/job permissions, and Node.js version pinning.

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description provides a clear summary of changes and test plan, but does not follow the repository's PR template structure with sections like Type of change, Related issue, Tests added, or Checklist.	Restructure the description to follow the repository template, including Type of change (Bug fix), Related issue (#30), Tests added section, and completed Checklist items.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly describes the main change: hardening the CI release workflow based on CodeRabbit review feedback, which aligns with the changeset's security and configuration improvements.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feature/fix-chain-release-after-ci

---

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

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/release.yml:
- Around line 15-17: The workflow-wide concurrency block is preventing new runs
from starting until the entire previous CI+release finishes; move the
concurrency key into the release job so only publishing is serialized.
Specifically, remove or delete the top-level concurrency block (concurrency,
group: release-${{ github.ref }}, cancel-in-progress) and add an equivalent
concurrency block under jobs.release (i.e., jobs: release: concurrency: group:
release-${{ github.ref }} cancel-in-progress: false) so build/test jobs can run
concurrently while the release job remains scoped and serialized.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 08e64262-db47-4467-902c-a2bf5dd9c775

📥 Commits

Reviewing files that changed from the base of the PR and between 3cc6e31 and f45c127.

📒 Files selected for processing (1)

• .github/workflows/release.yml

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Scope concurrency to the release job instead of the whole workflow.

At this level, every new main run waits for the previous run’s full CI and release sequence to finish. If the goal is only to prevent concurrent publishes, move concurrency under jobs.release so newer build and test jobs can start immediately.

Suggested change

-concurrency:
-  group: release-${{ github.ref }}
-  cancel-in-progress: false
-
 permissions:
   contents: read

 jobs:
@@
   release:
+    concurrency:
+      group: release-${{ github.ref }}
+      cancel-in-progress: false
     needs: [build, test, lint, format, audit]
     runs-on: ubuntu-latest

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/release.yml around lines 15 - 17, The workflow-wide
concurrency block is preventing new runs from starting until the entire previous
CI+release finishes; move the concurrency key into the release job so only
publishing is serialized. Specifically, remove or delete the top-level
concurrency block (concurrency, group: release-${{ github.ref }},
cancel-in-progress) and add an equivalent concurrency block under jobs.release
(i.e., jobs: release: concurrency: group: release-${{ github.ref }}
cancel-in-progress: false) so build/test jobs can run concurrently while the
release job remains scoped and serialized.