docs: put the merge first in the wrong-base recipe (improvise-1xfb.1)

Review of #305 at ac2efdc8: "no merge can do it" is false when the
foreign commits belong to an open PR that will land as a merge commit.
Stack on it, or wait for it and merge a newly pinned gh/main. cherry-pick
-x is kept only for commits that will never reach main as they are.
Rule 8 now says to re-pin before merging a newer main (improvise-79h5,
first half), and context/cloud-agents.md states the new rule.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VdfEGXA7aJ6ftMsCc9PJze

.agents/skills/wave/agent-rules.md

@@ -41,8 +41,9 @@ not in a second copy.
    repository, so `gh/main` moves whenever another session fetches. Re-resolve
    only on purpose, for example when you mean to merge a newer main. Rule 3's
    check before a PR is such a time.
-8. **Reconcile diverging history only by merge.** To take a newer main, run
-   `git merge <SHA>` with the SHA you pinned (rule 7). Merge commits and plain
+8. **Reconcile diverging history only by merge.** To take a newer main,
+   re-pin on purpose first (rule 7): `git fetch gh`, then `git rev-parse
+   gh/main`. Then run `git merge <new SHA>`. Merge commits and plain
    WIP commits are what the rule wants. What it forbids is rewriting history:
    - never `git rebase`;
    - never squash, in any form: `git reset --soft`, `git merge --squash`, a
@@ -64,12 +65,17 @@ not in a second copy.
      rule 3's numstat caught it before the push.
 
    A cherry-pick copies a change and drops its causal link, so use a merge
-   wherever a merge does the job. The one place one cannot: a branch that
-   carries another PR's unmerged commits. A merge only adds ancestry and
-   cannot leave those commits out. So cut a fresh branch from your pinned SHA,
-   `git cherry-pick -x` your own commits onto it (`-x` records where each came
-   from), and close the old branch rather than force-pushing it: `AGENTS.md`,
-   "Shipping a wave".
+   wherever a merge does the job. That includes a branch that carries another
+   PR's unmerged commits, when that PR is open and will land as a merge
+   commit. Either stack on that PR, or wait for it to merge, re-pin, and merge
+   the new SHA. The foreign commits then leave your diff.
+
+   The one place a merge cannot help is commits that will never reach main as
+   they are. That means an abandoned or rebuilt PR, or commits that exist only
+   on a mirror or a local main (#148). Only then, cut a fresh branch from your
+   pinned SHA and `git cherry-pick -x` your own commits onto it (`-x` records
+   where each came from). Close the old branch rather than force-pushing it:
+   `AGENTS.md`, "Shipping a wave".
 
 ## Commit early: a worktree is not durable storage
 

AGENTS.md

@@ -149,13 +149,18 @@ once prescribed exactly that command (see "Repository policy over the Beads bloc
 It cost a review round on PR #145,
 where four unmerged commits — including another PR's whole diff — were pulled
 into a branch based on `gh/main` and had to be rebuilt by cherry-picking.
-That rebuild is the **one sanctioned cherry-pick**, and it is sanctioned because
-no merge can do it. A merge only adds ancestry, so no merge yields a branch
-without the other PR's commits. Reverting them in the branch is worse, because
-merging the branch would then land an undo of that PR. So: cut a fresh branch
-from the pinned `gh/main` SHA, `git cherry-pick -x` only your own commits
-(`-x` keeps the link to each original), open a new PR, and close the old one
-without force-pushing it.
+Today the repair **starts with a merge**. If the foreign commits belong to
+another open PR that will land as a merge commit, either stack on that PR (see
+the stacked-PR rule below) or wait for it to merge. Then re-pin `gh/main` and
+merge the new SHA, and the foreign commits drop out of your diff. Never revert
+them in your branch: merging the branch would then land an undo of that PR.
+
+`git cherry-pick -x` is sanctioned **only** when those commits will never reach
+`main` as they are: an abandoned or rebuilt PR, or commits that exist only on a
+mirror or a local `main`, as in #148 below. Only then, cut a fresh branch from
+the pinned `gh/main` SHA and cherry-pick only your own commits. `-x` keeps the
+link to each original. Open a new PR, and close the old one without
+force-pushing it.
 ChatGPT Codex caught it; nothing in CI could, because the result compiles and
 passes. The tell is a PR diff naming files the ticket has no reason to touch,
 so **read your own PR's file list before asking for review** — and diff against `gh/main...<branch>`, never the local equivalent. **The second vector is the worktree base**: a branch cut from the orchestrator's *local* `main` inherits whatever that checkout has merged but not yet pushed, and nothing in the branch says so. That hit PR #148 with another PR's whole diff — including `.beads/`, `kb.pl` and `context/repo-map.md`, the three files agents are forbidden to touch, so the review read as a rule violation rather than a base problem. Note the window

context/cloud-agents.md

@@ -136,7 +136,8 @@ environment, where egress leaves through your own network boundary.
   been rejected in review.
 - A merged PR cannot carry follow-up work: restart from the latest default
   branch and open a new PR.
-- Prefer merges to rebasing (`AGENTS.md`), including when bringing the
-  default branch into a working branch.
+- Reconcile diverging history only by merge, including when bringing the
+  default branch into a working branch. Never rebase, squash, amend a
+  pushed commit or force-push (`.agents/skills/wave/agent-rules.md`, rule 8).
 - Keep `context/repo-map.md` and `context/design-principles.md` current —
   they are the two docs agents are expected to maintain by hand.