Recover a blocked or failed ticket

Open the ticket and read the most recent run and stage result. A failing test, a reviewer change request, missing credentials, and an unavailable execution target require different responses. The board's next action reflects its current workflow; do not assume an old Start button or stale browser tab still describes the ticket's state. Refresh the ticket if a control is rejected after another run changes it.

• If tests fail, inspect the named test and the diff; decide whether the code or the expectation should change.
• If review requests changes, read the concrete finding before asking for another builder pass.
• If a provider or executor is unavailable, check the selected model, credentials, and execution location before retrying.

ACP has an Unblocker lane for blocked work. It can retry, propose a patch, escalate, or request a targeted environment repair depending on the failure. Its attempts are bounded. An escalation means the system needs a human decision or an external repair; repeated automatic retries are not an unlimited substitute for that decision.

If you stop a live run, inspect the ticket again before starting the next one. A stop request, completion event, and repository state can arrive at different moments. The current board action and recorded evidence are safer guides than the last message in a chat window.

When asking for help, include the ticket ID, the stage that stopped, the exact error or failed test, and whether the run used cloud or a paired local machine. Avoid sharing tokens or private logs. A precise report helps distinguish a product defect from a temporary provider or environment problem.

How execution locations differ →