### Autopilot-full

**You own the verdicts, never the PRs. One owner runs each PR from build to merge, and nothing merges without your clean swarm verdict.** For "autopilot this queue", "full autopilot", and one-owner-per-PR programs. Orchestrate runs a standing program whose coordinator lands verified work itself and whose workers never merge. Here each PR's owner carries the whole lifecycle through the merge, and the root keeps only verification, countersigns, and audits.

**Scope in this release.** Children are leaves (`references/fan-out.md`). A child cannot launch children of its own or wait for anything outside its turn. So the root, this session, runs the program and launches every child. Each PR's owner is a role, not one long-lived agent. Each round of it (build, fix, rebase, merge prep, merge) is a fresh leaf child the root launches with consolidated scope, per the hub's Fresh-subagents rule. The root also runs every verification swarm and every watcher. There is no timed audit. The root audits at each child delivery, at each stall or no-progress advisory, and when the operator asks. Without one of those, nothing wakes the root. A full-autonomy grant authorizes no external action by itself (`references/authorization.md`). Pushing, opening PRs and merging each happen only under an operator grant that names that action. Without a grant that names merging, every PR stops at merge-ready and the run delivers what Autopilot-stack delivers.

1. **Mark the operator's items and honor state-then-wait.** Items the operator names stay with the operator. The operator reviews and clicks, and no owner merges one. When the operator asks for the protocol or the plan to be stated, deliver the statement and stop. Execution starts only on the operator's explicit go. Before the go, confirm which of push, PR creation and merge the grant names, and say what the run does without each.
2. **Launch owner rounds with the full lifecycle and an early trail.** GitHub only, through `gh`. Confirm `gh auth status` and `gh repo view` once for the program. Never require Graphite. The owner role for one PR covers build, the first push, a ready PR, self-proof on the real artifact (**principle-prove-it-works**), skeptical Bugbot triage per `references/bugbot-triage.md`, a slop-strip (a manual diff cleanup pass), `/skill:no-comments` (the **no-comments** skill), a rebase onto current trunk, babysit to green (`playbooks/babysit.md`), and the merge itself. Each round is a bare implementer child per `references/delegation.md`, with `model: "task:coding"` and a brief that names exactly which of push, PR and merge it may do. **One owner, one checkout, one PR branch.** Only the build round gets a `worktree` argument: a new branch from committed HEAD, which becomes the PR's canonical head branch when the round pushes it and opens the PR. Every later round of that owner continues in the retained owner worktree. Launch it only after the previous round's process has exited, as a bare child with `cwd` set to that retained path (from the previous delivery or `worktree_list`) and no `worktree` argument, because a new worktree is a new branch that does not carry the PR head or the trail. Its brief carries the canonical PR branch name, the trail path inside that checkout, and the publication mapping (local branch to the PR's remote head branch). The round confirms `git branch --show-current` names the canonical branch before any work, and stops and reports if it does not. A round updates the original PR branch and never pushes a sibling branch or opens a second PR for the same owner. The build round starts a `decisions.tsv` trail per the **show-me-your-work** skill as its first unit, pushes its first branch snapshot early, and opens the PR ready, never draft. After that, it pushes its branch again after every verifiable unit (hooks on, a WIP commit is fine). Open the PR before self-proof so the URL, decisions, and checks form a durable trail. Keep `decisions.tsv` uncommitted and return it with each round's report. The root records every child it launches, with its expected runtime (at least the longest past run of that kind) and state, in the visible checklist that `references/fan-out.md` requires. The build round does the first rebase before the code-ready report and babysit, whether or not trunk has drifted. Fix rounds keep that merge base. An owner round rebases again only at merge prep (step 5), on a `git merge-tree` conflict with trunk, or on a CI failure that comes from a change on trunk. When the shipped code is final, after the slop-strip and `/skill:no-comments`, the round reports the code-ready head SHA. Each later round reports the SHA of each push that changes the patch. Self-proof, CI, and babysit then run alongside the swarm. The CI and babysit waits are the root's watcher children, and each fix they surface is a fresh owner round. The root marks the PR merge-ready at a head SHA when self-proof, CI, and babysit have finished there. Before a push that starts a round, the round runs the pre-review checks that the repo's AGENTS.md files and rules name for the touched paths, on the committed head. A hook pass is not proof. To publish each rebase, a round pushes only the canonical PR branch, with `git push --force-with-lease` after an `ls-remote` check, and only under the push grant. Never force-push a shared branch. The merge is the one step an owner may not take alone. Step 4 gates it.
3. **Run owners in true parallel and never stack.** Many owner rounds at once when PRs are self-contained, launched in one turn per `references/fan-out.md`: one writer per branch, disjoint files, cross-PR drift absorbed by rebase. Only genuinely overlapping work serializes. Self-contained PRs branch straight off main, and sequenced work is merge-then-branch. One exception: an owner that must split a genuinely dependent change may hold a short private base-branch stack.
4. **Swarm-verify every round before its merge.** A round starts at the owner's code-ready head SHA and at each later push that changes the PR's patch. At that SHA, fan out independent verifiers per the **swarm** skill and aggregate to one verdict. The root launches the lanes per `references/fan-out.md`: verifier lanes on `task:qa` with the Verifier prompt, and review lanes with the Reviewer prompt on exact models from families other than the author's. The merge needs a clean verdict from the round whose patch matches the merge-ready head. Audit the receipts in the merge-ready report before the verdict. The lanes: re-run the gates at that SHA. Prove the load-bearing behavior live on the real surface the change touches (with available project UI or CLI verification tooling). Audit the diff, distrusting the PR body. Run the audit as two or more review lanes with the full brief. Give each lane one main focus, such as consumer parity with trunk, lifetimes and races, or data and config safety. **Regression lane against trunk.** Run the same load-bearing scenario on current trunk. If trunk does not have the feature, record that fact and gate the behavior the diff adds plus the end state the user waits for instead of pretending trunk can produce it. The live lane is the floor, and a verdict without it is not clean. No merge without the root's clean verdict. When the lanes return, send every proven finding against the PR to a fresh owner fix round in one fix-forward. A defect that a lane filed as a note is a finding. For each behavior finding, ask for a red test that covers every site with the same defect. Where no test can show the defect, ask for a repro receipt instead. Add that defect to the next round's review brief. The new head gets a fresh swarm and a fresh verdict, except for lane results that stay valid under the patch-id rule in `playbooks/shipping.md`.
5. **On a clean verdict the owner merges, and a fresh owner takes the next item.** The merge needs both the root's clean verdict and an operator grant that names merging. A full-autonomy grant without it stops the PR at merge-ready, reported with its head SHA. The owner merges only from a head freshly rebased onto trunk. Merge prep never comes before a round's lanes start, and it ends with a rebase onto current trunk right before the merge. After the merge-prep rebase, the round reports the new head SHA. CI must pass on that head before the merge, and the patch-id rule decides whether the round's verdict still holds. Once that head is green and its patch-id matches the verdict's under the patch-id rule in `playbooks/shipping.md`, a later trunk move does not force another rebase. Right before the merge, fetch trunk and check that `git merge-tree` of the head against current trunk is clean. Also check that no path in `git diff --name-only $(git merge-base HEAD origin/main) origin/main` is a path the PR changes or a path that decides which CI runs for it, such as the repo's CI config paths. If either check fails, rebase again, report the new head SHA, wait for CI to pass on it, and repeat these checks. A new head voids the verdict, except for lane results that stay valid under the patch-id rule in `playbooks/shipping.md`. The owner's merge round squash-merges its own PR with `gh pr merge <pr> --squash` and returns. A fresh owner picks up the next self-contained item from the queue, per poteto-mode's Subagents section. Operator-named items stop at merge-ready and wait for the operator's click.
6. **Run the root layer.** A genuinely new raise of a pinned gate or budget value (a limit CI only lets tighten) needs your fresh countersign, granted only after verifier proof. If the operator's grant or standing orders cover approvals, that countersign is the approval. The owner records it in the form that the tool's approval contract allows, with a pointer to the root's countersign. A lane checks the record against that countersign. The root never gives or bypasses an approval that the forge enforces. Absorbing values that already landed on main is drift, not a raise. Run an audit over all owners at each child delivery, at each stall or no-progress advisory, and on the operator's request. Nothing schedules it, so never promise a timed cadence and never leave the audit to memory. At each audit, re-read this playbook from the installed pstack skill directory and audit the operation against it. Fix drift during that audit. Judge each owner by side effects only: commits, pushes, PR or check deltas, and reported trail rows. Collect the decision trails. Treat a child that errors, that passes its expected runtime without a side effect, or that draws a no-progress advisory as stuck. A watcher child still inside its declared wait bound is exempt: its per-minute advisory is informational, and it is stuck only once that bound has passed (`references/fan-out.md` section 6). Cancel it with `subagent_cancel` and, once the cancel is confirmed, launch one fresh replacement with consolidated scope in the same retained owner worktree at once, per `references/fan-out.md` section 4. Do not wait for a polite return. Each audit runs this stuck test over every name on the root's child checklist, with that watcher exemption. A stall never proves or drops the work. When merges batch, run a retro pass and a read-only post-merge bot-comment sweep. Replies to those comments need explicit authorization. The program ends only when no delegated work is left, even after the last merge.
7. **Stand down instantly on the operator's stop.** On the operator's hold or stand-down, call `subagent_cancel` on every running child and launch nothing new. Report what each child had finished. When the operator releases the hold, the next round of each owner is a fresh child with consolidated scope.

**Reply:** the queue with each PR's owner, state, and head SHA. Each verdict and the swarm that produced it. What merged, under which grant, and what each fresh owner took next. Countersigns granted and why. Open operator gates. Where the collected decision trails live.