Release flow: test on published alpha/beta artifacts, bump only at release

All release testing now happens against the published -alpha/-beta
prerelease assets installed in the test vault (attested CI builds), and
cutting the stable release is only the version bump + bare tag on the
same source. Doc-only commits may ride between the last prerelease and
the stable tag; anything affecting the built artifact means a new
prerelease round.

Updated: RELEASING.md (TL;DR, pre-flight, "The alpha/beta channel"),
release-checklist SKILL.md (Phases 2/3/5 install the prerelease via
gh release download; release:prep stays as the mid-development path),
CHECKLIST.md intro, CLAUDE.md summaries. Also corrected RELEASING.md's
stale description of version-bump.mjs (it records every version, not
only floor changes).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

.claude/skills/release-checklist/CHECKLIST.md

@@ -1,6 +1,6 @@
-# ReWrite (Voice Notes) — release feature checklist
+# ReWrite (Voice Notes) — release feature checklist
 
-Manual pass to run in a **scratch** Obsidian vault against a fresh build (see `npm run release:prep`). This is the source of truth for pre-release verification; the old checklist in `obsidian-voice-notes-spec.md` is retired.
+Manual pass to run in a **scratch** Obsidian vault against the artifact under test — for a release gate, the published `-alpha`/`-beta` prerelease assets installed into the vault (see `docs/RELEASING.md`, "The alpha/beta channel"); for mid-development iteration, a fresh local build via `npm run release:prep`. This is the source of truth for release verification; the old checklist in `obsidian-voice-notes-spec.md` is retired.
 
 Runnable standalone (no Claude Code needed). For each item, do the action and record the outcome on its `Result:` line as PASS / FAIL / SKIP plus any notes. Scope the pass to what changed, but always run **Core** and the clean-load check.
 
@@ -119,7 +119,7 @@ Keep this file current: when a feature is added or changed, add or update its it
 - [ ] Settings "Auto-ingest folders": Add opens the rule popup; the template dropdown lists only newFile templates; rules list with enable toggle / Edit / Delete. Result: ____
 - [ ] `Process auto-ingest folders` processes each audio file in an enabled folder with that rule's template, one at a time, behind a sticky Notice with Cancel. Result: ____
 - [ ] On success each recording is moved to the attachments location and its note's `![[embed]]` still resolves; a re-run does not reprocess it. Result: ____
-- [ ] A file that fails stays in the ingest folder and is retried next run; the summary Notice reports processed/failed counts **and** a second sticky Notice lists the concrete failure reason per file (first 5, then "…and N more"). Result: ____
+- [ ] A file that fails stays in the ingest folder and is retried next run; the summary Notice reports processed/failed counts **and** a second sticky Notice lists the concrete failure reason per file (first 5, then "…and N more"). Result: ____
 - [ ] **Ingest folder == recordings/attachments folder** is caught UP FRONT: setting a rule's folder to the same folder recordings are stored in (either the ReWrite Attachments folder, or Obsidian's own attachment folder when ReWrite's is blank) skips the rule with a clear "this folder is also where recordings are stored; point the rule at a different folder" Notice BEFORE any note is created. Result: ____
 - [ ] **Move-after-success failure**: if the note is created but the recording can't be moved out, the error says the note was created and to move/delete the source manually (so it isn't reprocessed). Result: ____
 

.claude/skills/release-checklist/SKILL.md

@@ -1,11 +1,11 @@
 ---
 name: release-checklist
-description: Run the ReWrite (Voice Notes) plugin's pre-release verification. Use before tagging a release, or when the user asks to smoke-test / verify the plugin in a real vault. Runs the automated pre-checks (build, lint, test, and the advisory local reviews), installs a fresh build into a test vault, then walks the feature-by-feature CHECKLIST.md so the human effort goes into clicking through features rather than copying files.
+description: Run the ReWrite (Voice Notes) plugin's release verification. Use before cutting a stable release, or when the user asks to smoke-test / verify the plugin in a real vault. Runs the automated pre-checks (build, lint, test, and the advisory local reviews), installs the published -alpha/-beta prerelease artifact (or a fresh local build when no prerelease exists yet) into a test vault, then walks the feature-by-feature CHECKLIST.md so the human effort goes into clicking through features rather than copying files.
 ---
 
 # Release checklist
 
