How a ticket moves through the agent pipeline

A ticket starts with an accepted goal and a place in the board's workflow. The builder edits the repository and produces a committed result. ACP then hands the work to testing and review. A tester can report a pass, ask for changes, or block on infrastructure. A reviewer can approve, request changes, or block. When a stage requests changes, the ticket returns for another attempt rather than advancing because the agent merely finished speaking.

Some projects also run Browser Verify after review. It checks the running interface and can return evidence to the ticket. The optional overseer has a different scope: it can inspect the whole Feature pull request after all member tickets are done. Neither Browser Verify nor the overseer replaces your final judgment about the product.

On the board, open the ticket to inspect the current stage, run output, tests, and review result. A green test only covers the checks that actually ran. A blocked ticket tells you where progress stopped; it does not mean the underlying goal was abandoned. The workflow record decides which action is valid next, so controls can change as the ticket advances or is retried.

A Feature groups multiple tickets into one delivery. Each completed ticket adds its work to the feature branch; the pull request stays draft until the entire Feature has met its gates. Standalone tickets are different: when GitHub publication is available, each one can open its own pull request on completion.

What to do when work is blocked →

Ticket done means its own required stages completed. Feature ready for review additionally depends on the integration result, all tickets, branch synchronization, and any oversight gate. A draft PR is therefore a useful work-in-progress artifact, not a signal that the whole Feature is ready to merge.