releasinglisted

# Release procedure Pick the bump per semantic versioning: **patch** for bug-fixes only, **minor** for any new user-visible feature, **major** for breaking changes that require user or operator action. Use today's date, read from the shell (`date` or `Get-Date`) rather than from memory: a wrong date in a release heading is public and permanent once the tag is pushed. ## 0. Read the repo profile first Read `Lock:` and `Docs language:` from the `## Repo profile` section of the repo's root `CLAUDE.md`, exactly as `committing` step 0 describes, including its fallback when the section is missing (infer, confirm once, write the four-line marker yourself). The lock decides whether you cut the release on a feature branch through a pull request or straight on `main`. The docs language decides the wording of the CHANGELOG bullets and of the Release notes. ## 1. Pre-flight: run the `committing` checklist A release ships the docs, not just the code, so before bumping anything run the `committing` pass over everything since the last release (the range `<last-tag>..HEAD`, with `<last-tag>` from `git describe --tags --abbrev=0`; on a first release, with no tag yet, the pass covers the whole history): confirm the docs are current and that no change left an existing doc stale, update any `CLAUDE.md` the work invalidated or extended, and prune comments to the strictly useful. Then make sure `[Unreleased]` is complete: every user-visible change since the last tag has a bullet, there are no