Run a plan

A plan is a selection of work to do now: whole specs, plus any individual side quests you want included. Running it means handing its work units to lanes and letting them work.

Make the plan

Ask, in the OPAL conversation:

Make a plan covering the gait spec and the BLE reconnect side quest.

Trove creates it and tells you its key. A plan holds no progress of its own — it is a selection, and progress is counted from the units it points at whenever you ask. That is why you can keep editing the specs while the plan runs and nothing goes stale.

Send it to a lane

Run the gait plan in lane 1.

Trove picks the next runnable unit, claims it, writes the briefing into that lane's worktree, and starts a session. Ask again for another lane and it picks a different unit — the first is claimed, so it will not be handed out twice.

What the session is told

The briefing that lands in the lane's CLAUDE.md carries the unit's instruction, its Definition of Done, its key, and — importantly — how to reach the database, because the spec is not in the worktree. A session that did not know that would search the tree, find nothing, and invent requirements to fill the gap.

It also carries the session's two obligations: renew the lease while working, and set a terminal status when finished.

Watch it

Ask:

How is the gait plan doing?

You get counts derived from the units themselves — total, terminal, done — and the open ones by name. Or open the project board's Build tab, where each lane's card shows what it is on and what its session is doing right now.

You do not have to watch. Lanes keep going when you are not looking.

When something does not land

Not every unit finishes cleanly. Some stall, some finish failing, some finish and spawn follow-up work.

Regroup the gait plan.

This re-opens the unsatisfactory ones so the next dispatch picks them up. It runs one round and tells you what it re-opened — how many rounds are worth trying depends on the budget you have left, which is your call rather than Trove's.

Add "including the rejected ones" if you want it to reconsider work somebody decided against. It leaves those alone by default: a rejection is a decision, not a failure, and quietly overturning it would be worse than missing it.

When a definition changes mid-flight

If you edit a unit's instruction or Definition of Done after it finished successfully, it goes stale — and its recorded evidence stops counting. That is deliberate: a test run that passed was measured against the definition it had then, so it is evidence for something the unit no longer is.

A stale unit cannot re-claim success on the strength of the old green. Regroup picks it up and it gets done again, against what it now says.

If a lane dies

Its claim is a lease, not a lock. When the lease expires the unit becomes available again, and the next dispatch takes it. A crashed session cannot make work permanently unclaimable.

If the session merely failed — reported an error rather than vanishing — the claim is released immediately, so you do not wait out the lease to retry.