Merge gate

A review tells you what is wrong. The merge gate tells you whether the pull request is safe to merge, and if not, what to do about it.

For every commit of every pull request, MergeHarbor combines everything it knows into one verdict:

• Ready to merge: every check in your policy passed.
• Ready with warnings: nothing blocks the merge, but some checks need a look.
• Blocked: something in your policy must be fixed first.
• Waiting for review: the latest commit is still being reviewed.

Alongside the verdict you get a merge readiness score from 0 to 100 and a checklist, most important first, where every item says what to do: “Fix: refund amount is not validated”, “Meet criterion 2 of PAY-12”, “Add tests for Partial() in pay/refund.go”, “Get 1 more approval”.

What the gate looks at

Signal	What counts
Review	The review’s confidence score for the latest commit.
Open findings	Unresolved findings by severity. Resolved and dismissed findings no longer count.
Proof runs	A finding that a generated test reproduced in the sandbox counts as proven. Generated tests that passed raise readiness.
Requirements	Acceptance criteria of linked Jira or Linear issues that the review found unmet.
Tests	Changed-line coverage and changed functions without tests, where they are measured.
Change risk	How risky the change is: what it touches and how widely.
Approvals	People (not bots) whose latest review on the code host approves the pull request.
Rules and configuration	Findings from your team’s rules, and errors in .mergeharbor files.
Dependencies	Vulnerable or denied-license packages the pull request adds or upgrades (with the Security add-on). If the check can’t run, the gate warns by default; you can let it pass or block until it runs.

A signal that is not measured for a repository never blocks; the checklist says it was not checked.

Merge readiness is the weighted average of the measured signals, kept within the verdict’s range (blocked 0-49, warnings 50-79, ready 80-100), so the number and the verdict always agree.

Where you see it

• On the code host as its own check, MergeHarbor / merge gate, next to the review check (which it never changes). GitHub shows it as a check run with the checklist; GitLab, Bitbucket, Gitea and Azure DevOps show a commit or pull request status.
• In the console: at the top of every pull request, as a column and filter in the pull request list, and under Insights → Risk → Merge gate.

The gate is checked again whenever something changes: a new push, a finding resolved or dismissed, a review or proof run finishing, requirements or approvals changing, or your policy changing. Check again on the pull request reads everything immediately.

Stop merges that are not ready

To stop merges on the code host, make the check required:

• GitHub: add MergeHarbor / merge gate as a required status check in branch protection or a ruleset. A warning shows as neutral and still lets the pull request merge.
• GitLab: the gate posts a commit status named MergeHarbor / merge gate. On GitLab Ultimate, add an external status check whose name contains “MergeHarbor” (Settings → Merge requests → Status checks); MergeHarbor answers it as passed or failed for each commit.
• Azure DevOps: add a branch policy requiring the status mergeharbor/merge-gate.
• Bitbucket and Gitea: require the MergeHarbor / merge gate build status or commit status.

Merges started from MergeHarbor (single or bulk) always respect the gate.

Policies

Configure the gate under Settings → Checks & gates → Merge gate. Start from a preset and change any check:

Preset	In short
Relaxed	Only critical findings and findings a test proved block.
Standard (default)	Also blocks a review confidence below 3/5; warns on tests, risk and unmet criteria.
Strict	Blocks major findings, unmet criteria and team-rule violations; needs 1 approval.
Regulated	Coverage, test gaps and high risk block; needs 2 approvals and expects a proof run.

Branch policies make the gate stricter (or looser) for some target branches, for example Strict for main and Regulated for release/*. The first matching pattern wins.

Advisory mode (the default) reports the verdict without ever failing the check. Switch to Enforce in Settings → Checks & gates → Merge gate when you want a failing verdict to fail the check, so a required check stops the merge. Advisory is also a good way to try a stricter policy first.

Policies cascade like every other setting: the organization’s policy, a repository’s own policy, then .mergeharbor.yml in the repository. The organization can lock the policy so repositories cannot weaken it.

# .mergeharbor.yml
merge_gate:
  enabled: true
  mode: enforce # or advisory
  preset: standard # relaxed | standard | strict | regulated
  rules:
    required_approvals: 1
    min_coverage: 70
  branches:
    - pattern: "release/*"
      preset: regulated

Every check you can change is in the configuration reference.

Overrides

Sometimes a blocked change must ship. People with the Override a blocked merge gate permission (owners and admins by default) can override the gate for one commit with a reason, from the pull request or the merge dialog. The check then passes and says who overrode it and why, MergeHarbor comments on the pull request, and the override is in the audit log. A new push is checked again. Turn overrides off in the policy to forbid them.

Analytics

Insights → Risk → Merge gate shows, for merged pull requests: how many were ready, how many were blocked and then fixed before merging, how many were overridden, how many merged on the code host while blocked, and how many passed but were reverted later. It also shows what blocks merges most and the recent overrides with their reasons.