How does your first ticket move from your tracker to a merged pull request?

What has to be in place first?

A Team with a repository attached. The fastest one is a Team on your own tickets: sign in, connect GitHub, pick the repository, and Create. Wright, Reeve, and Proctor come on, with Wright supervised by you, which is the right place to watch a first ticket. Proctor posts its reviews on its own and marks Wright’s drafts ready. Your open tickets from Linear or Jira are already listed on Work when the page opens.

How does the ticket move, step by step?

1. Start it. On Work, click Add tickets and pick one from Linear or Jira, or click Start on one of your own tickets under Proposed. It lands in Plan, accepted by you, and Wright begins. A ticket Bailey proposed waits in Proposed until click one: Start plan, or Doesn’t need work.
2. Approve the plan. Wright drafts a plan in a sandbox against the repository, answering what it can from the decision ledger and asking what it cannot. Reeve reads the plan and critiques it in place. The open questions arrive as taps on the case file. Answer them, then click two: Approve plan, or Send back with a note.
3. Wright builds. Commits and tests on a branch, then a draft pull request. Nothing touches the trunk. The ticket reads Build, then Review when the pull request opens.
4. Proctor reviews. One review through its checks, then Wright answers each finding with follow-up commits, up to the rounds you allow. When Proctor’s verdict is approve, the pull request comes out of draft with no click from anyone, because Proctor’s line starts autonomous. Move the line to supervised and it takes one click from you to confirm the verdict.
5. Fletcher walks it (beta). With the Team’s repository environment working, it boots the app at that revision, writes a test plan from the change, walks it in a browser, and attaches the video, the screenshots, and a verdict.
6. You merge. Click three: merge on GitHub, or click Merge on the case file if your workspace has the in-app switch on. The merge webhook moves the ticket to Done with a Receipt naming who merged and the commit. Harper’s Daily Brief names it the next morning.

Which three clicks are yours?

Accept the proposal, approve the plan, merge. They are the decisions a supervised Team stages, and each one is a button in the footer of the case file with its consequence written beside it. As you move lines to autonomous on the Ladder, the plan approval can become the Team’s to answer on its own, and so can accepting proposals, up to the tickets per day you set. The third never does: merge is always a person’s click.

There is one more ask you may meet: a build that stops because it needs something only a person has, a credential, a product call, an answer the record does not hold. It reads Stopped to ask on the row, and answering it resumes the run.

What do you read before you merge?

One page. The case file holds the proposal and its case, the plan with your answers, Reeve’s critique, every run and what it cost, Proctor’s review with the findings it discarded readable behind it, and Fletcher’s video. The pull request link sits beside them. You are not reconstructing a decision from a thread. It is all on the ticket.

What happens after the merge?

The ticket stays as the record, and three things compound. The decisions behind the merge land in the ledger, so the next plan reads them instead of guessing. A correction you made becomes a proposed Playbook rule you adopt or dismiss. And the outcome lands on each line’s track record, which is what you read when you decide to move a line to autonomous.