chore: back-merge v0.12.4 into next (real merge)

.github/workflows/release-please.yml

@@ -286,8 +286,8 @@ jobs:
   # Stable releases only: bring the release's version bump and changelog from
   # main into next so the branches do not drift. Only version bookkeeping files
   # may conflict and scripts/back-merge.ts resolves those; anything else fails
-  # the job loudly so a person resolves it (see RELEASING.md). The PR must be
-  # merged with a merge commit, not squashed.
+  # the job loudly so a person resolves it (see RELEASING.md). The PR is set to
+  # auto-merge with a merge commit, never a squash, so the branches share history.
   back-merge:
     name: Open main to next back-merge PR
     needs: [channel, release-please]
@@ -347,6 +347,11 @@ jobs:
           else
             gh pr create --repo "$GITHUB_REPOSITORY" --base next --head "$BRANCH" \
               --title "chore: back-merge ${TAG} into next" \
-              --body "Brings the ${TAG} version bump and changelog from main into next. Merge with a merge commit, not a squash, so the branches share history."
+              --body "Brings the ${TAG} version bump and changelog from main into next. Auto-merges with a merge commit once checks pass; do not squash it, or main's commits never become ancestors of next and the next back-merge conflicts on the same lines again."
           fi
 
+          # The next ruleset allows squash for feature PRs, so a person clicking
+          # merge here would default to squash (v0.12.0 to v0.12.4 all were).
+          # Auto-merge pins the method to a real merge commit.
+          gh pr merge "$BRANCH" --repo "$GITHUB_REPOSITORY" --auto --merge
+

README.md

@@ -287,11 +287,6 @@ the site's `lefthook.yml`: it applies to the merged hook, so every step,
 including the shared ones, starts at once and their `priority` order is ignored
 (tests that share a database or build output can then time out).
 
-Hook-level options merge too. Don't set `parallel: true` under `pre-commit:` in
-the site's `lefthook.yml`: it applies to the merged hook, so every step,
-including the shared ones, starts at once and their `priority` order is ignored
-(tests that share a database or build output can then time out).
-
 Install the binary through mise (`lefthook = "<version>"` in `mise.toml`) and
 set the `prepare` script so `bun install` wires the hooks, but make it tolerate a
 missing binary:

RELEASING.md

@@ -40,7 +40,10 @@ gitGraph
 3. release-please opens or updates the stable release PR on `main`. Merging it
    publishes under `latest`, moves the floating `v0` tag, and opens a
    `main` to `next` back-merge PR.
-4. Merge the back-merge PR with a merge commit too.
+4. The back-merge PR auto-merges with a merge commit once checks pass. If you
+   ever merge one by hand (e.g. after resolving conflicts), use a merge commit,
+   never squash: a squash leaves main's commits out of next's history, so the
+   following back-merge conflicts on the same lines again.
 
 ## Hotfix
 

lefthook/site.yml

@@ -16,10 +16,6 @@
 # `test:unit:precommit` replaces `test:unit` for the pre-commit unit step, and
 # `check:precommit` replaces `check` for the typecheck step.
 
-templates:
-  # Package manager: pnpm when the repo is a pnpm project, bun otherwise.
-  pm: "$(if [ -f pnpm-lock.yaml ]; then echo pnpm; else echo bun; fi)"
-
 templates:
   # Package manager: pnpm when the repo is a pnpm project, bun otherwise.
   pm: "$(if [ -f pnpm-lock.yaml ]; then echo pnpm; else echo bun; fi)"