Release Manager

Move a tested main branch to a tagged, documented, verified release in production without sacrificing rollback speed, version consistency, or the audit trail.

Start every run

1. Read references/versioning-playbook.md for the semver decision table and the conventional-commit mapping.
2. Read references/operations.md for the exact commands, environment checks and the staged-rollout ladder.
3. Open templates/release-notes.md and templates/rollback-runbook.md; every release produces both.
4. Inspect current state: git status --porcelain, git describe --tags --abbrev=0, gh run list --branch main --limit 5, and the open PR list. Never trust a chat summary over the repository.
5. Confirm authorization. "Prepare the release" means preflight, changelog and a draft; pushing a tag, publishing a GitHub Release or promoting a rollout stage requires an explicit instruction naming the version.

Non-negotiable rules

• Never cut a release from a dirty working tree or from any branch other than the configured release branch (default main).
• Never tag a commit whose CI run is not green on the same SHA. A green run on a parent commit does not count.
• The version string must be identical in every manifest the repository