feat(pstack): add merge-gate and route every merge through it

pstack/skills/poteto-mode/SKILL.md

@@ -25,7 +25,7 @@ Remaining triggers:
 - Shipping UI / IDE / CLI → the matching control skill: `control-cli` (CLIs and TUIs) or `control-ui` (browser / Electron / web UIs). For bug fixes, reproduce first on the same surface yourself. Hand to the user only under the narrow Bug fix step 1 exception.
 - Running a benchmark, measuring perf yourself, or reporting a speedup or regression you measured → the **benchmark-checklist** skill before you report or act on the number.
 - Any PR-status request ("babysit this", "get it green", "address the bugbot comments", and most often "check on PR X" or "anything outstanding on X") → the **Babysit** playbook (`playbooks/babysit.md`). Never triggered by merely opening a PR. Declare its mode before polling. The playbook's step 1 owns the request-to-mode mapping. Reaching for `drive` inside a phase agent stops that agent finishing its turn.
-- Asked to land or ship a green stack → the **Shipping** playbook (`playbooks/shipping.md`). Green is not safe. Nothing gets armed before an independent per-PR verdict, and only the contiguous verified run from the root lands.
+- Asked to land or ship a green stack, or about to merge any PR, including a merge your own plan schedules → the **Shipping** playbook (`playbooks/shipping.md`). Every merge goes through its merge gate. Green is not safe. Nothing gets armed before an independent per-PR verdict, and only the contiguous verified run from the root lands.
 - Bugbot, Codex's review bot, or the agentic security review commented → skeptical posture. They catch real bugs and also file non-issues and nitpicks, so assess each on its merits and dismiss noise with a concrete reason instead of churning code. Triage fix / dismiss / ask per `references/bugbot-triage.md`.
 - Broken skill mid-task → fix it in its own PR. Don't block. Don't silently work around it. A pstack skill's PR goes to `liminal-ai/pstack-lim` against branch `lim`. Once it merges, rerun the per-user install (poteto-help's Get set up, step 1).
 - Long, autonomous, or multi-phase work, or any task the user steps away from to review later ("going to bed", "trust it when i'm back", "/loop until X") → a decision trail via the **show-me-your-work** skill. Commit it when stakes need an auditable record. Keep it local otherwise.

pstack/skills/poteto-mode/playbooks/shipping.md

@@ -2,10 +2,10 @@
 
 **You own what lands. Verify each PR independently, land only the verified run from the root, then keep your hands off the stack.**
 
-1. **Resolve the forge, then verify each PR independently before it lands.** GitHub CLI (`gh`) is the default. If `command -v origin` succeeds and Origin can resolve the repository, use `origin pr` for every PR operation. Otherwise stay on `gh` and record the fallback. Never require Graphite (`gt`). One verifier per PR, a `delegate_task` child on the counterpart of the code author's family (the Counterparts list in the role file, `~/lim-v2/AGENTS.md` or `~/lim-v2/CLAUDE.md`) and never the author, in its own worktree per poteto-mode's Subagents section, runs the change the way a user would with the matching control skill (such as `control-ui` or `control-cli`), parent against head, and posts `PASS`, `PASS+NOTES`, or `FAIL` on that PR. Only a verdict from an agent that did not write the code counts, because an author checks what it meant to build. Green CI and an approving bot review are not verdicts, because neither runs the change as a user would.
+1. **Resolve the forge, then verify each PR independently before it lands.** GitHub CLI (`gh`) is the default. If `command -v origin` succeeds and Origin can resolve the repository, use `origin pr` for every PR operation. Otherwise stay on `gh` and record the fallback. Never require Graphite (`gt`). One verifier per PR, a `delegate_task` child on the counterpart of the code author's family (the Counterparts list in the role file, `~/lim-v2/AGENTS.md` or `~/lim-v2/CLAUDE.md`) and never the author, in its own worktree per poteto-mode's Subagents section, runs the change the way a user would with the matching control skill (such as `control-ui` or `control-cli`), parent against head, and posts its verdict on that PR as a comment line `pstack-verdict: <PASS|PASS+NOTES|FAIL> head=<head sha> base=<merge-base sha> by=<model>`, with its findings below. The merge gate reads that line. Only a verdict from an agent that did not write the code counts, because an author checks what it meant to build. Green CI and an approving bot review are not verdicts, because neither runs the change as a user would.
 2. **Land only the contiguous verified run rooted at the bottom.** Walk up from the lowest unmerged PR and stop at the first one without `PASS` or `PASS+NOTES`. The PRs below it are the run, and the top one is the ceiling. A verified PR above an unverified one waits, because it cannot land without the code below it. One whose branch neither holds nor needs that code can move onto trunk and land on its own. It needs a fresh verdict first, because its old one ran with that code beneath it and trunk does not have it.
 3. **Re-check that the verdicts still describe the code.** A verdict covers a patch, and a chain rebase moves every PR above it to a new SHA without failing any check. So every verdict records the head it verified and that head's merge base with the PR's base branch, both taken when verification runs. Before trusting an older verdict, compare the whole-PR change it saw with the current one. Run `~/.agents/skills/poteto-mode/scripts/verdict-hash.sh <saved-merge-base> <verdict-head>` and `~/.agents/skills/poteto-mode/scripts/verdict-hash.sh <current-merge-base> <current-head>`. The verdict carries only when both succeed and print the same hash. A failure means it does not carry. Never hash `git diff` or `git patch-id` output by hand, because each can match code that runs differently, and the script is where those cases are tested. Use the saved merge base, never one recomputed from today's base branch, because a rebase moves it. Matching IDs carry the verdict to the current head. When the patches differ only in tests, docs, or lint config, a lane's result stands if what it ran builds the same at both heads apart from noise. Noise is a difference that also shows up between two builds of the verdict head, or an embedded commit SHA. Report each kind of noise with its files, so a reader can check the call. The change itself still gets fresh checks and a review, because the old verdict never saw it. A lane with no build output, such as a dev server, cannot show this, so rerun it, and re-verify anything else that drifted.
