Lanes, and why there is only one kind
What the retired spec/impl worktree pair was for, and what replaced it
Lanes, and why there is only one kind
A Trove lane is one unit of concurrent effort the Operator can watch and steer: one worktree, one branch, one session at a time, working one plan or one work unit.
That sentence used to be longer. A lane was a pair of worktrees — a
lane-N-spec where you wrote the specification and a lane-N-impl where the
machine implemented it — joined by a choreography of rebases and merges that
carried work from one side to the other. This document explains why that is gone,
because the shape it left behind is still visible in older branches and in
anything that remembers the two-phase vocabulary.
Why the pair existed
The pair solved a real problem: the Operator wanted to keep editing the spec while a session was implementing it, and both were files in the same repository. Two worktrees meant two checkouts, so the session's commits never fought the Operator's edits. The cost was the choreography — sync down before implementing, sync up afterwards, then merge, with conflicts possible at each step and a half-finished rebase to recover from when one failed.
Why it does not any more
Specs are rows in a database now, not files in a branch. The spec worktree was a checkout of documents that no longer live in the repository, so the reason for the second worktree evaporated: there is nothing in it to edit.
With one worktree per lane, integration stops being a local merge dance and becomes ordinary git. Every box — this one, or another machine in a fleet — pushes to the same shared origin through normal git authentication. Code produced by a lane lands the way code has always landed. The only thing every box has to agree on is the origin URL.
What replaces the phases
Lanes used to carry a phase — Draft → Auditing → Implementable → Building → Landed — that decided which surface a lane's card appeared on: the cool Spec
desk for design, the warm Build board for execution.
The Spec desk is retired. Authoring is a conversation now, so there is no wall of design cards to sort. What remains is the board, showing lanes that are running work, and the real state is read from the work units themselves: what is claimed, what is in progress, what finished satisfactorily and what did not. A lane's status is derived from the work rather than declared alongside it.
What a lane still guarantees
- One session at a time. A lane is a place work happens, not a queue.
- Its own worktree. Two lanes never write the same checkout.
- A claim, not a lock. A lane holds a work unit under a lease. If the lane dies, the lease expires and the unit returns to the pool — a crash cannot make work permanently unclaimable.