Release

Run local checks:

cargo clippy --all-targets --all-features -- -D warnings
cargo test --all

If checks fail, stop and report the errors.

Determine the new version:

# Get current version from server/Cargo.toml
CURRENT=$(grep '^version = ' server/Cargo.toml | head -1 | sed 's/version = "\(.*\)"/\1/')
echo "Current version: $CURRENT"

# Use cargo-release to calculate new version
cargo release version <LEVEL> --dry-run 2>&1 | grep -o '[0-9]\+\.[0-9]\+\.[0-9]\+'

Create release branch:

NEW_VERSION="X.Y.Z"  # from step 3
git checkout -b release/v${NEW_VERSION}

Bump versions using cargo-release:

cargo release version <LEVEL> --execute --no-confirm

Update CHANGELOG.md:

• Move items from "Unreleased" section to new version section
• Add release date
• Create new empty "Unreleased" section

The changelog should follow Keep a Changelog format. Ask the user if they want to review/edit the changelog before proceeding.

Commit changes:

CRITICAL: The commit message MUST start with release: v (no other words before the version). The tag-release.yml workflow matches startsWith(message, 'release: v') on the merge commit. When GitHub squash-merges a single-commit PR, the commit message becomes the merge commit message.

git add -A
git commit -m "release: v${NEW_VERSION}"

Push and create PR:

git push -u origin release/v${NEW_VERSION}

gh pr create \
  --title "release: v${NEW_VERSION}" \
  --body "$(cat <<EOF
## Release v${NEW_VERSION}

This PR prepares the release of v${NEW_VERSION}.

### Changes
- Version bump across all crates
- Changelog update

### After Merge
The release workflow will automatically:
1. Create git tag \`v${NEW_VERSION}\`
2. Build and publish release artifacts
3. Bump to next development version (\`-alpha.0\`)

---
See CHANGELOG.md for details.
EOF
)"

Report the PR URL to the user.