release-tag

Take the repo from "ready" to a clean, tagged, pushed release. Releases are outward-facing and effectively irreversible once published, so every step is gated by pre-flight checks and explicit confirmation. ## Hard rules: never break these - **Never release a dirty or unverified tree.** Working tree clean, on the correct branch, up to date with the remote, and tests/CI green; all true before tagging. - **Tags are immutable once published.** Never move or overwrite a pushed tag; if a release is wrong, cut a new patch version. Force-retagging breaks everyone who already pulled. - **Follow SemVer honestly.** The bump must reflect what actually changed (see Step 2), not a convenient number. - **Confirm before the commit, the tag, and the push.** These are the irreversible, outward-facing actions. - **No AI/co-author trailers** in the release commit or tag message. - **Publishing is downstream.** Tagging ≠ publishing to a registry. Don't run `npm publish` / `cargo publish` / etc. unless explicitly asked; most pipelines publish from CI on tag. ## Step 1: Pre-flight - `git status` → clean tree (or stash/commit deliberate changes first). - On the release branch (usually `main`/`master` or a `release/*` branch) and synced: `git fetch && git status` shows up to date. - Latest tag and history since it: `git describe --tags --abbrev=0`. - Tests, linters, and build pass locally; CI on the release commit is green. ## Step 2: Determine the version Derive the SemVer bump from the commi...