releasing

# Release Tag and publish a new version with rich, narrative release notes. ## Step 1: Pre-flight Run in parallel: ```bash git branch --show-current # Must be main git status --porcelain # Must be clean git log origin/main..HEAD --oneline # Must be empty (all pushed) ``` **If any fail:** report and stop. Run `make check` — all must pass. ## Step 2: Determine Version Get the last tag: ```bash git describe --tags --abbrev=0 ``` Parse `$ARGUMENTS`: - If a semver like `2.4.0` → use it directly - If `patch` / `minor` / `major` → bump the last tag accordingly - If empty → analyze commits since last tag to suggest: - `feat` commits → minor - Only `fix`/`docs`/`refactor` → patch - Breaking changes → major - Present suggestion, ask user to confirm The version is `X.Y.Z` (no `v` prefix in display). The git tag is `vX.Y.Z`. ## Step 3: Generate CHANGELOG ```bash git cliff --tag vX.Y.Z --output CHANGELOG.md ``` ## Step 4: Craft Release Notes Read the FULL diff since the last tag to understand every change: ```bash git diff <last-tag>..HEAD -- '*.py' '*.yml' '*.toml' git log <last-tag>..HEAD --format="%H %s" ``` Also read any PR descriptions referenced in commits: ```bash gh pr list --state merged --search "is:merged" --limit 20 --json number,title,body ``` Now write release notes following this structure and style (study existing releases for tone): ### Style Rules 1. **Lead with a theme headline** — one sentence summarizing what this re...