-This plugin has no headless UI test harness, so event-wiring and UI-lifecycle bugs are invisible to `npm run build` / `npm run lint` / `npm test`. This skill closes that gap: it runs every automated check available, installs a fresh build into a test Obsidian vault, then drives a human through a feature-by-feature manual pass.
+This plugin has no headless UI test harness, so event-wiring and UI-lifecycle bugs are invisible to `npm run build` / `npm run lint` / `npm test`. This skill closes that gap: it runs every automated check available, installs the artifact under test into a test Obsidian vault (the published `-alpha`/`-beta` prerelease for a release gate; a fresh local build for mid-development iteration), then drives a human through a feature-by-feature manual pass.
 
 It is the successor to the stale "Testing Checklist" in `obsidian-voice-notes-spec.md` and the token "manual smoke test" step in `docs/RELEASING.md`. The mechanics of each tool are in `docs/DEV_TOOLING.md`; the tag/push release steps are in `docs/RELEASING.md`. This skill is the front door that sequences them.
 
@@ -25,16 +25,22 @@ npm run review:docs   # advisory local doc-consistency review
 
 ## Phase 2 — Setup check
 
-1. Confirm `dev-tools.config.json` exists at the repo root with a non-empty `releaseVault.vaultPath`. If not, tell the user to copy `dev-tools.config.example.json` to `dev-tools.config.json` and fill it in. A dedicated **scratch** vault is ideal; a real vault is acceptable because `release:prep` only overwrites the three build artifacts (see Phase 3), but never point it anywhere you'd mind a plugin reload.
-2. Confirm the working tree holds exactly what the user intends to ship. For a real release you also want the version already bumped (`npm version <patch|minor|major> --no-git-tag-version`) so the manual pass exercises the actual versioned artifact **before** you commit and tag — do not tag first.
+1. Confirm `dev-tools.config.json` exists at the repo root with a non-empty `releaseVault.vaultPath`. If not, tell the user to copy `dev-tools.config.example.json` to `dev-tools.config.json` and fill it in. A dedicated **scratch** vault is ideal; a real vault is acceptable because the install only overwrites the three build artifacts (see Phase 3), but never point it anywhere you'd mind a plugin reload.
+2. Confirm the working tree holds exactly what the user intends to ship, and that master carries **no version bump**: per `docs/RELEASING.md`, all testing happens on published `-alpha`/`-beta` prerelease artifacts while `manifest.json` stays at the last stable version. The bump + bare tag come only after this skill's go decision.
+3. Identify the prerelease to test: the newest `-alpha`/`-beta` tag whose commit matches what the user intends to ship (`gh release list`). If the tree has moved past the latest prerelease, cut a new suffixed tag first (see RELEASING.md) — do not sign off on an artifact that doesn't match master.
 
-## Phase 3 — Build and install
+## Phase 3 — Install the artifact under test
+
+**Release gate (a prerelease exists):** install the published, attested prerelease assets into the vault — that exact build is what the stable release will re-version:
 
 ```bash
-npm run release:prep
+gh release download <tag> --repo WiseGuru/ReWrite-Voice-Notes --clobber \
+  --dir "<vaultPath>/.obsidian/plugins/rewrite-voice-notes"
 ```
 
