docs: polish RELEASING.md for review feedback and sync SECURITY to 0.2.0

Author: clean6378-max-it

RELEASING.md

@@ -1,16 +1,16 @@
 # Releasing
 
-Manual release flow for claude-code-chat-browser. A release is an annotated git tag plus a GitHub Release with notes. No CI publish workflow, and no wheel, npm package, or other artifact.
+Manual release flow for claude-code-chat-browser. A release is a git tag plus a GitHub Release with notes. No CI publish workflow, and no wheel, npm package, or other artifact.
 
-`v0.1.0` (2026-06-18) is the only shipped tag so far. `v0.2.0` is in progress; these steps describe that cut.
+`v0.1.0` (2026-06-18) and `v0.2.0` (2026-07-30) are the shipped tags so far. The steps below apply to the next cut.
 
 ## Version source
 
 The release version is `__version__` in `app.py` line 3. There is no `pyproject.toml` version field.
 
-`SECURITY.md` line 5 names the version again in the supported-versions blurb (`(currently \`...\`)`). Keep it in sync with `app.py` on every release. `README.md` links to that page for supported versions.
+`SECURITY.md` line 5 repeats that version in the supported-versions blurb. Update it whenever you bump `app.py`. `README.md` points readers at that page.
 
-Between tagged releases, `master` may use a `.dev0` suffix (for example `0.2.0.dev0` while `0.2.0` was in development). The shipped tag drops `.dev0`.
+Between tagged releases, `master` may use a `.dev0` suffix (for example `0.3.0.dev0` while the next release is in flight). The shipped tag drops `.dev0`.
 
 ## Pre-release checklist
 
@@ -20,54 +20,63 @@ Between tagged releases, `master` may use a `.dev0` suffix (for example `0.2.0.d
 
 ## Release checklist
 
-Do the changelog in one PR and the version bump in a second PR, or combine them on a `release/vX.Y.Z` branch. The `v0.2.0` cut used two PRs: changelog first (`docs/changelog-0-2-0`), then the bump (`release/v0.2.0`).
+Do the changelog in one PR and the version bump in a second PR, or combine them on a `release/vX.Y.Z` branch. For `v0.2.0` we used two PRs: changelog first (`docs/changelog-0-2-0`), then the bump (`release/v0.2.0`).
 
 1. Edit [CHANGELOG.md](CHANGELOG.md) ([Keep a Changelog](https://keepachangelog.com/en/1.1.0/)):
    - Move everything under `## [Unreleased]` into a new `## [X.Y.Z] - YYYY-MM-DD` section with `### Added`, `### Changed`, `### Deprecated`, `### Fixed`, `### Removed`, or `### Security` as needed.
    - Leave `## [Unreleased]` empty.
    - Update the footer compare links: `[Unreleased]` → `vX.Y.Z...HEAD`, add `[X.Y.Z]` → `vPREVIOUS...vX.Y.Z`.
 2. On a branch from current `master`, set `app.py` line 3 to the release version without `.dev0` (for example `"0.2.0"`).
-3. Update [SECURITY.md](SECURITY.md) line 5 so `(currently \`...\`)` matches that version (for example `(currently \`0.2.0\`)`). Leave the table at lines 7-10 unchanged.
-4. From the repo root, grep for stale version strings (the previous `.dev0` suffix, the old `SECURITY.md` parenthetical, or any other doc that still names the prior release):
+3. Update [SECURITY.md](SECURITY.md) line 5 so the "(currently ...)" parenthetical matches that version (for example `(currently 0.2.0)`). Leave the table at lines 7-10 unchanged.
+4. From the repo root, grep for stale version strings (`.dev0` suffixes, the old SECURITY.md parenthetical, or the previous shipped release):
    ```sh
-   git grep -nE '\.dev0|\(currently `'
+   PREVIOUS=0.2.0
+   PREVIOUS_ESC=$(echo "$PREVIOUS" | sed 's/[.]/\\&/g')
+   git grep -nE "\.dev0|\(currently \`|${PREVIOUS_ESC}"
    ```
-   Update any hits that should name the new release (for example `docs/deprecation-policy.md`).
+   Point `PREVIOUS` at the release you are replacing (no `v` prefix). Fix any hits that should name the new version (for example `docs/deprecation-policy.md`).
 5. Open a PR, get review, merge to `master`.
-6. Tag the merge commit:
+6. Tag the merge commit (lightweight tag, same as `v0.1.0` and `v0.2.0`):
    ```sh
    git checkout master
    git pull
-   git tag -a vX.Y.Z -m "vX.Y.Z"
+   git tag vX.Y.Z
    git push origin vX.Y.Z
    ```
    Tag format: `vMAJOR.MINOR.PATCH` (for example `v0.2.0`).
-7. Cut the GitHub Release after the tag. From the repo root, extract the body from `CHANGELOG.md`:
+7. Publish the GitHub Release after pushing the tag. From the repo root, extract the body from `CHANGELOG.md`:
    ```sh
    cd "$(git rev-parse --show-toplevel)"
    VERSION=0.2.0   # no leading v; not the literal X.Y.Z placeholder
    VERSION="${VERSION#v}"
    case "$VERSION" in
-     *[!0-9.]*|*.*.*.*|'') echo "error: VERSION must look like 0.2.0" >&2; exit 1 ;;
+     *[!0-9.]*|'') echo "error: VERSION must look like 0.2.0" >&2; exit 1 ;;
+     *..*|.*|*.) echo "error: VERSION must look like 0.2.0" >&2; exit 1 ;;
+     *.*.*.*) echo "error: VERSION must look like 0.2.0" >&2; exit 1 ;;
+     *.*.*) ;;
+     *) echo "error: VERSION must look like 0.2.0" >&2; exit 1 ;;
    esac
    NOTES="$(mktemp)"
    trap 'rm -f "$NOTES"' EXIT
    awk -v ver="$VERSION" '
