Review, pull requests and merge

The last stretch of the line is where a change earns its way onto main. This page covers the two kinds of review, local merges and pull requests.

Review against the original ask#

Agents tend to grade their own work generously. A fresh reviewer that never saw the build chat checks the change against what was asked for. It is on for the Assured lane, for any lane at L2 or above, and wherever you switch it on in Customize → Lanes.

The reviewer is read-only and sees only:

• the original ask, word for word;
• the approved plan or spec;
• the diff and the full changed files;
• the commit messages;
• the project's AGENTS.md or CLAUDE.md.

It grades the change A to F and marks every requirement met or not met. It passes only when every requirement is met and no medium or high gap remains. Gaps go back to the build chat automatically for up to two rounds; after that the item waits for you. In the drawer:

• Send gaps to the build drafts the gaps into the build chat for you to edit and send;
• Accept as is… moves on anyway, with a note saying why;
• Re-run reviews again. The review also re-runs on every new commit.

The reviewer uses the Code review · the grader role in your Model policy. Pick a different model from the one that builds, so the agent isn't marking its own homework. See Connect your models.

The lane's review#

• By a person (Standard and Assured): Approve the change when you are satisfied. Review the change opens the guided walkthrough (riskiest files first, boilerplate folded; see Intelligent review). Verify (L‹n›) runs the assurance checks for the item's level (see Assurance levels).
• By the policy engine (Express): Warden runs the assurance checks up to the lane's level, plus the build's worklist of things found during the build, then asks your rules whether this change may go on unattended.

Local merges#

A lane set to Deliver: Merge here merges on your Mac with git merge --no-ff, pinned to the exact commit that was reviewed. Warden then removes the worktree.

It merges by itself only when every one of these holds:

1. the lane (or a Who decides rule) sets merge to When policy allows;
2. the review is approved, by the policy engine or a person;
3. the review against the original ask passes, if it is on;
4. your rules allow the merge (see gates);
5. git merge-tree predicts no conflict;
6. your project checkout is on the target branch.

Otherwise it waits on Merge for a person. A merge is refused while your checkout is on another branch (The project checkout is on X; switch it to main to merge into it), or when your uncommitted changes overlap the files being merged.

Pull requests#

Set a lane's Deliver to Open a pull request and the Factory pushes the branch and opens the PR itself once review passes. On any item, Open a PR instead does the same by hand. You need the GitHub CLI installed and signed in (gh auth login).

• The Factory never merges a pull request by itself. It waits for a person to press Merge PR #n, or for someone to merge it on GitHub.
• Merge readiness reads the PR's checks and reviews: blocked, pending, warn (with Merge anyway) or ready. The merge-method picker offers only the methods your repository allows. There is no admin bypass.
• Send failing checks to the build drafts the failures into the build chat so the agent can fix them.
• Take over in Factory, on a teammate's PR in the Pull Requests view, brings it onto your line.

The Factory reads PR checks; it doesn't run CI or show CI logs.