# Auto‑merge

On **Max** and **Enterprise**, AM can merge a pull request for you — hands‑off,
with **no human review**. Auto‑merge fires as soon as the change clears AM's
automated gates. Gating it on **earned trust** is an *optional* extra, not a
requirement (see *Gate it on earned trust* below).

## What must be true to auto‑merge

A PR auto‑merges only when **all** of these hold:

1. **Auto‑merge is enabled** for the repo and the plan allows it (Max+).
2. **The [Verification Gate](/docs/verification-gate) passed (green)** —
   mandatory. A red gate produces a *draft* PR that is never auto‑merged. (A repo
   with no gate configured also can't reach the *auto‑merge‑ready* trust tier.)
3. **AM's automated review gates didn't flag the change** — the
   objective‑adherence (intent) and architecture‑conformance critics. A *concern*
   or *fail* on either holds the merge for you.
4. **(Optional) Earned trust** — only if you enabled *"Only when trust is
   earned"*: the repo must have reached the *auto‑merge‑ready* tier.

There is **no human review and no manual approval step** on auto‑merge — that's
what "hands‑off" means. If you want a human in the loop, that's the **Pro**
posture: AM reviews + approves, you press merge. If any gate above isn't
satisfied, the PR is left as a reviewable (or draft) PR instead.

## Enabling it

In **Repo settings**, toggle **Auto‑merge**. On plans below Max the toggle is
inert — review/merge stays with you.

## Gate it on earned trust (opt‑in)

In **Repo settings → Auto‑merge**, enable **"Only when trust is earned"** and AM
auto‑merges only once this repo's [trust score](/docs/trust-and-plans) reaches
*auto‑merge ready* — a demonstrated track record over a real verify gate. Below
that, the run still opens a **reviewable PR** (you merge) instead of merging
automatically.

Because trust is recomputed every run, this **ramps and demotes on its own**:
auto‑merge resumes as the repo proves out and pauses if reliability regresses — no
manual flipping. It's the literal form of *"autonomy earned by demonstrated
reliability"*, and the safest way to adopt auto‑merge.

## Does the next run see the merge?

**Yes.** Once a PR auto‑merges, its commits are on your default branch
(`main`/`master`), and the **next scheduled run starts from a fresh clone of that
branch** — so it builds on the merged work, not a stale copy. The panel pins no
checkout and no commit SHA: each run sends only the repo URL, and the worker
re‑clones the current default‑branch HEAD every time. There's no "stale workdir"
to reset. (The one exception is [recovering an open PR](/docs/recovering-a-pr),
where a run is told to continue an *unmerged* PR branch instead.)

## Recommended adoption

Start with auto‑merge **off** even on Max, watch a handful of runs land
merge‑ready PRs you approve, then enable auto‑merge **with trust‑gating on** so it
goes hands‑off only once the repo has earned it. Pair it with
[explore mode](/docs/explore-mode) for a fully hands‑off improvement loop.

## Related

- [Trust ladder & plans](/docs/trust-and-plans)
- [The Verification Gate](/docs/verification-gate)