# Review, pull requests and merge

How the Factory reviews a change against the original ask, when it merges by itself, and how pull requests fit in.

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](models#a-model-for-each-job).

> [!LIMIT]
> A review takes at most 10 minutes. A diff over 300,000 characters is held for a person rather than cut short.

## 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](review)). **Verify (L‹n›)** runs the assurance checks for the item's level (see [Assurance levels](assurance)).
- **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.

> [!WARNING] Configure checks before trusting Express
> If the project has no assurance checks configured (lint, type-check, tests), the policy review's Verify step has nothing to run and passes. Set them up under **Assurance** before you let Express merge 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](factory-lanes#gates-your-rules-at-every-step));
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.

> [!NOTE] A local merge doesn't push
> Push main yourself (or let an automation do it) when you are ready. Staging and Production only move once the change reaches the remote.

## 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.