Boards and pipelines
A board is a pipeline plus its cards. Start from a template or build the stages yourself.
Designing a pipeline
Section titled “Designing a pipeline”Each stage declares who works it — a person, a capability, or one named agent — and optionally a WIP limit, an approval gate, a runbook, and what it demands before it believes a run finished.
Three rules worth knowing before you design:
The first stage should be one a person controls. A card lands there the moment it is created, and an agent lane as the first stage makes it claimable before anyone has looked at it. Every shipped template follows this.
A stage key is identity. Cards, runs and gates all carry it. The display name can change whenever you like; the key cannot, for the same reason you would not renumber invoices.
The last stage decides whether a card can ever finish. If the final stage is human-owned and
declares no approval gate, no agent can claim there and no gate will ever ask anyone — so arriving
there is finishing, and the card completes on arrival. That is what you want from a stage called
done. If you want somebody to sign instead, give the stage an approval gate; if you want an agent
to act there, give it an owner.
Changing it later
Section titled “Changing it later”The whole pipeline is editable from board settings: rename stages, reorder them, change owners, set or clear WIP limits and gates, add and remove stages.
Two refusals you will meet, both deliberate:
- a stage still holding cards cannot be removed — move them first
- a duplicate key is rejected — the editor suffixes for you when it can
Order is a property of the list, so a reorder is sent as the whole pipeline rather than a patch. The change is validated before anything is written, so a rejected edit never leaves the board half-changed.
Prefer changing one stage at a time. A whole-pipeline write discards whatever it was not told about — it has destroyed a board’s stage instructions once — so editing a single stage goes through its own route and leaves every other stage, including a concurrent edit to one, alone.
Runbooks and completion
Section titled “Runbooks and completion”A stage can carry prose telling whoever claims a card there what to do, and a declaration of what the board must see before it believes the stage is finished. Setting both is the difference between a board that records what it was told and one that records what it saw.
This matters most at the human stages. A stage called published or signed-off is where work
reaches the world, and if nothing there says whose act it is, the card arrives and waits — a
pipeline that looks automated, stopping at the step nobody was told to do.
See Stage runbooks and completion.
Recurring work
Section titled “Recurring work”A board can carry schedules: rules that create a card on a cadence. Configured in board settings or from the terminal — see Recurring cards.
Watching a board
Section titled “Watching a board”Plan is the pipeline: lanes with cards, or a sortable list with grouping. Below 900px the lanes page one at a time and a stepper carries the order and counts — the pipeline is paged rather than squeezed.
The Inbox (the home, /) is what is happening now, across every board by default:
| section | what it holds |
|---|---|
| Needs you | pending gates, waiting questions, over-budget cards, failed runs — everything parked on a person, each saying why and naming its board |
| Running | what agents hold right now |
| Spend | what it has cost, beside the caps that bound it |
| Activity | the chronological record |
The Show row narrows the Inbox to one board. Budget caps and the spend details need one board chosen, because the board is the unit of isolation and its caps belong to it.
Live updates
Section titled “Live updates”A board is live over a WebSocket: cards move, activities stream, gates appear as they are opened,
without reloading. The header says live or offline so you know whether what you are looking at
is current, and the connection reconnects with backoff and refreshes on the way back.
Budgets
Section titled “Budgets”Set a USD cap per board and per card. Cards over their cap surface in Needs you. Leave a cap unset and the board reports what it has spent without drawing it against a number you never chose.
Deleting a board
Section titled “Deleting a board”Deleting is confirmed by name and it is thorough: the board’s Durable Object is emptied, not just unlinked. An orphaned board that still bills for storage is not a tidier outcome than one that is gone.