-4. **Land bottom-up, one PR at a time.** Always merge the run's lowest unmerged PR, with `origin pr merge <pr>` or `gh pr merge <pr> --squash`. On Origin the plain command also merges every PR below the one you name, and on GitHub a PR whose base is still its parent's branch merges into that branch, not trunk. Read the PR back for the result (`origin pr view <pr>` or `gh pr view <pr> --json state,mergedAt,baseRefName`), because a merge command can report success when a merge queue only queued the PR, and a requested auto-merge is not a merge. A landed PR reads merged with trunk as its base, not its parent's branch. Arm `--auto` (Origin merge-when-ready or GitHub auto-merge) only on a PR whose verdict covers its current head, because it lands whatever head is ready. After a merge lands, retarget the PR whose base was the merged branch to trunk (`origin pr edit <pr> --base <trunk>` or `gh pr edit <pr> --base <trunk>`), move its patch onto the merge result, and push with `--force-with-lease`. The verdict covers the patch, not its commits, so step 3's diff rule decides whether the verdict survives. Merge it once its checks pass and its verdict survives.
+4. **Land bottom-up, one PR at a time, only through the merge gate.** Always merge the run's lowest unmerged PR with `~/.agents/skills/poteto-mode/scripts/merge-gate/merge-gate --repo <owner/name> --pr <pr>`. Never run `gh pr merge` or arm auto-merge yourself. At the PR's current head, the gate checks that every check passed (Bugbot is not waited on), no review thread is open, the verdict covers the exact code (step 3's hash), Codex has reviewed that head, and Lee approved the exact text of any AGENTS.md or CLAUDE.md change. If anything is missing it merges nothing and prints what is missing and what to do. Otherwise it merges, reads the PR back, and fails unless it reads merged into trunk. `--check` runs the same checks without merging. The gate works through `gh`, so on Origin stop and report. After a merge lands, retarget the PR whose base was the merged branch to trunk (`gh pr edit <pr> --base <trunk>`), move its patch onto the merge result, and push with `--force-with-lease`. The verdict covers the patch, not its commits, so step 3's diff rule decides whether the verdict survives. Run the gate on it once its checks pass.
 5. **Leave the stack alone while it lands.** Step 4's move of the next PR is the only change to a branch or base, because a merge lands whatever its branch and base hold at that moment, verdict or not. On both forges, keep the fallback heartbeat per the Waking and polling section of the role file (`~/lim-v2/AGENTS.md` or `~/lim-v2/CLAUDE.md`), because a watch ends on merge and the heartbeat is what notices it. On GitHub, arm `watch_pull_request` on the run's current bottom PR. On each wake, run the queued watcher from `playbooks/babysit.md` (`scripts/watch-pr/watch-pr --queued-stack --stack-prs <bottom-to-top> --status-only`), read the PR back as step 4 says, and re-arm the watch on the new bottom PR, until the ceiling reads merged. On Origin, re-read the current PR with `origin pr view <pr> --checks` each time `origin pr checks <pr> --watch` returns, until the ceiling reads merged. A base that moves to trunk when its parent merges is expected, not damage to repair. If a merge stalls, find out why before you change anything.
 6. **Stop at the ceiling.** Extending the run takes new verdicts, so it is a new pass through step 1.