/full-patrol

name: full-patrol
description: Suki's full patrol for a queue of independent PRs. Each warrior walks her own route to the end, and Suki inspects every route before the human signs off. Use for autopilot-full, "autopilot this queue", "full autopilot", one owner per PR, or a batch of independent PRs to drive to merge-ready with full autonomy while the operator clicks every merge.

Suki's full patrol

On a full patrol every warrior walks her own route from the gate to the far wall, and no two routes overlap. Suki does not walk the routes for them. She sends her own inspectors to check each one, and only then does she report it clear to the captain, who gives the final word. You own the verdicts, never the PRs. One owner carries each PR from build to merge-ready. Nothing merges until your formation, which never wrote the code, has proven the code that lands and the operator has clicked the merge.

A verdict covers one patch, and green CI covers one head. Step 4 runs a full formation once, and again only for a major change. The patch-id rule in `safe-landing` can carry a lane's result to a new head, and every new head needs its own green CI.

Prove behavior with the project's verify skill (see `vital-signs`), or with Claude Code's `run` skill when the repo has none.

On Codex, read [avatar-mode/references/codex.md](../avatar-mode/references/codex.md) for tool equivalents.

Steps

1. **The operator's gates come first.** The grant covers only the queue's items, so items the operator names as theirs and PRs outside the queue stop at merge-ready. A request to state the plan is not a go. On the operator's go, write the full program objective into the standing orders and restate it in your todolist, so it stands across turns until the queue is done. Before the first owner starts, tell the operator the size of the program: the number of owners, the verifier lanes in the first round, and the ceiling of two fix-forwards per PR from step 4. A program of more than three owners waits for the operator's go on that size, unless the operator's request already named it. 2. **Spawn one owner per PR, and keep its work where a replacement can find it.** Resolve the forge once for the program. 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`). Each owner is a background subagent, dispatched as `team-avatar:appa` with Appa's model from the avatar-setup sheet, in its own worktree. It builds, opens its PR per `yip-yip`, proves the change on the real artifact, drives it to green per `long-flight`, and hands the PR off at merge-ready once steps 4 and 5 clear it. No owner runs the merge. Where the runtime lets a subagent spawn one, an owner may dispatch its own workers and reviewers. Where it cannot, it does that work itself with the same review separation.

Open the PR early so CI and bots run alongside the work. The code is ready only after the `purify` pass and the `clear-water` pass, so the full formation runs on finished code. Then rebase onto current trunk and report the code-ready head before self-proof, so verification runs on the base the patch lands on. Report every later head, and report merge-ready once self-proof, CI, and `long-flight` are done. Fix rounds stay on that base unless trunk conflicts or breaks CI, because each rebase restarts CI. Run the repo's checks for the touched paths on the committed head before the code-ready push and before any later push that needs a verifier.

Assume the owner's session dies. Soon after starting, the owner pushes and starts a decision trail with `battle-map` in the program's store at `${CLAUDE_CONFIG_DIR:-~/.claude}/orchestrate/<slug>/` (on Codex, `${CODEX_HOME:-~/.codex}/orchestrate/<slug>/`), then pushes after every unit worth keeping. Whoever spawns a subagent records its id, its state, and a stuck-after runtime from past runs of its kind in that store, so the root can probe it if the parent dies. An owner force-pushes only its own branch, with `--force-with-lease` pinned to the SHA it last pushed or took over. On any push it did not make, it stops and reports to the root. 3. **Run owners in parallel off trunk, never stacked,** so each PR lands on its own. When the work is sequenced or coupled, use `shield-wall` instead. 4. **Verify with one full formation.** A full `kyoshi-formation` runs once, at the code-ready head. Another full formation runs only for new behavior, a redesign, or a large new diff. A rebase, a merge-conflict resolution, or a minor fix gets a single verifier at the new head. Fan out independent verifiers at the code-ready SHA on Suki's model. They re-run the gates, prove the load-bearing behavior live on the real surface through the verify skill, and audit the diff. Toph takes the diff audit with `earth-rumble`. The verdict is not clean without the live lane, and not before you audit the receipts in the merge-ready report, because no lane trusts a claim it has not checked.

Send every proven finding, whatever a lane labeled it, to the owner in one fix-forward, with a red test across every site that has the same defect. A defect that trunk shows without the PR is recorded against trunk and does not gate the PR. One the PR copies or newly reaches is the PR's own. Never push a fix yourself, because each branch has one writer. Replace a stuck owner instead.

Brief every review lane to report what the diff breaks, not everything wrong in the files it touches. Ask for no mutation or fuzz campaign unless the operator asked for one. Two fix-forwards per PR is the ceiling. When a blocking finding survives the second, stop work on that PR. Report it blocked with the finding and its evidence, and let the operator choose another round, a narrower PR, or closing it. 5. **The operator merges only what you verified, tested on the trunk it lands on.** Green CI alone