-This runs `npm run build`, then copies `main.js` / `manifest.json` / `styles.css` into `<vaultPath>/.obsidian/plugins/rewrite-voice-notes/`. It fails loudly (non-zero exit) on a build error or a bad vault path; surface any failure and stop. It **only overwrites those three files** — `data.json` and `secrets.json.nosync` in the target folder are left untouched, so a re-install keeps the user's settings and keys (this is why running against a vault with real data is safe).
+**Local iteration (no prerelease yet, or mid-development):** `npm run release:prep` builds the working tree and copies the three files into the same folder. Fine for finding bugs fast; the final pass before a stable tag should still run against the prerelease artifact.
+
+Both paths **only overwrite `main.js` / `manifest.json` / `styles.css`** — `data.json` and `secrets.json.nosync` in the target folder are left untouched, so a re-install keeps the user's settings and keys (this is why running against a vault with real data is safe). `release:prep` fails loudly (non-zero exit) on a build error or a bad vault path; surface any failure and stop.
 
 Then tell the user to open the vault and reload the plugin (Settings -> Community plugins -> toggle it off and on, or reload Obsidian), and confirm it loads with no errors in the developer console. **A clean load is itself the first checklist item** — it is the exact step that would have caught the regression that motivated this tooling.
 
@@ -49,6 +55,6 @@ Open `CHECKLIST.md` (in this skill folder) and walk it area by area. For each it
 
 ## Phase 5 — Summary and hand-off to release
 
