Rounds and pull requests

A squad outlives the feature it was created for, so the unit of work is the round, not the session.

One round is one feature. One integration branch. One pull request.

Sealing

When the orchestrator opens the pull request, the round is sealed. While it is sealed, three tools refuse:

• spawn_agent
• merge_agent
• open_pull_request

The reason is straightforward: anything they did would land on a branch you have already been asked to review. A pull request that grows commits after you started reading it is not a pull request, it is a moving target.

The next prompt is a decision

Because of the seal, the message you send after a delivery is a decision before it is a task, and only the orchestrator can tell the two apart:

• start_round if you are asking for something new.
• continue_round if you are amending what was just delivered.

Fleet nudges by prefixing a note to your prompt, and it guarantees by refusing the three tools until one is called.

What start_round does

It moves the orchestrator's existing worktree onto a new branch, and where that branch starts from depends on what happened to the last one:

• From origin/<base> once the previous round has merged.
• From the sealed branch while its pull request is still open, so the next feature is not written against code the agents cannot see.

It retires the round's agents by archiving them. Their checkouts are reclaimed; their transcripts and their branches are kept. An agent from a delivered round sits on a branch that was merged into a branch that has itself been delivered, so re-briefing it would put work somewhere nothing will read it. The new round spawns what it needs.

Retiring is never forced and never fatal, the same way reclaiming a worktree after a merge is not.

The plan gate re-arms, because a plan gate is per feature. Without that, the second feature would be the only one nobody planned.

The cap on agents per squad counts the round, not the squad's whole life.

What continue_round does

Keeps the branch and keeps the pull request, and only clears the seal. A later open_pull_request pushes to the pull request the round already has, rather than asking gh to open a second one for the same head.

Use it for review feedback on the delivery you just made.

Archiving a squad

Archiving a squad archives its agents with it. Nothing else would ever reclaim their checkouts: the pull request watcher skips workers by design, because a worker's branch is not what got merged.