Merge gating · Warpway

Make Warpway / Review a required check and understand every conclusion it can report.

Merge gating makes Warpway's review policy a condition for merging: a pull request cannot merge until the Warpway / Review check passes. Warpway reports the result; GitHub's branch protection enforces it.

Merge gating requires the Team plan and trust level 2 (Gate) or higher for the repository.

Turn it on

1. Raise the repository to Gate

In the dashboard, open the repository and set its trust level to Gate. Admins can do this; levels above Gate need an Owner. If the base branch's .warpway.yml sets a lower trust_level, the lower level wins. See Trust levels.

2. Require the check in GitHub

GitHub lists only checks that ran in the repository recently, so open or update a pull request first and let Warpway report once.

With a ruleset (recommended):

In the repository (or organization) settings, open Rules → Rulesets and create or edit a branch ruleset.
Target your default branch, and any release branches.
Enable Require status checks to pass.
Add the check named exactly Warpway / Review, and select the Warpway app as its source so no other integration can satisfy it.
Save the ruleset with enforcement Active.

With classic branch protection:

Open Settings → Branches and add or edit the rule for your default branch.
Enable Require status checks to pass before merging.
Search for and select Warpway / Review.
Save.

What the check reports

The check is always bound to the pull request's exact head commit. A new commit starts a new check run, and the policy is evaluated again for that commit; a result for an older commit never counts for a newer one.

Situation	Status and conclusion	Title	Merge with the check required
Review queued	`queued`	Review queued	Blocked until it completes
Review running	`in_progress`	The current step, such as Reviewing the change	Blocked until it completes
Only required CI checks or runtime verification still running	`in_progress`	Waiting for CI, or Waiting for runtime verification	Blocked until they finish
Policy satisfied	`success`	Review policy satisfied	Allowed
Only human tasks remain	`action_required`	Waiting on 2 human decisions	Blocked
Open findings, incomplete lenses or failing CI	`failure`	Counts the blockers, such as 1 blocking finding, 1 lens incomplete	Blocked
Invalid configuration	`failure`	Invalid Warpway configuration: 2 errors	Blocked
A system error	`failure`	Review could not complete	Blocked
Plan usage limit reached	`action_required`	Usage limit reached	Blocked
Review cancelled	`cancelled`	Review cancelled	Blocked
Trust level 0 or 1, once the review finishes	`neutral`	The mode, then the result, such as Assist mode (not gating): 1 blocking finding	Allowed

The check's details list every blocker, the requirements already met, and non-blocking warnings.

Warning

GitHub treats a neutral conclusion as passing. At Observe and Assist, every finished review concludes neutral, so requiring the check only makes merges wait for the review to finish; it blocks nothing else until the repository is at Gate or above. Warpway never reports success while blockers exist.

What satisfies the policy

Deterministic code evaluates the policy from the stored results of the review; a model never decides that policy passed. With the default merge_gate settings, all of these must hold:

every required lens is resolved: Cleared, its human decisions answered and the lens re-evaluated, or every finding it reported closed or below the blocking severities;
no required human task is open;
no open finding at a blocking severity (critical, high or medium by default) in a lens whose blocking is block;
every CI check listed in required_ci_checks concluded success, neutral or skipped on the head commit;
no required lens is Incomplete, including because a runtime verification profile it needs failed or has not finished;
every lens that needs a human sign-off has one;
the configuration is valid, and no system error or usage limit affected the review.

Each unmet condition is a blocker of one of these types, listed in the check with an explanation:

Blocker	Key	Example
Finding	`finding`	High finding in Correctness: Retry loop can enqueue the same invoice twice
Human task	`human_task`	Open question for Security: Should role revocation end active sessions immediately? (waiting on Priya)
Incomplete lens	`incomplete_lens`	Runtime verification 'unit' timed out, so Testing / Reliability cannot be completed.
CI	`ci`	Required CI check 'unit-tests' failed.
Configuration	`configuration`	Configuration error (.warpway.yml, line 12): Unknown setting 'merge_gates'. Did you mean 'merge_gate'?
System error	`system_error`	The repository snapshot could not be downloaded.

Re-running

Use Re-run review on the Warpway / Review check in GitHub, or Rerun on the pull request page in the dashboard. A re-run reviews the same commit under the current base-branch policy.

Things to know

Warpway never merges. It has no permission to. Merging stays with your team, or with GitHub's auto-merge if you use it.
Approvals are separate. A passing Warpway check does not count as a GitHub approval. If your branch requires approving reviews, those still come from people, unless you enable auto-approval and GitHub's rules accept it.
Bypass is GitHub's. Anyone your ruleset allows to bypass required checks can still merge without a passing check.
Merge queues. Warpway reviews pull requests. It does not report on merge-queue groups, so do not require Warpway / Review in a ruleset that also gates a merge queue, or queued merges will wait for a check that never arrives.