Landing PRs

Many agent threads build and land PRs in parallel. Each thread owns its PR end to end: it verifies the PR, runs bounded review rounds, resolves its own conflicts, and merges.

Verify: a swarm breaks each PR

Agents verify behaviour by using it; a growing script suite is not the goal. Every gate added here slows every PR, so add none.

• A PR that changes Machine behaviour (daemon, Docker, WireGuard, ZFS, moves, deploys) sends a swarm of 2-3 agents before it goes ready. Each agent boots its own Boat (the verify-server skill, or core/scripts/verify-cluster) and tries to break the changed feature the way a real user would: the happy path, the edges, and what the change might break nearby. Give each agent a different angle. Agents drive the CLI and dashboard by hand; they write no scenario scripts.
• A swarm agent's report is the commands it ran and the end state it observed. A break it finds gets fixed in the PR, then the agent that found it reruns its angle.
• Put each agent's evidence in the PR body.
• A PR that leaves Machine behaviour alone skips Boat. Verify dashboard UI with the verify-dashboard skill.
• Merges run no scenario suite.
• Releases are Nick's job; agents leave them alone.

Review: bounded rounds

• Stop at the first round with no BUG-class finding.
• A finding is BUG-class when the PR leaves behaviour worse than main. File a defect that main already has as an issue, and keep it out of the PR.
• Only BUG-class findings start another round. Speculative, minor, style, and repeat findings get noted or dropped. A round starts for a known finding, never for what a reviewer might still find.
• When the same function needs its second fix, rewrite that function's whole contract before you patch it again.
• A large push during review restarts at round 1.
• CodeRabbit sits outside the gate. Change code only for a finding you accept on its merits.

Why the bound: across 45 PRs and 566 findings, 41% of real bugs came from earlier review fixes. Speculative findings rose from 24 in round 1 to 76 in round 3 and later. The Codex panel had a 60% real-bug rate; CodeRabbit had 11%.

Land

• Open PRs as drafts. CI skips drafts, so push freely while the work settles.
• Run gh pr ready <n> once the branch is done. That starts CI, and every later push runs it again. gh pr ready <n> --undo pauses CI while you rework.
• Once review is clean, queue the PR: gh pr merge <n> --auto. Never merge with --admin, which skips the queue.
• Main has a merge queue. A PR joins it once "CI ready" passes on its head and it has no conflicts. The queue then runs CI again on the PR merged with main and the PRs ahead of it, and merges it (as a merge commit) only if that run passes. Two PRs that pass alone but break main together fail there instead of on main. The branch does not need to be up to date with main.
• A PR the queue drops for a failed run stays open. Fix it if the failure is real, then queue it again with gh pr merge <n> --auto.
• Keep stacks short and merge each layer as soon as it is green. Ship unfinished work dark, behind a flag, in place of a tall stack.

Conflicts

• The thread that owns the PR resolves its conflicts. Enable rerere (git config rerere.enabled true) and rebase with git rebase --update-refs so every layer of a stack moves together.
• Registries are conflict hotspots: schema.ts, cli/mod.rs, handlers/mod.rs, change-log.sources.ts. Where the code allows, add one file per entry so parallel PRs touch different files.

Main is red

Revert the culprit first, then fix forward in a new PR. A main run that started always finishes, but a newer push replaces one still waiting, so main skips commits. When the commits before the red run show cancelled, the culprit may be among them: check those predecessors.