creating-releaseslisted

# Creating releases Releases here are cut with `gh` from the CLI — never the GitHub web UI — and the notes are a PRODUCT SURFACE, not a changelog dump: a future daemon/agent will quote them verbatim to convince users to upgrade (that's the plan behind the VersionBadge and #18). Write them for that reader. ## Mechanics (in order) 1. `python3 scripts/bump_version.py X.Y.Z` — keeps the four version files in sync (pyproject, uv.lock, dashboard/package.json, plugin.json); NEVER bump by hand, drift once shipped a stale plugin (issue #7). 2. Commit the bump (`chore: release vX.Y.Z`), tag `vX.Y.Z`, push both: `git push origin main vX.Y.Z`. 3. `gh release create vX.Y.Z -R noisy/noisy-coding --title "…" --notes "…"`. 4. The tag triggers the release workflow (verify-version gate + Docker image with provenance). Watch it (`gh run list --workflow=release`) and confirm the tag appears on Docker Hub BEFORE telling the user to update — the image takes ~3-4 min; the marketplace needs no build. 5. Then follow the `after-production-release` skill: spoken one-liner + minimal refresh checklist derived from what changed. ## Version number - PATCH — fixes, invisible changes. - MINOR — anything the user can see or a new capability; big visible UI batches are MINOR too (2.8.0 was a UI overhaul). - Krzysztof calls the number; suggest one, don't tag until he says. ## Release notes — the format that matters ``` ## Highlights > The section an upgrade-nudging agent should qu