Track release impact via per-PR labels

Four `release:` labels now classify every PR:
- release: breaking      — public API / admin / schema requires action
- release: migration     — adds a backend/drizzle/*.sql file
- release: upgrade-action — operators must do something manually
- release: internal      — no user-visible impact (default for refactors)

PRs must carry at least one. The PR template now has a "Release impact"
block with checkboxes for each label and prefilled prose sections
(Breaking change details, Migration & upgrade actions, Notes for AI
agents) the author fills in when the matching label is ticked. That text
becomes the source material for the release body — labelling well
during PR review is the work that makes release time fast.

CONTRIBUTING.md gets a "Release impact labels" section documenting the
labels, plus the gh recipe for fetching labelled PRs since the previous
tag at release time. RELEASE_TEMPLATE.md references the same recipe in
its top-of-file comment.

Author: vekexasia

.github/PULL_REQUEST_TEMPLATE.md

@@ -10,13 +10,65 @@
 
 <!-- Steps a reviewer can take to verify the change locally. -->
 
+## Release impact
+
+<!--
+Tick every label that applies and apply the matching label(s) to the PR
+on the right sidebar. If only "internal" applies, you're done — skip
+the "Breaking change details" / "Migration & upgrade actions" blocks.
+
+If "breaking", "migration", or "upgrade-action" apply, fill in the
+relevant block below. Whoever cuts the next release pulls these PRs
+via the GitHub UI / `gh pr list --label "release: breaking"` and
+copies the details into the release body.
+-->
+
+- [ ] `release: breaking` — public API shape, admin workflow, or DB
+  schema change that requires an upgrade action.
+- [ ] `release: migration` — adds a file under `backend/drizzle/*.sql`.
+- [ ] `release: upgrade-action` — operators must run a manual step
+  (rename a code, re-link an item, set an env var, regenerate a token).
+- [ ] `release: internal` — no user-visible impact (refactor, tests,
+  docs, CI). Default for refactors and test-only PRs.
+
+### Breaking change details
+
+<!--
+Required if `release: breaking` is ticked. What broke for whom?
+Be precise: include API path, schema column, admin URL, etc.
+This text gets copied into the GitHub release body.
+-->
+
+### Migration & upgrade actions
+
+<!--
+Required if `release: migration` or `release: upgrade-action` is ticked.
+
+Migration:
+- Filename and what it does to data (not just schema — call out any
+  backfill, default values, or dropped columns).
+
+Upgrade actions:
+- Concrete commands or admin clicks operators must run, in order.
+-->
+
+### Notes for AI agents
+
+<!--
+Optional but encouraged when this PR encodes a non-obvious decision
+(an invariant two files must respect, a deliberate workaround for a
+tooling quirk, a path we tried and rejected). These migrate into
+CHANGELOG.md at release time.
+-->
+
 ## Checklist
 
 - [ ] Tests pass: `cd backend && npm run check && npm run test:run`
 - [ ] Tests pass: `cd web && npm run test:run && npm run build`
 - [ ] Tests pass: `cd web/workers/chat && npx tsc --noEmit && npm run test:run`
 - [ ] No secrets, real tenant IDs, or `.dev.vars` committed
 - [ ] Docs updated if behaviour or env vars changed
+- [ ] Applied at least one `release:` label
 
 ## Licensing
 

.github/RELEASE_TEMPLATE.md

@@ -8,9 +8,18 @@ Drop sections that don't apply, but DO NOT drop "Breaking changes" or
 "Upgrade actions" — leave them with "None." if there are none. Self-hosters
 read these first.
 
-Pull from the matching CHANGELOG.md entry. The release body should be a
-self-contained snapshot — readers should not need to follow a link to know
-whether they have to do something.
+Source material: every PR merged since the previous tag carries one or more
+`release:` labels. PRs labelled `release: breaking`, `release: migration`,
+or `release: upgrade-action` have prefilled prose under their respective
+template sections — copy/aggregate those into the body below. PRs labelled
+only `release: internal` are skipped.
+
+  LAST=$(git describe --tags --abbrev=0)
+  gh pr list --state merged \
+    --search "merged:>$(git log -1 --format=%cI "$LAST")" \
+    --label "release: breaking" --label "release: migration" \
+    --label "release: upgrade-action" \
+    --json number,title,body,labels
 -->
 
 ## Summary

CONTRIBUTING.md

@@ -51,24 +51,50 @@ a separate license (see [COMMERCIAL.md](COMMERCIAL.md)).
 - Tailwind for styling.
 - One feature/fix per PR. Keep diffs small.
 
-## Releasing
+## Release impact labels
+
+Every PR must carry at least one `release:` label so the next release can be
+assembled from merged PRs without re-reading every diff:
 
-When publishing a GitHub release:
+- `release: breaking` — public API shape, admin workflow, or DB schema change
+  requiring an upgrade action.
+- `release: migration` — adds a file under `backend/drizzle/*.sql`.
+- `release: upgrade-action` — operators must run a manual step on upgrade.
+- `release: internal` — no user-visible impact (refactor, tests, docs, CI).
 
-1. Add a new dated entry at the top of [CHANGELOG.md](CHANGELOG.md). Always
-   include **Breaking changes**, **Migrations**, and **Upgrade actions**
+A single PR can carry several. Use `release: internal` as the default for PRs
+that genuinely don't affect users — that signals "consider me, then skip me"
+rather than "I forgot to label". The PR template in
+[.github/PULL_REQUEST_TEMPLATE.md](.github/PULL_REQUEST_TEMPLATE.md) prompts
+the author to fill in details for each non-internal label they tick; that text
+flows into the release body verbatim.
+
+## Releasing
+
+1. Find the previous tag: `LAST=$(git describe --tags --abbrev=0 2>/dev/null
+   || git rev-list --max-parents=0 HEAD)`.
+2. List PRs that need release-note coverage:
+   ```bash
+   gh pr list --state merged --search "merged:>$(git log -1 --format=%cI "$LAST")" \
+     --json number,title,labels,body \
+     --label "release: breaking" --label "release: migration" --label "release: upgrade-action"
+   ```
+   Each of these contributes a paragraph to the release body — copy the
+   "Breaking change details" / "Migration & upgrade actions" sections from
+   each PR description.
+3. Add a new dated entry at the top of [CHANGELOG.md](CHANGELOG.md). Always
+   keep **Breaking changes**, **Migrations**, and **Upgrade actions**
    subsections — write "None." rather than dropping them.
-2. Tag the commit (`git tag vYYYY.MM.DD && git push --tags`) or use the
-   GitHub UI.
-3. Draft the release body using
-   [.github/RELEASE_TEMPLATE.md](.github/RELEASE_TEMPLATE.md) as a starting
-   point — copy its contents into the release form, or pass it via
+4. Tag the release commit (`git tag vYYYY.MM.DD && git push --tags`).
+5. Draft the GitHub release body from
+   [.github/RELEASE_TEMPLATE.md](.github/RELEASE_TEMPLATE.md):
    `gh release create <tag> --notes-file .github/RELEASE_TEMPLATE.md` and
-   edit the resulting body. Keep the breaking-changes / upgrade-actions
-   blocks even if empty: self-hosters scan these first.
+   edit the resulting body. Paste the labelled PR content into the matching
+   sections.
 
 The release body should be self-contained — operators should not need to
-click through to CHANGELOG.md to find out whether they have work to do.
+click through to CHANGELOG.md or individual PRs to find out whether they
+have work to do.
 
 ## Reporting bugs