What a blocked ticket tells you
How ACP separates a failed stage from a completed job and brings evidence back to the board.
An agent exit is not a product verdict
A coding agent can exit successfully while the intended change still fails tests, needs review changes, or cannot be published. ACP records separate stage outcomes because a process exit alone is too weak a signal for delivery. The builder must leave a committed result; the tester and reviewer then report their own verdicts. A requested change returns the ticket to the relevant earlier stage rather than making a complete-looking card out of incomplete work.
The workflow also needs to survive interrupted processes and late callbacks. A stale completion from an older run must not move a newer attempt forward. That is why the board's current stage and action are more useful than the last line of an agent transcript.
The rescue lane is bounded
When work is blocked, ACP can send it to an Unblocker that classifies the obstacle. It may retry, patch, request environment provisioning, or escalate. Those outcomes are distinct from tester and reviewer approval; a rescue attempt does not erase a known failure. Attempts have limits so a persistent provider outage or missing permission does not spin forever while the board appears busy.
Some blocks need a person. A missing credential should be fixed in the intended execution location, not copied into a prompt. A conflicting product requirement needs a clarified goal. A source conflict may need a deliberate integration decision. The useful output of the rescue lane is therefore sometimes a precise escalation rather than more generated code.
Use the board as a diagnosis surface
For a blocked ticket, read the stage, latest run, failed test or verdict, and next permitted action. This gives a reproducible starting point for a human or the next agent. Treat the blocking state as information: it preserves the boundary between work attempted and work proven ready to advance.