generate-release-cc

# Generate Release Workflow Bump version, build a **complete CHANGELOG** from every commit since the last tag (with PR back-reference and contributor attribution), commit, open a **PR to main** and wait for user confirmation before tagging, publishing, and deploying. > **VERSION RULE: Always use PATCH bumps (3.x.y → 3.x.y+1)** > NEVER use `npm version minor` or `npm version major`. > Always use: `npm version patch --no-git-tag-version` > The threshold rule: when `y` reaches 1000, bump to `3.(x+1).0` — e.g. `3.8.999` → `3.9.0`. > **🔴 INTEGRATION BRANCH RULE**: The `release/vX.Y.Z` branch is the **integration target** for the entire release cycle. Bug fixes and feature implementations land here **via per-issue PRs from short-lived `fix/<ISSUE>-<short>` or `feat/<ISSUE>-<short>` worktrees** (see `/resolve-issues`, `/implement-features`). Contributor PRs from `/review-prs` likewise merge into this branch. The release branch is then merged to `main` via a single release PR at the end of the cycle. --- ## ⚠️ Four-Phase Flow ``` Phase 0 → security audit (npm + CodeQL + Dependabot) Phase 1 → bump → full quality gate → changelog from commits → commit → push → open PR ↕ 🛑 STOP: notify user, wait for PR merge Phase 2 → deploy main to Local VPS for homologation ↕ 🛑 STOP: notify user, wait for OK Phase 3 → tag → GitHub release → Docker → npm → Akamai Phase 4 → monitor CI pipelines and validate artifacts ``` **NEVER push directly to main or create tags before the user confi...