### Shipping **You own what lands. Verify each PR independently, land only the verified run from the root, then keep your hands off the queue.** This is the half after `playbooks/babysit.md`. **Scope in this release.** GitHub only, through the GitHub CLI (`gh`). Shipping starts only on the user's explicit request to merge, land or ship, and that request authorizes merging the verified run, nothing more. Each push (above all a force-push), base retarget, verdict comment and auto-merge arming needs its own explicit authorization under `references/authorization.md`. Ask once, up front, naming each action the run needs. Waits run through a one-shot watcher child (`references/fan-out.md`, section 6). A base branch that requires a merge queue is detected in step 1, before any merge or auto-merge command, then reported and left to the operator. Nothing in pstack wakes you between deliveries, so a merge that completes while no child runs is seen at the next wake or the operator's next request. 1. **Confirm the forge and rule out a merge queue, then verify every PR independently.** Confirm `gh auth status` succeeds and `gh repo view` resolves the repository. If either fails, report it and stop. Never require Graphite. Read the trunk name from `gh repo view --json defaultBranchRef`, then read `gh api repos///rules/branches/`. If it lists a `merge_queue` rule, run no merge, auto-merge or enqueue command at all: report the base's queue requirement and each PR's state from `gh pr view`, and stop. If the call fails, the queue state is unknown, so report that and stop the same way. Launch one bare verifier child per PR, not batched, as independent `subagent` calls in one turn per `references/fan-out.md`: the Verifier prompt from `references/delegation.md`, `model: "task:qa"` or an exact model from a family other than the author's, and a brief to exercise the real surface (available project UI or CLI verification tooling) against parent versus head. Each returns `PASS`, `PASS+NOTES` or `FAIL` with its evidence. The verdict lives in your report and the decision trail. Posting it on the PR is a remote comment, so only you post it and only with explicit authorization. Safe means a verdict from an agent that did not write the code. CI green is not a verdict, and an approving bot review is not a verdict. 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 a passing verdict, where both `PASS` and `PASS+NOTES` pass. A verified PR sitting above an unverified one is not landable. Report the ceiling as a PR number and say what breaks the chain. 3. **Re-check that each verdict still describes the patch.** Record the verdict head SHA, base SHA, and stable `git patch-id` of that PR's base-to-head diff. A rebase or base retarget rewrites SHAs and can silently invalidate a verdict without touching a check. Before landing a PR, compare the recorded patch-id with its current base-to-head patch-id. Before comparing, write down this repo's allowlist: the only paths whose changes may keep a lane result. A path is on it only when it lies outside everything the package or build ships and it enforces no behavior, so no test, test fixture, CI config, or lint, typecheck or build config. Package manifests, license and notice files, the changelog, and release docs are never on it, even when the build does not ship them. Files that decide what ships (such as `package.json` `files`, `.npmignore` and `.gitignore`) are never on it either. Record the allowlist in the decision trail before the comparison. A patch that touches any path off the allowlist is re-verified. When every path where the two patches differ is on the allowlist, compare what each lane (each verifier or swarm lane) ran. Run that comparison twice at the verdict SHA and once at the current head. A lane that ran tests compares that test output. Use `npm pack` as the comparison only for a lane with no build output of its own. A difference is noise if the two verdict-SHA runs also show it. An embedded commit SHA is not noise on that basis alone: it counts as noise only when the build stamps it and the source diff does not touch that line. Judge each difference, not each file, and report each kind of noise with its files. If only noise differs, that lane's result stays valid, and checks and a review of the change run fresh. Do not reuse a lane result from a dev server. Rerun that lane. Re-verify anything else when the patch changed. When it did not, keep the code verdict but re-run mergeability and CI at the current head. Never use matching commit messages or a green check from an older SHA as a substitute. 4. **Prepare only the bottom PR.** Fetch current trunk. Rebase the lowest verified branch onto the exact trunk tip when needed, push it with `git push --force-with-lease` after an `ls-remote` check when the force-push is authorized, and retarget only that PR to trunk with `gh pr edit --base ` when the retarget is authorized. Without either authorization, report the prepared local branch and stop. Re-run step 3 after the push. Do not retarget, arm, or merge descendants yet. 5. **Land one PR at a time.** Immediately before each merge or arm command, re-read the step 1 rules call for the PR's base. On a `merge_queue` rule or a failed call, report and stop as in step 1. If the bottom PR is mergeable now, squash it with `gh pr merge --squash`. If requirements are still running and the user asked for merge-when-ready, arm only that PR with `gh pr merge --squash --auto`. GitHub's `--auto` is GitHub auto-merge. Wait for that PR to merge before preparing the next one. 6. **Do not read GitHub `autoMergeRequest` as stack readiness.** At most it says GitHub auto-merge was requested for one PR. It does not prove that a descendant is queued, that a patch verdict is current, or that the contiguous stack is safe. Confirm GitHub's state for the current bottom PR, and say that the state is unknown if `gh` cannot report it. 7. **Recompute after every merge.** Fetch trunk, confirm the merged SHA is present, drop the merged PR from the frozen bottom-to-top list, and inspect the new bottom PR's base, head, checks, and patch-id. A host may retarget a child automatically, but do not assume it did. Repeat steps 3 through 6 for that one PR. Independent work stays outside this chain and ships on its own. 8. **Watch the current frontier until it merges or fails. Do not mutate the stack around it.** After a merge is armed, launch one watcher child that runs `timeout gh pr checks --watch --required` once and reports each check's final state. When its result arrives, read `gh pr view --json state,mergedAt,mergeStateStatus,statusCheckRollup,autoMergeRequest`. The PR has landed only when `mergedAt` is non-null or `state` is `MERGED`. Only then run step 7. Hard-fail only when `state` is `CLOSED` with no `mergedAt`, a required check concludes `FAILURE` or `CANCELLED` and blocks merge after auto-merge is no longer pending, or `mergeStateStatus` is `UNSTABLE` or `DIRTY` with no auto-merge pending. `BLOCKED` while checks are pending or auto-merge is armed is not failure. If the checks have finished and the PR is still unmerged with auto-merge pending, report that state and stop. Read it again at the operator's next request, and never in a loop. Report each merge and the new ceiling. If the frontier stalls, diagnose before mutating. 9. **Stop at the ceiling.** When the verified run is merged, report what landed, what the next unverified PR is, and what verifying it would take. Extending the run is a new pass through step 1. **Reply:** the verified run and its ceiling, each PR's verdict and who produced it, which external actions you took under which authorization, what you armed and how you confirmed it, what landed, and what the next gap needs.