ci(release-please): switch to workflow_dispatch-only trigger

.github/copilot-instructions.md

@@ -79,4 +79,4 @@ Managed (enterprise) settings sit above all of these but are out of scope for th
 - Default branch: `dev`. PRs target `dev`. Follow Conventional Commits — version bumps and GitHub Release notes are generated by release-please from commit subjects (see `CONTRIBUTING.md`). No tracked `CHANGELOG.md`.
 - CI triggers on pushes to `dev` and PRs targeting `dev`.
 - MSRV: Rust 1.88 (enforced by a dedicated CI `msrv` job).
-- Releases: `release-please.yml` opens version-bump PRs on `dev`; merging one tags `vX.Y.Z`, which fires `release.yml` to build Tauri installers and upload them + `SHA256SUMS.txt` to a draft GitHub Release.
+- Releases: `release-please.yml` is `workflow_dispatch`-only; maintainer manually runs it to open a version-bump PR on `dev`. Merging that PR tags `vX.Y.Z`, which fires `release.yml` to build Tauri installers and upload them + `SHA256SUMS.txt` to a draft GitHub Release.

.github/workflows/release-please.yml

@@ -8,23 +8,35 @@ name: Release Please
 #
 # The release PR therefore goes through normal CI before merge, so a broken
 # tree never gets tagged.
+#
+# Manual-trigger only: previously this fired on every push to `dev`, which
+# meant a release PR sat open after every `feat:`/`fix:`/`perf:` merge.
+# Maintainer now invokes it via the Actions UI ("Run workflow") when ready
+# to cut a release. release-please walks `dev` since the last tag and opens
+# the release PR on that single dispatch.
 
 on:
-  push:
-    branches: [dev]
   workflow_dispatch:
 
 permissions:
   contents: write
 
 concurrency:
-  # Serialize so two pushes can't open conflicting release PRs.
-  group: release-please-${{ github.ref }}
+  # release-please always operates on `dev` (target-branch is hardcoded
+  # below), regardless of which ref the dispatch fires from. Pin the group
+  # to that target so two simultaneous dispatches from different refs still
+  # serialize — keying on github.ref would let them race and produce
+  # conflicting release PRs.
+  group: release-please-dev
   cancel-in-progress: false
 
 jobs:
   release-please:
     runs-on: ubuntu-24.04
+    # Belt-and-suspenders: target-branch is hardcoded to `dev` below, so
+    # dispatching from any other ref would just run a (possibly stale) copy
+    # of this workflow against `dev`'s history. Refuse outright instead.
+    if: github.ref_name == 'dev'
     # Scoped here (rather than workflow-level) so future jobs don't
     # silently inherit PR write access.
     permissions:

CLAUDE.md

@@ -14,16 +14,17 @@ Work on feature branches. Open PRs targeting `dev`. Follow conventional commits.
 
 ## Versioning
 
-Version bumps are automated by release-please (see `CONTRIBUTING.md`).
-release-please opens a "release PR" against `dev` whenever a conventional
-`feat:` / `fix:` / `perf:` lands, bumps every version-carrying file in
-lockstep (`package.json`, `package-lock.json`, `src-tauri/Cargo.toml`,
-`src-tauri/tauri.conf.json`, plus `src-tauri/Cargo.lock` via a follow-up
-sync step in `release-please.yml`). Merging that PR pushes a `vX.Y.Z`
-tag, which triggers `release.yml` to build and upload installers +
-`SHA256SUMS.txt`. Release notes live on the GitHub Release itself —
-`skip-changelog` is set in `release-please-config.json`, so there is
-no tracked `CHANGELOG.md`.
+Version bumps are automated by release-please (see `CONTRIBUTING.md`),
+but **manually triggered** — release-please does not run on every push to
+`dev`. To cut a release, run **Actions → Release Please → Run workflow**;
+release-please walks `dev` since the last tag, opens a "release PR" that
+bumps every version-carrying file in lockstep (`package.json`,
+`package-lock.json`, `src-tauri/Cargo.toml`, `src-tauri/tauri.conf.json`,
+plus `src-tauri/Cargo.lock` via a follow-up sync step in
+`release-please.yml`). Merging that PR pushes a `vX.Y.Z` tag, which
+triggers `release.yml` to build and upload installers + `SHA256SUMS.txt`.
+Release notes live on the GitHub Release itself — `skip-changelog` is set
+in `release-please-config.json`, so there is no tracked `CHANGELOG.md`.
 
 If you ever need to bump versions by hand (e.g. release-please is broken),
 do **not** regenerate `package-lock.json` with

CONTRIBUTING.md

@@ -43,26 +43,32 @@ reads cleaner in the changelog than a bare `feat:`.
 
 ## Releases
 
-Releases are fully automated via
-[release-please](https://github.com/googleapis/release-please-action) plus
-the existing tag-driven `release.yml`. There's nothing to do by hand.
+Releases use [release-please](https://github.com/googleapis/release-please-action)
+plus the existing tag-driven `release.yml`. The cut is **maintainer-triggered**
+— release-please does not open a release PR on every merge into `dev`.
 
 The flow:
 
 1. Land conventional-commit PRs into `dev`.
-2. `.github/workflows/release-please.yml` opens (and keeps rebased) a
-   "release PR" that bumps the version in `package.json`,
-   `package-lock.json`, `src-tauri/Cargo.toml`, `src-tauri/tauri.conf.json`,
-   and `src-tauri/Cargo.lock`. Release notes are generated onto the GitHub
-   Release itself rather than into a tracked `CHANGELOG.md` (`skip-changelog`
-   in `release-please-config.json`).
+2. When ready to cut a release, manually run **Actions → Release Please →
+   Run workflow** on `dev`. release-please walks `dev` since the last tag,
+   computes the next semver bump from commit subjects, and opens a "release
+   PR" that bumps the version in `package.json`, `package-lock.json`,
+   `src-tauri/Cargo.toml`, `src-tauri/tauri.conf.json`, and
+   `src-tauri/Cargo.lock`. Release notes are generated onto the GitHub
+   Release itself rather than into a tracked `CHANGELOG.md`
+   (`skip-changelog` in `release-please-config.json`).
 3. Merge the release PR. release-please then pushes the `vX.Y.Z` tag and
    creates the GitHub Release.
 4. The tag push triggers `.github/workflows/release.yml`, which builds the
    Tauri installers for Linux / Windows / macOS-universal and uploads them
    plus a `SHA256SUMS.txt` to that release as a draft.
 5. Review the draft release in the GitHub UI and click "Publish".
 
+If you re-run the workflow after additional commits land on `dev`, the
+existing release PR is rebased to include them — same machinery, just
+triggered on demand instead of on every push.
+
 ### Caveats
 
 - **Cargo.lock sync race.** When release-please opens a fresh release PR,