Lifecycle
How a brief moves from idea to done — and why the most important rule is that the implementer stops before the finish line.
The five steps
todo → in-progress → implemented → verified → done
| State | Meaning | Who |
|---|---|---|
| todo | Authored, unclaimed, dependencies known. On the board, in Next-up if eligible. | Author |
| in-progress | A session owns it and is implementing. Moved from the queue to active work. | Implementer |
| implemented | The implementer finished and filled the Evidence section with their own run. Implementers STOP here. | Implementer |
| verified | A non-implementer re-ran the Verify table on merged main and filled Evidence (dated, with runner). | Independent verifier |
| done | Verified and carries the recorded review verdict. For human-gated briefs, a review entry naming a human is required. | Verifier + reviewer |
Why implemented is not done
An implementer verifying their own work is assaying their own metal. In multi-agent work this is not a philosophical concern — it is the primary failure mode. Every agent asked whether its task is done will say yes. A verifier drawn from the same fleet shares correlated failure modes with the implementer.
The lifecycle rule — implementers stop at implemented, a non-implementer advances to verified — makes self-grading structurally impossible. That extra step is friction, and the friction is the feature. It does not make the system uncorruptible, but it makes the corruption visible: a brief sitting at implemented with no verifier dispatched is a queue item, not a hidden assumption.
Evidence and review
Verified/Reviewed cells take dated entries (2026-07-08 sonnet-verifier, human:ian), never a bare checkmark. An undated tick is unattributable and unauditable. A dated, attributed entry works like a hallmark: it records who struck it and when.
The two checks are distinct:
- Verify table proves function: "does it work?" Re-running the brief's Verify commands on merged main.
- Review proves quality: "is it well-built?" A code/structure/security pass. Neither substitutes for the other.
STATUS.md: the single-writer rule
STATUS.md at the repo root is generated from the stream READMEs and registers — never hand-edited. It has exactly one writer: main's CI, which regenerates and commits it on every push that touches a source.
- Branches never commit STATUS.md. PR CI runs
--lintmode only and blocks any PR whose diff touches STATUS.md. - One writer eliminates the conflict class entirely. A generated file committed on branches turns every concurrent PR into a merge conflict.
- Regenerate locally freely; never commit on a branch. On a merge conflict, take either side and rerun the generator — never hand-merge a generated file.
Next-up: the cross-stream queue
The generator computes a Next-up batch so a session does not default to "the next brief in my stream" — the rabbit-hole reflex the system exists to prevent. Next-up weighs:
- Priority + staleness — higher-priority and aged streams rise.
- A 2-per-stream cap — no single stream floods the batch.
- Findings exclusion — a brief with an unresolved finding against it is held out.
A known defect: the staleness score rewards neglect regardless of why a stream aged. A value/effort term is a candidate knob — the board is a heuristic scheduler, not an oracle.