Ready-to-Merge Gate & Checks

What it is

Finishing a branch is a claim: "this is done, and it is safe to merge." The ready-to-merge gate makes that claim checkable. A branch earns a ready-to-merge marker only after the project's full check suite runs green on that branch's current commit, and the marker records the commit it was taken at. The gate that guards the branch then refuses to push it unless the marker names the exact commit being pushed — so a marker left over from an earlier state, or written by hand, does not count.

The point is the link between the checks and the commit. Checks that ran on Tuesday say nothing about a commit made on Wednesday, and the marker is bound to the one commit the checks actually saw. Any new commit, rebase or amend moves the branch's tip and voids the marker, forcing a fresh run.

Where to find it

The marker lives on the branch itself, in the branch's git description — it is not a screen. You meet the gate when a push is refused for a missing or stale marker, and you meet the checks when the app runs them for the branch. A session that finishes a branch marks it through the app's CLI (the branch's /ready route) or by running the ready-to-merge flow; from then on a background service does the actual merging.

How it behaves

• The marker is one line on the branch — status: ready-to-merge | set-at:<time> | head:<sha> | <summary> — where head: is the commit the checks ran against.
• The gate refuses a push of a feature branch unless the marker's head: matches the exact commit being pushed. A marker with no head:, or one naming a different commit, does not authorize the push.
• The checks are the project's own full check suite, run in the same session that earns the marker, plus a scoped test run. A failure that already exists on the base branch is pre-existing and does not block; only a failure the branch itself introduced blocks.
• A dependency change is special-cased: the marker is still required and still correct to write, but it is not sufficient — a branch that changes a dependency is deliberately never landed for you; it waits for a person to look at it.
• The gate runs on the same machinery as the app's other git guardrails: enforced by a hook that fires even in autonomous mode, and it can be on, warn-only, or off. When it is off, a feature-branch push is not checked for the marker.
• The marker authorizes the landing; it does not perform it. Once a branch is marked, a background lander merges it into the main branch locally, forward-only, without pushing.

For agents

• The producer is the ready-to-merge skill (.claude/skills/ready-to-merge/SKILL.md): commit your own files, rebase once, run the merge gate (npm run gate, whose ordered step list lives in package.json under gate:serial) plus a scoped test run, and only then write the marker. The skill never merges.
• The marker's grammar is generated from src/shared/land-core/ready-tag-grammar.ts (mirrored into the hook, kept in byte-parity by a test). The hook that reads it and enforces the push gate is resources/git-guardrails/git-guardrails.mjs.
• The gate's contract is .claude/memory/contracts/checks-gate-contract.md; the marker is written through the paved-road CLI route rather than with a raw git command, and a hand-edited marker is refused.

Related

• where-checks-run.md — where the check suite that earns the marker runs
• git-guardrails.md — the guardrail family this gate belongs to, and its on / warn-only / off levels
• agent-git-paved-road.md — the CLI route that stamps the marker
• auto-lander-dashboard.md — the lander that merges a marked branch