Documentation

How Coroid verifies its own work

Why a pull request from Coroid arrives already checked, and what each layer of verification actually proves.

A pull request from Coroid has been through verification before you see it. This section covers what that means and how to configure it.

The layers

Verification is not one thing. Four layers run, each answering a different question.

Your test suite. The strongest signal available, because it already encodes what your team decided matters. Coroid runs it in a clean workspace on every task.

Quality gates. Policy-defined checks — coverage, linting, security scanning, browser tests. Blocking gates stop the task; advisory gates record a finding and let it continue. See Quality policies and gates.

Review. A reviewer agent reads the finished diff and produces findings. Fixable findings go back to the developer as rework; the rest are attached to the pull request.

Evidence. Preview deployments, scan results and coverage deltas attached to the pull request itself, so verification arrives with the code. See Review evidence.

What this does and does not prove

Verification establishes that the change does what it says, does not break what existed, and meets the standards you encoded.

It does not establish that the change is the right thing to build. That is what acceptance criteria in the specification are for, and what your review is for.

A change can pass every layer and still be wrong. Keeping that distinction sharp is what makes the rest of it trustworthy — the moment verification is presented as judgement, people stop reviewing.

The point of running it first

Every layer runs before the pull request exists, so failures come back as rework inside the run rather than as a pull request you would only reject.

It is cheaper to fail in the workspace than on your screen. Your review should be the first human look, not the first look.

Where to start

If you are configuring this for the first time:

  1. Make sure your test suite runs — see Build and test configuration. Nothing else matters if this is wrong.
  2. Set an organization default policy at your standard level, not your strictest.
  3. Connect the evidence providers you already use.
  4. Add gates one at a time, advisory first.

In this section