## Why one spec at a time

One spec is active at a time, and no two agents write coupled code at once. For a person who directs and does not type, the bottleneck is how much code can be reviewed before the next thing is built on it. Ten features in parallel are not ten times the progress if you can review two. Read-only work (sweeps, probes, verification runs) fans out freely. Across a team, two people can each run a spec on their own branch: the audit refuses overlapping closes as above, and the forge check judges every merge. What Setlist does not have, by design, is a coordination plane inside one checkout. What it has instead is the spec board: `/setlist:board` reads the trunk and the remote from any clone, with no server, and shows every claim, its driver and branch, and every collision it can see, such as one number claimed twice (the next number is taken from the trunk and the remote's spec branches, and when two cuts still collide the first trunk landing keeps it; since 2.15.0 the second is refused at push, `SLH-CLAIM-NUMBER-TAKEN`) or two ACTIVE specs declaring one file; it refuses nothing, and it cannot see a claim nobody pushed. The push race is the lock: when two people flip one spec, git refuses the second push, and the checkpoint fetches and reports who holds the spec. The board shows stale claims, ACTIVE specs whose branch has had no commit for `stale_days` (seven by default), with their drivers, and counts ACTIVE specs per driver without limiting them.