docs: channel branches in release workflow + promotion-PR check behavior (#116)

Doc gaps surfaced while dogfooding the `next` channel to completion.
Docs-only; no bump file (nothing under `packages/` changes).

**Release workflow examples (`github-actions.md`)** — both the
split-jobs and single-job examples now:
- comment that prerelease channel branches go in the `push` trigger too
(`[main, next, beta]`), with a link to the channels doc, and
- use a **per-ref concurrency group** (`bumpy-release-${{ github.ref
}}`). With a single shared group, a `next` prerelease publish queues
behind — or, with `cancel-in-progress: true`, gets cancelled by — a
`main` release, despite touching different dist-tags. This is the exact
lesson from our own `release.yaml`. The standalone **Concurrency**
section now explains the why, and notes the plain group is equivalent if
you only release from `main`.

**`prereleases.md` setup** — the "only trigger change" line now also
flags that an _existing_ workflow on a single concurrency group should
switch to per-ref (new workflows get it from the example).

**`cli.md`** — documents what `ci check` posts on channel PRs
(prerelease plan, `-<preid>.x`, dist-tag) and on **promotion PRs**
(reads `.bumpy/<channel>/`, shows the consolidated stable plan, calls
out that merging ends the cycle) — behavior that shipped in #111/#113
but wasn't in the command reference.

Not included here: the auto-close-promoted-release-PR docs ride with
#115; nothing here references that unmerged behavior.

Author: theoephraim

docs/cli.md

@@ -190,6 +190,8 @@ bumpy ci check --no-fail
 
 Requires `GH_TOKEN` environment variable (automatically available in GitHub Actions).
 
+**On channel and promotion PRs:** for a PR targeting a [prerelease channel](prereleases.md) branch, the comment is channel-aware — it shows the prerelease plan (`-<preid>.x` versions) and the target dist-tag rather than implying a stable release. For a **promotion PR** (a channel branch → `main`, or a graduation like `alpha` → `beta`), the check reads the cycle's already-shipped bump files from `.bumpy/<channel>/` and shows the consolidated stable plan, calling out that merging ends the prerelease cycle. (Feature PRs that _target_ a channel branch are checked against that branch, so only the PR's own new bump files count — see [`--base`](#bumpy-check) on the local `check` command for the equivalent locally.)
+
 ## `bumpy ci plan`
 
 CI command that reports what `ci release` would do, without acting. Outputs JSON to stdout and sets GitHub Actions step outputs so you can conditionally run expensive steps (builds, etc.) only when needed.

docs/github-actions.md

@@ -108,10 +108,13 @@ The recommended release workflow splits version-PR maintenance from publishing i
 name: Bumpy Release
 on:
   push:
+    # Add any prerelease channel branches here too, e.g. [main, next, beta].
+    # See the prerelease channels docs: https://github.com/dmno-dev/bumpy/blob/main/docs/prereleases.md
     branches: [main]
 
 concurrency:
-  group: bumpy-release
+  # Per-ref: serialize a branch's releases, let different branches run in parallel
+  group: bumpy-release-${{ github.ref }}
   cancel-in-progress: false
 
 jobs:
@@ -257,10 +260,13 @@ For simpler setups, you can run everything in a single job. `bumpy ci release` w
 name: Bumpy Release
 on:
   push:
+    # Add any prerelease channel branches here too, e.g. [main, next, beta].
+    # See the prerelease channels docs: https://github.com/dmno-dev/bumpy/blob/main/docs/prereleases.md
     branches: [main]
 
 concurrency:
-  group: bumpy-release
+  # Per-ref: serialize a branch's releases, let different branches run in parallel
+  group: bumpy-release-${{ github.ref }}
   cancel-in-progress: false
 
 jobs:
@@ -321,11 +327,11 @@ Use a concurrency group on your release workflow to prevent overlapping publish
 
 ```yaml
 concurrency:
-  group: bumpy-release
+  group: bumpy-release-${{ github.ref }}
   cancel-in-progress: false # queue rather than cancel — don't skip releases
 ```
 
-This is included in all the workflow examples above.
+This is included in all the workflow examples above. Per-ref serializes each branch's releases against themselves while letting different branches publish in parallel. It's the right default everywhere: with a single release branch it behaves identically to a plain group, and once you add [prerelease channels](prereleases.md) it stops a `next` prerelease publish from queueing behind — or, with `cancel-in-progress: true`, being cancelled by — a `main` release, even though they touch different dist-tags and never conflict.
 
 ## Token setup