-Save the filled-out run to `docs/claude-scratch/release-checklist-<version>.md` (read `<version>` from `manifest.json`; that folder is gitignored). Then give a clear **go / no-go**: list every FAIL with its symptom, note any SKIP and why, and state plainly whether the build is releasable. Do not soften a FAIL into a pass.
+Save the filled-out run to `docs/claude-scratch/release-checklist-<version>.md` (name it after the tag under test, e.g. `1.3.0-alpha`; when testing a local `release:prep` build instead, use `manifest.json`'s version. The folder is gitignored). Then give a clear **go / no-go**: list every FAIL with its symptom, note any SKIP and why, and state plainly whether the build is releasable. Do not soften a FAIL into a pass.
 
-On a **go**, the actual release (commit the bump + rolled `docs/ROADMAP.md`, tag the bare version, push, let CI build the attested assets) follows `docs/RELEASING.md` — this skill stops at the go/no-go decision; it does not tag or push.
+On a **go**, the actual release (bump `npm version <patch|minor|major> --no-git-tag-version`, commit the bump + rolled `docs/ROADMAP.md`, tag the bare version, push, let CI build the attested assets) follows `docs/RELEASING.md`. The bump commit (plus doc-only commits) is the only permitted delta between the tested prerelease and the stable tag; any artifact-affecting change means a new prerelease round. This skill stops at the go/no-go decision; it does not tag or push.

CLAUDE.md

@@ -59,7 +59,7 @@ npm run release:prep  # build + copy main.js/manifest.json/styles.css into a scr
 
 Verification is `npm run build && npm run lint && npm test` (CI parity) plus the manual feature pass driven by the **`release-checklist` skill** ([.claude/skills/release-checklist/](.claude/skills/release-checklist/); see [docs/DEV_TOOLING.md](docs/DEV_TOOLING.md)), which replaced the stale checklist in [obsidian-voice-notes-spec.md](obsidian-voice-notes-spec.md).
 
-To publish a new version, follow [docs/RELEASING.md](docs/RELEASING.md) (version bump + bare-version tag + CI-built, attested assets; do not hand-upload).
+To publish a new version, follow [docs/RELEASING.md](docs/RELEASING.md). The flow is alpha/beta-first: tag `<next-version>-alpha` (no version bump on master), test the published prerelease artifact in a real vault via the `release-checklist` skill, iterate with further suffixed tags as needed, and only on a green pass bump the version + push the bare-version tag (CI-built, attested assets; do not hand-upload). The bump commit (plus doc-only commits) is the only permitted delta between the tested prerelease and the stable tag; artifact-affecting changes mean a new prerelease round.
 
 CI ([.github/workflows/lint.yml](.github/workflows/lint.yml)) runs `npm ci`, `npm run build`, `npm run lint`, and `npm test` on Node 20.x and 22.x for every push/PR.
 
@@ -349,7 +349,7 @@ Per [.editorconfig](.editorconfig): tabs (width 4), LF, UTF-8, final newline. Ma
 - **Keep [src/main.ts](src/main.ts) minimal**: only plugin lifecycle, command registration, settings tab registration. Feature logic belongs in dedicated modules.
 - **Defer heavy work**: no long tasks in `onload`. Providers/recorders lazy-init when first used.
 - **Network policy**: provider calls go to user-configured endpoints with user-provided keys. No telemetry, no auto-update of plugin code, no `fetch`+`eval`.
-- **Releases**: GitHub release tag must exactly match `manifest.json`'s `version` (no leading `v`). Attach `main.js`, `manifest.json`, `styles.css` as individual binary assets (not zipped). This is automated by [.github/workflows/release.yml](.github/workflows/release.yml): pushing a version tag builds the bundle, runs `actions/attest-build-provenance` (GitHub artifact attestations for provenance), and publishes the assets via `softprops/action-gh-release`. To cut a release, push a tag named exactly the version; do not hand-upload assets (that loses attestation). A tag carrying a pre-release suffix (any `-`, e.g. `1.3.0-alpha`/`1.3.0-beta`) is instead published as a GitHub **prerelease** for manual/BRAT smoke-testing: the workflow stamps the tag's version into the *published* `manifest.json` only (master's copy is untouched, so the official updater and community review never see it). See the "Pre-release (alpha/beta) builds" section of RELEASING.md. **Before publishing any release, follow [docs/RELEASING.md](docs/RELEASING.md)** for the full step-by-step (version bump, tag, push, verify) and the guideline-conflict checklist that keeps the Obsidian community review green.
+- **Releases**: GitHub release tag must exactly match `manifest.json`'s `version` (no leading `v`). Attach `main.js`, `manifest.json`, `styles.css` as individual binary assets (not zipped). This is automated by [.github/workflows/release.yml](.github/workflows/release.yml): pushing a version tag builds the bundle, runs `actions/attest-build-provenance` (GitHub artifact attestations for provenance), and publishes the assets via `softprops/action-gh-release`. To cut a release, push a tag named exactly the version; do not hand-upload assets (that loses attestation). A tag carrying a pre-release suffix (any `-`, e.g. `1.3.0-alpha`/`1.3.0-beta`) is instead published as a GitHub **prerelease**: the workflow stamps the tag's version into the *published* `manifest.json` only (master's copy is untouched, so the official updater and community review never see it). This channel is where ALL release testing happens — every stable release is a tested prerelease plus only the version-bump commit (and doc-only changes). See "The alpha/beta channel" section of RELEASING.md. **Before publishing any release, follow [docs/RELEASING.md](docs/RELEASING.md)** for the full step-by-step (prerelease tag, feature pass, bump, bare tag, verify) and the guideline-conflict checklist that keeps the Obsidian community review green.
 
 ## Gotchas
 

docs/RELEASING.md

@@ -2,28 +2,34 @@
 
 How to cut a new release the Obsidian way, without tripping the community-plugin review. Read this before every release.
 
-Releases are automated by [.github/workflows/release.yml](../.github/workflows/release.yml): pushing a version tag builds the bundle, attaches build-provenance attestations, and publishes the GitHub release. Your job is the version bump, the pre-flight checks, and pushing a correctly named tag.
+Releases are automated by [.github/workflows/release.yml](../.github/workflows/release.yml): pushing a version tag builds the bundle, attaches build-provenance attestations, and publishes the GitHub release. Your job is the pre-flight checks and pushing correctly named tags.
+
+**Every release rides the alpha/beta channel first.** All testing (the manual feature pass included) happens against published `-alpha`/`-beta` prerelease artifacts; cutting the stable release is then *only* the version bump + bare tag on the same source. Between the last prerelease you tested and the stable tag, nothing that affects the built artifact (`src/`, `styles.css`, `manifest.json` beyond the version, build config, dependencies) may change — doc-only commits may ride along, but any artifact-affecting change means a new prerelease round, not a direct-to-stable commit.
 
 ## TL;DR
 
 ```bash
-# 0. On master, clean working tree, everything you want shipped is committed.
-npm run build && npm run lint          # must both pass
-# 0a. Roll docs/ROADMAP.md: move the Unreleased items into a new
-#     "### <version> — <YYYY-MM-DD>" block under Released, leave Unreleased empty.
-# 1. Bump version files (no auto commit/tag so we control the message)
+# 1. On master, clean tree, everything you want to ship committed. Do NOT bump yet —
+#    manifest.json stays at the last stable version throughout testing.
+npm run build && npm run lint && npm test   # must all pass
+# 2. Cut a prerelease of the version you are ABOUT to ship
+git tag -a 1.3.0-alpha -m "Pre-release 1.3.0-alpha"
+git push origin 1.3.0-alpha
+# 3. Test the PUBLISHED prerelease artifact in a real vault (the release-checklist
+#    skill / CHECKLIST.md — see "The alpha/beta channel" below for install options).
+#    Fixes needed? Commit them, tag 1.3.0-alpha.2 / 1.3.0-beta, re-test. Repeat until green.
+# 4. Go: roll docs/ROADMAP.md (Unreleased -> "### <version> — <YYYY-MM-DD>" under
+#    Released), then bump and tag the bare version.
 npm version patch --no-git-tag-version # or minor / major
-# 2. Commit the bump (include the rolled roadmap)
 git add manifest.json package.json package-lock.json versions.json docs/ROADMAP.md
-git commit -m "1.0.1"                  # use the new version as the subject
-# 3. Tag with the BARE version (no leading v) and push
-git tag -a 1.0.1 -m "Release 1.0.1"
+git commit -m "1.3.0"                  # use the new version as the subject
+git tag -a 1.3.0 -m "Release 1.3.0"
 git push origin master
-git push origin 1.0.1
-# 4. Watch CI, then verify provenance (see Verify below)
+git push origin 1.3.0
+# 5. Watch CI, then verify provenance (see Verify below)
 ```
 
-The tag name must equal `manifest.json`'s `version` exactly. `.npmrc` already pins `tag-version-prefix=""`, so `npm version` produces a bare tag too if you ever let it tag directly.
+The stable tag name must equal `manifest.json`'s `version` exactly (bare, no leading `v`). `.npmrc` already pins `tag-version-prefix=""`, so `npm version` produces a bare tag too if you ever let it tag directly.
 
 ## Hard rules (Obsidian requirements)
 
@@ -33,14 +39,14 @@ The tag name must equal `manifest.json`'s `version` exactly. `.npmrc` already pi
 - **Stable version format is `x.y.z` only.** Semantic Versioning, no build metadata. The initial release is `1.0.0`. Pre-release suffixes (`1.3.0-alpha`, `1.3.0-beta.1`) are allowed **only** for the alpha/beta channel below, which is deliberately invisible to the official review/updater; a stable tag never carries a suffix.
 - **The directory reads `manifest.json` at the HEAD of your default branch** (`master`), not just the release asset. Keep master's `manifest.json` correct and in sync with the released version.
 - **`minAppVersion` must be >= the highest `@since` of every Obsidian API you call directly** (anything not behind a runtime feature-detect). Check `node_modules/obsidian/obsidian.d.ts` for the `@since` of new APIs. Example from this project: `FileManager.trashFile` is `@since 1.6.6`, which is why `minAppVersion` is `1.6.6` (raised from 1.4.4, which `FileManager.processFrontMatter` `@since 1.4.4` had driven). The `obsidianmd/no-unsupported-api` lint rule flags a direct call newer than the declared floor. Feature-detected APIs (like `app.secretStorage`) do not raise the floor.
-- **`versions.json` maps plugin version -> minAppVersion.** Our [version-bump.mjs](../version-bump.mjs) only adds a new line when the `minAppVersion` value is not already present (i.e. when the floor actually changes). That is valid: Obsidian reads the latest version straight from the release `manifest.json`, and consults `versions.json` only to find the newest plugin version compatible with an older app. If you raise `minAppVersion`, confirm a new `versions.json` entry was written; if you keep it, no new line is expected.
+- **`versions.json` maps plugin version -> minAppVersion.** Our [version-bump.mjs](../version-bump.mjs) records an entry for **every** bumped version (it skips only when the version key already exists). It previously added a line only when the `minAppVersion` *value* changed, which silently dropped every release after the first from the compatibility map; that was fixed, so expect one new line per release. Obsidian reads the latest version straight from the release `manifest.json`, and consults `versions.json` only to find the newest plugin version compatible with an older app.
 - **Public repo + LICENSE.** The repo must be public to be listed, with a real LICENSE whose copyright holder is correct (this plugin is 0BSD). The README must disclose network use, and `manifest.json` carries `author`, `authorUrl`, and (if you take donations) `fundingUrl`.
 
 ## Pre-flight checklist
 
 1. `npm run build` passes (this is `tsc -noEmit` then esbuild production; a type error here is a release blocker).
 2. `npm run lint` passes with zero warnings, and `npm test` passes. The local `eslint-plugin-obsidianmd` is looser than the official review bot, so also eyeball the conflict checklist below.
-3. Manual feature pass via the **`release-checklist` skill** (`.claude/skills/release-checklist/`), which sequences the whole verification. Its Phase 1 runs the automated pre-checks (`build` / `lint` / `test` plus the advisory `npm run review` and `npm run review:docs` local reviews); then `npm run release:prep` builds and installs `main.js` / `manifest.json` / `styles.css` into your test vault's `.obsidian/plugins/rewrite-voice-notes/` (configure `releaseVault.vaultPath` in `dev-tools.config.json` first — `release:prep` only overwrites those three files, so a vault with real data is safe); then the skill walks `CHECKLIST.md` feature by feature. `CHECKLIST.md` is also runnable standalone by a human without Claude Code. See [DEV_TOOLING.md](DEV_TOOLING.md). Test the actual **versioned** artifact: bump first (`npm version <patch|minor|major> --no-git-tag-version`), then run the pass, then commit + tag.
+3. Manual feature pass via the **`release-checklist` skill** (`.claude/skills/release-checklist/`), which sequences the whole verification. Its Phase 1 runs the automated pre-checks (`build` / `lint` / `test` plus the advisory `npm run review` and `npm run review:docs` local reviews); then the **published prerelease artifact** is installed into your test vault's `.obsidian/plugins/rewrite-voice-notes/` (download the three assets from the prerelease page, or use BRAT — the install only replaces `main.js` / `manifest.json` / `styles.css`, so a vault with real data is safe); then the skill walks `CHECKLIST.md` feature by feature. `CHECKLIST.md` is also runnable standalone by a human without Claude Code. See [DEV_TOOLING.md](DEV_TOOLING.md). Sign off on the prerelease build, not a local one: `npm run release:prep` (which builds and copies from the working tree) remains the fast path for iterating *before* a prerelease exists, but the pass that gates the release runs against the attested `-alpha`/`-beta` assets, and the stable bump happens only after the go decision.
 4. Update docs for any behavioral change ([CLAUDE.md](../CLAUDE.md), the user-facing [`wiki/`](../wiki/) pages, and the [README](../README.md)), per the doc-maintenance rules in CLAUDE.md.
 5. Roll [ROADMAP.md](ROADMAP.md): every item shipping in this release should already have an **Unreleased** entry. Move them into a new `### <version> — <YYYY-MM-DD>` heading at the top of the **Released** archive, and leave `## Unreleased` empty for the next cycle. The version + date must match the tag.
 
@@ -93,11 +99,11 @@ gh attestation verify /tmp/rel/main.js --repo WiseGuru/ReWrite-Voice-Notes # mus
 
 Also confirm the release page shows the bare tag (`1.0.1`, no `v`) and all three assets.
 
-## Pre-release (alpha/beta) builds
+## The alpha/beta channel (where all testing happens)
 
-For a manual smoke test through Obsidian before committing to a stable release, cut a pre-release. It builds and publishes the same three attested assets as a normal release, but as a GitHub **prerelease**, so it is invisible to the official channel: GitHub's "latest release" (what Obsidian's in-app updater reads) excludes prereleases, and the community submission review reads `manifest.json` at **master's HEAD**, which this flow never touches.
+Every release candidate is published as a prerelease and tested in that form. A prerelease builds and publishes the same three attested assets as a stable release, but as a GitHub **prerelease**, so it is invisible to the official channel: GitHub's "latest release" (what Obsidian's in-app updater reads) excludes prereleases, and the community submission review reads `manifest.json` at **master's HEAD**, which this flow never touches.
 
-Convention: pre-release the version you are *about to* ship. If the next release is `1.3.0`, tag `1.3.0-alpha` (then `-beta`, `-rc`, etc.) while master's `manifest.json` still reads the last stable version (`1.2.1`). Because `1.3.0-alpha` < `1.3.0` in SemVer, a BRAT beta tester is auto-upgraded when the real `1.3.0` lands.
+Convention: pre-release the version you are *about to* ship. If the next release is `1.3.0`, tag `1.3.0-alpha` (then `-alpha.2`, `-beta`, `-rc`, etc. as rounds accumulate) while master's `manifest.json` still reads the last stable version (`1.2.1`). Because `1.3.0-alpha` < `1.3.0` in SemVer, a BRAT beta tester is auto-upgraded when the real `1.3.0` lands.
 
 Any tag containing a `-` is treated as a pre-release by [release.yml](../.github/workflows/release.yml): it stamps the tag's version into the **published** `manifest.json` at build time (master's copy is left alone) and sets `prerelease: true` on the GitHub release.
 
