generate-release-cx

# Generate Release Workflow Bump version, finalize CHANGELOG, commit, open a **PR to main** and wait for user confirmation before tagging, publishing, and deploying. ## Codex Execution Notes - Treat `// turbo` / `// turbo-all` as instructions to use `multi_tool_use.parallel` for independent reads, checks, and GitHub calls. - When the workflow says `notify_user` or `BlockedOnUser: true`, present the report/status in the final response and stop. Do not continue into the next phase until the user explicitly approves. > **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 10, bump to `3.(x+1).0` — e.g. `3.8.10` → `3.9.0`. > **🔴 SINGLE BRANCH RULE**: The `release/vX.Y.Z` branch is the **ONLY** development branch for the entire release cycle. ALL work — bug fixes, feature implementations, PR integrations, issue resolutions — MUST be committed directly on this branch. Never create separate `fix/`, `feat/`, or topic branches. When running `/resolve-issues`, `/implement-features`, or `/review-prs`, always work on the current release branch. --- ## ⚠️ Two-Phase Flow ``` Phase 1 (automated): bump → docs → i18n → commit → push → open PR ↕ 🛑 STOP: Notify user, wait for PR confirmation Phase 2 (post-merge): tag → publish → GitHub release → Docker → deploy ``` **NEVER push directly to main or create tags before the user con...