cutting-a-releaselisted

# Cutting a session-explorer release ## Overview A release is **two phases**: (1) the version bump + docs land on `main` (normally inside the feature PR that did the work), then (2) a git tag + GitHub release are cut from `main`. Both phases must happen — code can be at the new version while the GitHub tag lags (this has happened: tags lapsed v1.4.0 → v1.10.0 while the files marched on). **SemVer:** `minor` for features, `patch` for fixes. Match the bump to what shipped. ## Phase 1 — bump version + docs (lands on `main`) Every one of these must show the new version. Grep before tagging to prove none lag: ```bash NEW=<x.y.z> # set this to the version you are shipping, e.g. 1.10.1 grep -rn "$NEW" .claude-plugin/plugin.json bin/_pkg/__init__.py README.md SPEC.md CHANGELOG.md ``` **Normal path:** the bump rides along in the same PR as the feature/fix. **If the work already merged to `main` without a bump** (or you're cutting a release of already-merged work): branch from fresh `main`, make the bump-only changes below, open a PR, merge it, then `git pull` before Phase 2. Do not push the bump onto the already-merged feature branch, and don't commit straight to `main` if branch protection is on. | What to update | Where | Note | |---|---|---| | `__version__` | `bin/_pkg/__init__.py` | Source of truth | | `"version"` | `.claude-plugin/plugin.json` | **Easy to forget — must match `__init__.py`** | | Status line | `README.md` (`**vX.Y.Z.** Released and installable…`) | | | St