release

name	release
description	Bump version, commit, tag, and push to remote. Use when user says "release" or "bump version".

You are the release engineer for Panther Minor Controller. Follow this workflow precisely.

Prerequisites

1. Check branch — run git rev-parse --abbrev-ref HEAD. Must be main.
   • If not on main, abort and tell the user to switch to main first.
2. Check for uncommitted changes — run git status --porcelain. Must be empty.
   • If dirty, abort and ask the user to commit or stash changes first.
3. Pull latest — run git pull --rebase to ensure you're up to date.

Version Bump

Ask the user what type of release this is (major, minor, patch). Prefer tool to ask question if available, otherwise ask in the chat.

Wait for their answer. Then bump the version using semver:

Type	Current X.Y.Z	New X.Y.Z
major	X.Y.Z	X+1.0.0
minor	X.Y.Z	X.Y+1.0
patch	X.Y.Z	X.Y.Z+1

Read Cargo.toml to find the current version = "X.Y.Z" line. Update it in-place. Read package.json to find the current version: "X.Y.Z" field. Update it in-place with the new version. Read README.md and update the references to the version in wget download links (sections "Set up the Raspberry Pi", "Install the controller" and "Update the controller").

Commit & Tag

1. Refresh lockfiles after version bump:

   pnpm install
   cargo build --workspace
   

2. Gather all changed files:

   git add $(git diff --name-only HEAD)
   

3. Commit:

   git commit -m "chore(release): vX.Y.Z"
   

4. Create a signed tag:

    git tag -s vX.Y.Z -m "Release vX.Y.Z"
   

5. Push to remote — push sequentially, NOT in parallel:

   git push origin vX.Y.Z
   git push origin main
   

   Push the tag first, then the branch. Running both pushes concurrently can cause the tag to be pushed twice (resulting in "reference already exists") and the branch push to fail. If git push origin main is rejected due to required status checks, wait for checks to complete and retry once. Do not retry more than once.

Confirmation

Report back to the user:

✅ Release vX.Y.Z created successfully.
   - Version bumped in: {list all files that were modified during the release}
   - Committed: chore(release): vX.Y.Z
   - Tagged: vX.Y.Z
   - Pushed to remote

Error Handling

• If the version format is unexpected, abort and ask the user to verify it follows X.Y.Z semver or is approved to be in a different format (e.g., X.Y.Z-beta).
• If git push fails (e.g., remote rejects tag, network issue), inform the user and stop. Do not retry automatically.
• Never auto-approve — always confirm each step with the user before proceeding when the action is irreversible (push to remote).