Why a Feature has one pull request

A planned feature usually needs several changes that depend on one another. If each ticket opens a separate pull request, a reviewer must reconstruct the intended whole from multiple branches and changing merge order. ACP's Feature path instead gives its tickets a shared branch and one draft PR. Each finished ticket contributes a commit to that branch, so the PR shows the integrated change as it develops.

The first push can open the draft while later tickets are still underway. This makes the work visible without claiming it is complete. Ticket done is a local pipeline result; Feature ready requires all tickets plus integration and publication checks. Optional whole-PR oversight evaluates the combined change, which a per-ticket reviewer could miss.

A draft PR can collect discussion and reveal conflicts early. ACP should only mark it ready after the Feature's readiness checks pass. If the branch head changes after a reviewed state, that evidence can become stale and the gate must be reconsidered. Automatic merge, where enabled, is a later decision pinned to a reviewed head rather than a side effect of one ticket finishing.

This architecture does not mean every ACP change uses a Feature PR. Standalone tickets have their own branches and can open separate non-draft PRs. Mission Build and Change can use a direct project-main route. The workflow is chosen at intake, and that choice determines which integration boundary ACP can honestly claim.

Read the full diff, not only the most recent ticket. Confirm the feature's user journey, tests, and any browser evidence actually cover the acceptance criteria. If a ticket changes a shared interface, inspect the dependent tickets together. The one-PR shape makes this possible, but the quality of the final decision still depends on the evidence and the reviewer.

Learn the delivery routes →