+     BEGIN { heading = "## [" ver "]" }
      /^## \[/ {
        if (found) exit
-       if ($0 ~ "^## \\[" ver "\\]") { found=1; next }
+       if (index($0, heading) == 1) { found=1 }
      }
      /^\[[^]]+\]:/ { if (found) exit }
      found { print }
    ' CHANGELOG.md >"$NOTES"
-   [ -s "$NOTES" ] || { echo "error: no CHANGELOG.md section for $VERSION" >&2; exit 1; }
+   grep -q '[^[:space:]]' "$NOTES" || { echo "error: no CHANGELOG.md section for $VERSION" >&2; exit 1; }
    gh release create "v${VERSION}" --title "v${VERSION}" --verify-tag --notes-file "$NOTES"
    ```
-   On macOS, Linux, and Git Bash, `mktemp` works. Or paste the section in the GitHub UI (skip the `## [X.Y.Z]` heading; the title is already set).
+   Append a footer line after extraction, matching prior releases:
+   `**Full changelog:** https://github.com/cppalliance/claude-code-chat-browser/blob/vX.Y.Z/CHANGELOG.md`
+   On macOS, Linux, and Git Bash, `mktemp` works. Or paste the `[X.Y.Z]` section in the GitHub UI and add the same footer link.
 
 ## After release
 
-1. On `master`, bump `app.py` `__version__` to the next development suffix if you are starting the next cycle (for example `0.3.0.dev0` after shipping `0.2.0`). Put that commit in `CHANGELOG.md` under `[Unreleased]` only when there is user-visible work; a bare dev bump can ride with the next feature PR.
+1. On `master`, bump `app.py` `__version__` to the next development suffix when you start the next cycle (for example `0.3.0.dev0` after shipping `0.2.0`). Put that commit in `CHANGELOG.md` under `[Unreleased]` only when there is user-visible work; a bare dev bump can ride with the next feature PR.
 2. New work goes under `## [Unreleased]` until the next release.
 
 ## References

SECURITY.md

@@ -2,7 +2,7 @@
 
 ## Supported Versions
 
-This project is pre-release. Security fixes are applied to the **latest `master` branch only** (currently `0.1.0.dev0`).
+This project is pre-release. Security fixes are applied to the **latest `master` branch only** (currently `0.2.0`).
 
 | Version        | Supported |
 | -------------- | --------- |