Quality gates

Every AI session ends with a change: a diff against your project's repository. Before that change can become a pull request, AI CodeOps checks it. The checks are the same whether you open the pull request from the console or ask from your CI.

What the gate checks

A change is release-ready when all of these hold:

• Tests pass. After writing the change, the session runs your project's test command in its sandbox and records the result. Failing tests block the change.
• The AI findings review completed. A reviewer step reads the diff and records findings (security, quality, performance, reliability, test coverage and other categories). If that review could not finish, for example because the model failed, the findings are unknown and the change is held: "The automated review of this change didn't complete, so its findings are unknown. Re-run the session".
• No blocking findings are open. Findings of severity high or critical block until they are triaged.
• Tests count for the version they ran on. If someone edits the change after its tests ran, the old result neither passes nor blocks it: the gate says this version is untested and the approval opens again, so a person decides before it ships. Re-run the session to test the new version.

Approvals are a separate check on the same path. See Approvals and policies.

Where you see it

Open a session's run page. The Quality gates panel shows Release-ready or Gate checks pending, the test totals, each test result, and the reasons the change is not ready yet. The Findings panel lists each finding with its severity, file and line.

Workspace-wide test results and open findings are under Build & Test → Quality.

Triage findings

Each finding has a status. Change it from the dropdown on the run's Findings list:

You can also choose Fix on a finding to launch an AI run that fixes it. Changing a finding's status needs a role with triage permission. Owners, admins, developers, members and security admins have it; viewers don't.

What the gate blocks

When you choose to open a pull request, AI CodeOps checks in this order:

1. The workspace policy. A deny rule stops the pull request; an ask rule needs an approved review.
2. The approval. A rejected or pending approval stops it.
3. The quality gate. A change that isn't release-ready gets the first reasons, for example "This change isn't release-ready: HIGH security: …".

The same quality gate runs again before the console merges a pull request it opened. The pull request opens on a branch named codeops/run-<id>.

The release gate for CI

Review & Gate → Release gate evaluates a pull request URL or commit SHA across every session that touched it, and shows Allowed or Denied with reasons. Your CI can ask the same question through POST /api/release/check with a workspace API key. The CI check adds options the per-run gate doesn't use: required workflows, a minimum coverage percentage, disallowed licenses (checked against the project's SBOM), and a required prior deployment such as staging. The fields and response are on the API page.

If the gate check itself can't run, for example during a brief outage, the pull request is not opened: "The release check couldn't run just now." Try again in a moment.

Next steps

• Approvals and policies
• Security and SBOM
• Evidence packs