release-cutlisted

# Release cut Promote previous cut; create, document, deploy next. **Kind** procedure · **Used by** [releaser](../../agents/releaser.md) · **When** the workspace's release cadence says to cut, or a human asks for one · **Ends with** a promoted previous release, a new branch + pre-release, merged release notes, a QA plan issue, a pre-production deploy, and an announcement waiting for the human's go-ahead Use profile release/branch/deploy facts. No cadence means not applicable. Write once; non-2xx stops. No blind retry, force-push, moved tag, direct protected-branch push, or production deploy. ## 1. Promote the previous release — after checking its tag still describes it Before promotion, check branch drift: ```bash git fetch <remote> --tags git log --oneline <prev-tag>..<remote>/<prev-release-branch> # post-cut cherry-picks ``` A non-empty list means the tag no longer describes what shipped, and promoting it leaks those cherry-picks into the **next** changelog, which is generated from that tag. **A cherry-pick onto a release branch is a re-cut**: tag the branch head with the next counter and promote that. Record the tag you promoted — it is `<prev-tag>` for steps 2 and 3. Skip the step when there is no prior pre-release. ## 2. Cut the branch and create the pre-release Branch from current default, push branch, tag with generated changelog from `<prev-tag>`. Read it back. Earlier-release entries mean stale start tag: recreate; never hand-edit. ## 3. Release notes