Pass, fail and retries
Where a card goes when the work passes, fails or is blocked, what the retry limit is for, and how to design a loop that closes.
A worker finishes with a verdict. The three routing settings on a station decide what that verdict does to the card — and they are rules the system enforces, not prompts. The agent reports the outcome; the system makes the move.
Each of the three can point at a column of this workflow or at a station in another workflow of the same factory. This page covers the first; Handoffs between workflows covers the second.
When it passes
Where the card goes when the worker passes. Usually the next station; on the last one, Done.
When it fails
Where the card goes when the worker fails — and the reason goes with it, written into the card's discussion.
From QA, that is normally back to Development. The engineer's next run reads the thread first, so it starts from what actually happened rather than from the story title. This is the single most valuable handover in the product: a failure that carries its evidence is a different thing from a failure that carries a status.
When it is blocked or out of retries
The escalation station. A card lands here when it has used its retry limit at a station, or when the worker reports blocked and cannot continue.
Put a person on this station. An escalation station staffed by another agent is not an escalation; it is the loop with an extra step.
Retry limit
A number from 1 to 10: how many times one card may come back to this station before it escalates instead.
Development ⇄ QA is a loop, and a loop without a bound is a bill. Three is a reasonable default:
- First attempt.
- Second attempt with QA's findings.
- Third attempt — and if that fails, a person should look, because two rounds of evidence did not fix it.
Designing a loop that closes
A complete delivery loop, with the settings that make it one:
| Station | Worker | Starts when | Passes to | Fails to | Blocked / out of retries |
|---|---|---|---|---|---|
| Backlog | Sarah (BA) | you ask her | Design | — | — |
| Design | Zoe (Designer) | dropped | Development | Backlog | Human review |
| Development | Alex (Engineer) | dropped | QA | Design | Human review |
| QA | Maya (QA) | dropped | Human review | Development | Human review |
| Human review | A person | — | Done | Development | — |
| Done | — | — | — | — | — |
Read it as a sentence: analysis produces a story, design specifies it, development builds it, QA verifies it, a person approves it. Failures go back one step. Anything that cannot be settled in three passes goes to a human.
What a verdict actually contains
Because every shipped skill ends with "Finish with evidence, remaining gaps and a pass, fail or blocked outcome", a verdict is not a status. It is:
- what was done,
- the evidence for it,
- what is still missing,
- and one of pass, fail or blocked.
That is what the next worker reads, and it is why the loop converges instead of bouncing.
Blocked is not failed
A worker that cannot verify something reports blocked. Blocked means "I could not find out", not "it is wrong" — and it routes to escalation rather than back down the line, because sending it back to Development would ask the engineer to fix something nobody has established is broken.