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 = safeguard. Steps marked built run today; the rest are the planned target.
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. The deploy comments the link on the ticket and moves the card here. QA tests here.
Integrated :develop env (Argo-synced). PM demos here.
Pre-prod validation after PM sign-off.
Ships as a release: develop → master promote, tag YYYY.MM.DD — the tag creates the GitHub Release and moves every shipped ticket to Done. built
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 |
|---|---|---|
| → To Do | 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 + link commented on the ticket | 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 the next release train | PM |
| → Done | release · CalVer tag YYYY.MM.DD pushed → automation releases + moves the whole batch built | Release owner |
| → Blocked | hand-move · parked with a comment naming the impediment | Dev |
| ← back from Blocked | hand-move · impediment cleared → back to the column it left | Dev |
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). Blocked is a column (kept as today): park the card there with a comment, drag it back when cleared — automation never touches it. 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: promote, tag, ship.
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() |
What already runs, what's next, what's later. Statuses are being name-synced across VCORE / MDR / OHD so one mechanism serves every project.