@@ -110,7 +116,9 @@ git push origin 1.3.0-alpha
 # CI publishes a prerelease with a manifest.json version of 1.3.0-alpha.
 ```
 
-Iterate by pushing further suffixed tags (`1.3.0-alpha.2`, `1.3.0-beta`, ...). To install for review, either download the three assets from the prerelease page and copy them into `<Vault>/.obsidian/plugins/rewrite-voice-notes/`, or add the repo in **BRAT** with "beta versions" enabled (BRAT reads the newest prerelease). When satisfied, cut the stable `1.3.0` the normal way (TL;DR above): the real version bump + bare tag. Pre-release tags and their GitHub releases can be left in place (they stay marked prerelease) or deleted; they never affect the stable channel.
+To install for testing, either download the three assets from the prerelease page and copy them into `<Vault>/.obsidian/plugins/rewrite-voice-notes/`, or add the repo in **BRAT** with "beta versions" enabled (BRAT reads the newest prerelease). Run the feature pass (`release-checklist` skill / `CHECKLIST.md`) against that install. Fixes go to master and get a further suffixed tag (`1.3.0-alpha.2`, `1.3.0-beta`, ...); re-test at least the affected areas plus a clean load.
+
+When the pass is green, cut the stable `1.3.0` per the TL;DR: version bump + bare tag on the **same source** you just tested — the bump commit (plus doc-only commits) is the only permitted delta between the last prerelease and the stable release; anything touching the artifact means a new prerelease round. Pre-release tags and their GitHub releases can be left in place (they stay marked prerelease) or deleted; they never affect the stable channel.
 
 Note: `versions.json` is not updated for pre-releases (no bump runs), which is correct. Never point a stable tag at a suffixed name, and never commit a `-alpha`/`-beta` version into master's `manifest.json` (it would corrupt what the directory reads at HEAD).