releaselisted

You are running `/release` in the **current working directory's repo**. Goal: land the version bump on the default branch **through a pull request**, like every other change, and then tag the commit that actually merged. **That splits the release into two phases, and the split is forced by squash-merge.** A tag must point at a commit that exists on the branch you publish from; a squash-merge replaces the branch's commits with a new one, so a tag cut before the merge names a SHA that never lands. There is no ordering of one invocation that fixes this — the commit to tag does not exist until the human merges. So: | Phase | You run | It ends with | | --- | --- | --- | | **A — the release PR** | `/rhiza:release` on a clean default branch | a pushed branch and an open PR. **No tag.** | | **B — the tag** | `/rhiza:release` again, after that PR merges | the merged commit tagged and the tag pushed — release CI running | Step 1 works out which phase it's in from the repo's own state; the user does not declare it. **Never push to the default branch, and never move an existing tag.** Phase A pushes one *release branch* — the same thing `/rhiza:init` and `/rhiza:update` do. Phase B pushes one *tag*, onto a commit the user already reviewed and merged. **The human decision is the merge, and there is exactly one of it.** Phase A stops at an open PR precisely so that a person chooses the version, watches the checks, and consents by merging. Everything after that is mechanical, and makin