Auto-approval

Auto-approval lets Warpway submit an APPROVE review on a pull request when every deterministic condition holds for the exact commit it reviewed. It is disabled by default, and only an organization Owner can enable it.

Warpway never approves because a model reported high confidence. Eligibility is computed by code from stored review results, immediately before approving.

Turn it on

All of these are needed; any one of them missing keeps auto-approval off:

1. Team plan. Auto-approval is not available on Free.
2. Organization switch. An Owner allows auto-approval for the organization in organization settings. Without it no repository can auto-approve.
3. Repository enablement. An Owner enables auto-approval for the specific repository and confirms the change. It is recorded in the audit log with who enabled it and when.
4. Trust level 4. The repository's effective trust level must be Auto-approve. See Trust levels.
5. Policy. auto_approve.enabled: true in the base branch's .warpway.yml or in organization or repository settings, with the conditions you want. See auto_approve.

These settings are part of the policy version a review uses, so they apply to reviews that run after they are in place. To make an open pull request eligible, re-run its review.

The conditions Warpway checks

Right before submitting an approval, Warpway evaluates every condition below against the current state. If any one fails, it does not approve, and the dashboard shows which condition failed and why.

1. The repository is allowed. The organization switch, the Owner's repository enablement, the plan and trust level 4 are all in place, and the policy enables auto-approval. The repository is enabled in Warpway, is not archived, and passes the organization's list of repositories allowed or excluded from auto-approval, if an Owner set one.
2. The commit matches exactly. The pull request's current head commit is the commit Warpway reviewed.
3. The policy version is current. The review used the policy currently in effect for the base branch. If the effective policy changed since then, through settings or a merged .warpway.yml change, a new review is needed.
4. The review policy is satisfied, evaluated again from the stored results at that moment, exactly as for the merge gate.
5. All required lenses are resolved. This is stricter than the merge gate: every required lens must be Cleared, so a lens whose findings are merely below the blocking severities does not count, and at least one required lens must have run.
6. No required lens is Incomplete.
7. No required human task is open.
8. No blocking finding remains. No finding at a severity in merge_gate.block_on_severities is open in any lens, including lenses set to warn or none.
9. Configured CI checks pass, including auto_approve.required_ci_checks and merge_gate.required_ci_checks. Each must conclude success (neutral and skipped do not count), and no other check on the commit may be failing or still running.
10. No required tool failed, every runtime verification run on the commit succeeded, and no system error or usage limit affected the review.
11. The change avoids excluded paths and risk categories in excluded_paths and excluded_categories. Path rules need the complete list of changed files; if Warpway could not get all of it, they fail.
12. Every required human sign-off is present.
13. Optional size and author rules pass, if you set them:
    • max_changed_lines: at most this many changed lines, additions plus deletions;
    • max_files: at most this many changed files;
    • allowed_authors: only pull requests opened by these GitHub users;
    • dependabot_only: only pull requests opened by Dependabot (dependabot[bot]);
    • docs_tests_only: only documentation and test files, decided by file path, never by the change analysis. Documentation means Markdown, MDX, reStructuredText and AsciiDoc files, and images in the top-level docs/ or doc/ folder; tests mean files such as *.test.*, *.spec.*, *_test.* and test_*.py, snapshots, and anything under test/, tests/, spec/, testdata/ or __tests__/;
    • require_preview_deployment with preview_deployment_check: the named preview deployment check concluded success on the commit.

Examples

Documentation and tests, kept small and away from sensitive code:

version: 1
auto_approve:
  enabled: true
  docs_tests_only: true
  max_changed_lines: 300
  excluded_paths:
    - auth/**
    - migrations/**
  required_ci_checks:
    - unit-tests

Dependabot updates that pass CI and a preview deployment:

version: 1
auto_approve:
  enabled: true
  dependabot_only: true
  max_files: 5
  excluded_categories:
    - auth
    - migration
  require_preview_deployment: true
  preview_deployment_check: Vercel Preview
  required_ci_checks:
    - build
    - unit-tests

What an approval means

• The approval names the exact commit it was given for. A new commit makes the pull request ineligible until it is reviewed again and every condition passes again.
• Turn on GitHub's Dismiss stale pull request approvals when new commits are pushed so an approval never outlives its commit.
• Every automatic approval creates an audit event recording the commit, the policy version and the result of each condition.
• Warpway approves; it never merges. Whether its approval counts toward your branch's required approvals is decided by your GitHub rules.

Turning it off

An Owner can disable auto-approval for a repository or for the whole organization at any time, and an Admin can lower the repository's trust level below Auto-approve. Either takes effect for the next evaluation. Setting auto_approve.enabled: false in .warpway.yml works too, once that change is merged into the base branch.