ci(release): add release-please automation

[parth0025]

Summary

Adds release-please for automated SemVer bumps, CHANGELOG generation, git tags, and GitHub Releases. Step 4 of the open-source repo maintenance baseline initiative (#207 license, #208 branching, #209 lint).

Builds directly on the Conventional Commits enforcement from #209 — every feat/fix/perf/etc. commit on main becomes a line in the next changelog entry.

What happens after this lands

staging  (active dev — feat/fix PRs land here)
    │
    ▼
  main  (after staging → main promotion PR merges)
    │
    ▼
 release-please runs ──► opens "Release PR":
                          chore(main): release v14.1.0
                            • CHANGELOG.md gets new [14.1.0] section
                            • package.json: 14.0.26 → 14.1.0
    │
    │  maintainer reviews & merges the Release PR
    ▼
  🚀 git tag v14.1.0 created
  🚀 GitHub Release published with changelog body
  🚀 package.json + CHANGELOG.md committed to main

Files changed (4, all new)

File	Purpose
release-please-config.json	Tool config: tracks root package only, SemVer rules, CHANGELOG section visibility (user-facing types shown, engineering types hidden)
.release-please-manifest.json	Anchors current version at 14.0.26 (matches existing v14.0.26 git tag)
.github/workflows/release.yml	Runs googleapis/release-please-action@v4 on push to main + workflow_dispatch for manual triggering
CHANGELOG.md	Bootstrapped with v14.0.26 baseline; release-please appends future entries above

Decisions documented

Decision	Choice	Rationale
Tool	release-please	Industry standard for OSS Node; maintainer-gated (matches BRANCHING.md's on-demand promotion model); zero npm deps
Scope	Root package.json only	Frontend (8.36.0) versioning stays independent. Can add as second component later
Trigger branch	main (not staging)	Releases cut from main after staging promotion, per BRANCHING.md
Versioning	Strict SemVer — feat → minor, fix → patch, BREAKING CHANGE → major	Standard for Node OSS
Changelog visibility	feat, fix, perf, refactor, docs, revert shown; ci, chore, build, test, style hidden	Reduces noise in user-facing changelog
Action version	Tag-based (@v4)	Matches existing main.yml style
Pre-releases	Disabled	Can enable per package later if you want beta channels
npm install required?	No	Action runs entirely on GitHub runners. package.json is not touched

⚠️ Caveat — branch protection token

When branch protection is enabled on main (per #208), the default GITHUB_TOKEN may not be able to push the Release PR if 1-approval-required is enforced. Two options to handle this once protection is on:

1. Recommended: add the release-please bot to the bypass-allowlist in branch protection rules
2. Alternative: create a Personal Access Token (PAT) with repo scope, store as RELEASE_PLEASE_TOKEN secret, and replace ${{ secrets.GITHUB_TOKEN }} in release.yml

Either way, this is a one-time post-merge setup.

⚠️ First release will be a big one

The first time release-please runs (after the next staging → main promotion), it will scan all 235+ Conventional Commits since v14.0.26 and generate one large changelog. That's expected — every commit between the existing tag and the new HEAD becomes a line. Subsequent releases will be small per-cycle.

Test plan

• After merge, push a test commit to main → release-please workflow should trigger (verify in Actions tab)
• A Release PR should appear titled chore(main): release v... with version bump + CHANGELOG diff
• On Release PR merge: verify git tag is created, GitHub Release appears with changelog body, and CHANGELOG.md is updated on main
• Verify package.json version is bumped on main (and that bump didn't get bumped twice somehow)
• Trigger workflow_dispatch manually from Actions tab → confirm same behavior

Compatibility

✅ Does NOT touch existing main.yml deploy workflow — runs alongside.
✅ Does NOT add any npm dependencies.
✅ Does NOT conflict with PRs #207, #208, #209 — all touch different files.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: f07b683e-484e-4182-a9c1-72316910b82b

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

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch ci/release-please

---

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