A board that tells the truth. The work itself moves the cards; people step in only at the decision points. Step a ticket through every scenario below to see who acts, when, and what happens.
Pick a scenario. Press play or step through. Teal = automated system event · amber = human gate · coral = rework · violet = blocked flag. The Automated steps are the planned target — not built yet; the board is manual today.
Three humans, one robot. Small, clear surface area each.
Each env satisfies exactly one column. The merge gate sits after Code-Review + QA. Every deploy is linked to its Jira ticket, so you can see where a ticket is deployed right on the card.
Per-PR pr-<slug> namespace via the preview label. QA tests here.
Integrated :develop env (Argo-synced). PM demos here.
Pre-prod validation after PM sign-off.
Ships as a batch: approved tickets ride a release/build-… branch merged to production.
Almost nobody drags tickets by hand. Doing the work moves them. People touch the board only where reality can't speak.
| Transition | How it happens | Triggered by |
|---|---|---|
| → Todo | hand-move · backlog grooming | PM |
| → In Progress | hand-move · dev picks it up | Dev |
| → Code Review | auto · PR opened | system (dev's PR) |
| → Ready for Testing | auto · preview deployed | system (dev's label) |
| ← In Progress · changes requested | auto | system |
| ← In Progress · QA fail | QA clicks ✗ QA Fail (in Jira) → also flags the PR | QA |
| → Internal Review | auto · merged to develop | system (dev's merge) |
| ← In Progress · PM reject | hand-move back + comment | PM |
| → Staging | auto · staging deploy | system (after PM's promote) |
| → Ready for Production | hand-move · approved → joins release branch | PM |
| → Done | release · release/build-… merged to production | Release owner |
Highlighted rows are the only times a human drags a card. QA works entirely in Jira — a ✓ QA Pass / ✗ QA Fail button on the card (Pass green-lights the PR and keeps the card in Ready for Testing; Fail sends it back). Everything else, the work moves it.
Expected at the QA-fail and PM-reject gates. The automation only ever moves cards forward, so it won't fight you. When the fix is re-deployed, the card re-advances on its own.
The board now lies — nothing was actually built or shipped. Moving a card never triggers a deploy. The nightly check catches the drift. Rule of thumb: don't drag forward — do the work and let it move.
Dragging into Ready for Production is the design — it's the “approved for the next release” signal. The release that follows is a separate, deliberate step.
Reality is the source of truth; the board reflects it. Moving a card never causes a deploy or release — it only changes the label. (The single cross-over: QA's ✓/✗ from Jira adds a label + ping on the PR — still never a deploy.) Move cards only where the table says “hand-move.”
The assignee is updated manually as the ticket moves (Dev → Reviewer → QA → PM). No custom field, no filters — a role finds its work in its column.
| To find… | Where |
|---|---|
| A role's whole queue (e.g. everything awaiting QA) | the column — e.g. Ready for Testing |
| What I'm working on | assignee = currentUser() |