AI code quality gates that fail closed

In AI CodeOps, quality gates are the checks every AI change has to pass before it becomes a pull request: the AI review of the diff must have run and found nothing serious open, the project's tests must not fail, and a person must approve. The same gate runs again before the console merges the pull request, and your CI can ask it for a verdict through an API.

AI agents write code quickly. That speed is only useful if every change still meets the bar you hold human changes to. This page explains what each check looks at, what it blocks, and where it stops.

Which agents run

The gate does not trust an agent's opinion of its own work. It reads records that agents and the platform produced:

• Findings from the review of the real diff, attributed to the Security Auditor when the workflow has one, else the Reviewer.
• Test runs from your own test suite. The Tester plans tests, but the result that counts comes from running them.
• Workflow runs of the session itself, such as a completed Release Readiness run, when your CI requires one.

The Quality-Gated Change workflow (Builder, Tester, Reviewer) is the shortest path through the gate. Any other workflow that changes code goes through the same checks.

Interactive demo, sample data.

Quality gates involved

When a session finishes, AI CodeOps works out whether its change is ready to ship. The change is held back if any of these fail:

• The AI review ran. After the code is written, a review step reads the diff and records structured findings. If it could not be completed, the change is held until it is reviewed. A missing review never counts as a pass.
• No blocking findings. A finding of high or critical severity that is still open, acknowledged or in progress blocks the change. See AI code review.
• Tests do not fail. The project's own suite runs against the change in an offline sandbox. A failed test or a non-zero exit code blocks it. See testing.
• The tested version is current. If someone edits the change after the tests ran, the old result no longer counts.
• A person approves. Every session that produces a change opens an approval request. One approval is enough. The person who started the session cannot cast it while another approver exists in the workspace; a one-person workspace can approve its own change. One rejection ends the request. Editing the code after approval resets it to pending. An undecided request expires after seven days and can be requested again.
• Workspace policy. Before the pull request opens, the repository and every changed file are checked against your policies. A deny stops it; an ask needs an approval.

The gate fails closed. If a check errors, the change is refused, not let through.

What it blocks

The gate applies to actions taken through AI CodeOps:

1. Opening a pull request from a session.
2. Merging, from the console, a pull request a session opened.
3. Automatic deploys after an incident's fix is merged.

A pull request merged directly on GitHub, GitLab or another host is outside AI CodeOps. To gate those merges too, call the gate from your CI.

Use the gate from CI

The Release gate page (under Review & Gate) checks a pull request URL or commit SHA on demand. The same check is an API for your pipeline, authenticated with a workspace API key:

curl -s -X POST "https://<your-console>/api/release/check" \
  -H "Authorization: Bearer $WORKSPACE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"pullRequestURL":"https://github.com/acme/checkout/pull/42","blockingSeverity":"medium","requireDeployedTo":"staging"}'

A denied answer, trimmed to the main fields:

{
  "allowed": false,
  "evidenceComplete": true,
  "summary": "HIGH security: Coupon code is passed to the pricing query without validation",
  "reasons": [
    "HIGH security: Coupon code is passed to the pricing query without validation",
    "Not yet deployed to \"staging\" — promote there before releasing"
  ],
  "blockingFindings": [
    {
      "id": "fnd_01JA8ZC1P3R5T7V9X1Z3B5D7F9",
      "severity": "high",
      "category": "security",
      "title": "Coupon code is passed to the pricing query without validation",
      "workflowRunID": "wfr_01JA8YQ4M2C7H5K9P3S6V8X1ZD",
      "agentID": "security-auditor",
      "filePath": "src/api/checkout.ts"
    }
  ],
  "testFailures": [],
  "coverageShortfall": null,
  "priorEnvironmentMissing": { "required": "staging" },
  "requiredGatesPassed": true,
  "missingRequiredWorkflows": []
}

The API returns HTTP 200 for both outcomes, so read the allowed field rather than the status code. Each call can set stricter checks:

• blockingSeverity, to block on medium findings as well as high and critical.
• minCoveragePct, a coverage floor for the latest run that reported coverage.
• requiredWorkflows, workflows that must have completed on this change.
• requireDeployedTo, an environment the change must already be deployed to.
• blockOnInFlight, to deny while a session for the change is still running.

The gate looks at runs from the last 14 days by default. A change it finds no session for is denied, not passed: the gate has nothing to judge.

How it is configured

The built-in checks are on for every workspace and the same for every session. The Policies page (under Secure) adds your own rules on top. Each rule allows, asks for approval on, or denies an action such as starting a workflow, changing files under a path or opening a pull request. A trust setting decides what happens when no rule matches. Every deny or ask decision is logged.

Who can approve and triage is set by roles, described with the audit log on the governance page. The approval, every vote and the gate result go into the change's signed evidence pack.