The delivery flow
The board is a grid: the stages a ticket passes through across the top, and who did the work down the side. Nobody moves a card. Every position on it was reported by the work itself.
The stages
A ticket sits at exactly one of eleven stages.
| Stage | What it means |
|---|---|
| Backlog | The tracker knows about it. Nobody has started |
| Local Dev | Somebody is changing code for it |
| Local Test | Tests are running, or have run, on a developer's machine |
| Local Audit | A review or a scan is running against the change locally |
| Merge | The change is at the merge gate |
| CI / Build | A build is running |
| Deploy Dev | It is being deployed to a development environment |
| Test Dev | Tests are running against what was deployed |
| Dev Audit | A review or a scan is running against what was deployed |
| Verified | It stood up in the development environment |
| Prod Review | The tracker says it is done. A person decides what happens next |
Who reports what
- The plugin, from your editor's own hooks: backlog, local dev, local test, local audit, merge, deploy, test and verified — derived from edits and from the test, audit, merge and deploy commands you were running anyway.
- Background reporters, for work nobody is watching: CI builds, deploys, tests run against the environment and audits of it.
- Your tracker, for backlog and for prod review.
The lanes
The board's rows are who did the work: Human, Claude Code, CI / Automation and Environment. The same ticket can appear in more than one lane as it moves, which is the point — it is how you see that a person wrote it, an agent tested it and CI built it.
The matrix above the board is the same two axes counted rather than drawn: actors across stages, with a click selecting a ticket.
Rework
Rework is never a column. When a gate fails, the ticket is drawn at the gate that failed, with a loop back to it, rather than in a column called broken.
A failed local test run is a local rework recorded against Local Test. A failed build is a dev rework recorded against CI / Build. An issue reopened in your tracker after being done is a rework recorded against Prod Review.
Drawing it this way is what lets the board say which gate is sending work back, which is a different and more useful question than how many tickets are broken.
The arrows
There are three kinds of arrow, and each one comes from somewhere different.
| Arrow | Where it comes from |
|---|---|
| Link | A relation in your tracker, or one a reporter stated: blocks, blocked by, related |
| Plan | A dependency recorded by a workflow run, with the reason planning or a team gave for it |
| Rework | The backward move itself, labelled with the gate that failed |
A dependency has a direction: one end is the ticket waiting, the other is the ticket being waited on. A *related* link says two issues touch and gates nothing. A duplicate is the same issue twice and gets no arrow at all.
If the other end of an arrow is not on the board — filtered away, or a key your tracker names that nobody has reported — the arrow is still drawn, to the edge of the card, labelled with the key. An edge that is true is not hidden because one end is off screen.
Reading a card
Hover a card for its summary: the stage, the status, who is on it and the short sentence the last report carried.
Click it to open the panel, which has the ticket's own timeline — every event any reporter has recorded, oldest first — its links and dependencies, and what your tracker says about it.
Every one of those is derived state. There are no prompts in it, no diffs and no logs, because none of those ever left the machine.