How does your first work item move from the backlog to a merged pull request?

What has to be in place first?

A Team that mirrors one of your engineering teams, with the repository attached, a backlog attached, and one accountable person. At least Bailey, Wright, and Proctor engaged on it, plus Reeve if you want a critique on plans and Fletcher if you want browser evidence. Every Engagement starts at Training, which is the right place to watch a first item: nothing moves without you.

How does the item move, step by step?

1. Bailey proposes. It reads the backlog and puts up the next item with the evidence it came from and what it is expected to move. It tags your product manager in Slack for the business read, and their answer in the thread lands on the item. Gate one: you accept the proposal.
2. Wright plans, Reeve critiques. Wright drafts a plan in a sandbox against the repository, answering what it can from the decision ledger and surfacing the questions it cannot. Reeve reads the plan against the Playbook and its watch-set and critiques it in place. Gate two: you approve the plan, with any edits you want in it.
3. Wright builds. Commits and tests on a branch, then a draft pull request. Nothing touches the trunk.
4. Proctor reviews. One review through its checks, then Wright answers each finding with follow-up commits, up to the rounds you allow, until the pull request is clean.
5. Fletcher tests it (beta). It boots the app in a sandbox with your repository environment, writes a test plan from the change, walks it in a browser, and attaches the video and the screenshots. Gate three: unblock it if it needs something only you have.
6. You accept the result. Read the pull request with everything attached and merge it, or send it back. Gate four: accept the result.
7. Harper reports. The standup goes to your channel and the Brief goes out the next weekday morning, receipts attached.

Which four moments are yours?

The four gates: accept the proposal, approve the plan, unblock, accept the result. They are the same at every rung of the Ladder. What changes as an Engagement is promoted is which of them the Team may answer for itself on reversible work. Accepting the result, and the merge behind it, stays with a person permanently.

What do you actually read before you merge?

One page. The case file holds the proposal and its evidence, the approved plan with your edits, Reeve’s critique, every run and what it cost, Proctor’s review with the findings it discarded readable behind it, Fletcher’s video, and the answer your product manager gave in Slack. You are not reconstructing a decision from a thread. It is all on the item.

What happens after the merge?

The item stays as the record, and three things compound. The decision behind the merge lands in the ledger, so the next plan reads it instead of guessing. A correction you made becomes a proposed Playbook rule you adopt or dismiss. And the outcome lands on each Engagement’s track record, which is what you look at when you decide to promote one a rung.