A pull request from Coroid undergoes verification prior to being viewed. This section explains what this entails and how to configure it.
The layers
Verification involves more than one process. Four distinct layers operate, each addressing a specific question.
Your test suite. This provides the most reliable signal, as it already reflects what your team deems important. Coroid runs it in a clean workspace for every task.
Quality gates. These are policy-defined checks — covering code coverage, linting, security scanning, and browser tests. Blocking gates halt a task; advisory gates record issues while allowing it to proceed. See Quality policies and gates.
Review. A reviewer agent examines the completed diff and generates findings. Fixable issues are sent back to the developer for rework; the rest are attached to the pull request.
Evidence. Preview deployments, scan results, and coverage changes are attached to the pull request itself, ensuring verification details accompany the code. See Review evidence.
What this verifies and what it does not.
Verification confirms that the change behaves as intended, does not disrupt existing functionality, and meets the established standards.
It does not confirm that the change is the appropriate solution to build. That is the purpose of acceptance criteria in the specification and what your Review process is for.
A change may pass every layer yet still be unsuitable. Maintaining this distinction is crucial for preserving trust; if verification is mistaken for final judgement, people will stop conducting Reviews.
The benefit of running checks early
Each layer operates before the pull request is created, so any failures result in rework during the process rather than producing a rejected pull request.
It is less costly to encounter errors in the workspace than on your screen. Your Review should be the initial human assessment, not the first glance. human assessment, not the first glance.
Where to begin
If you are setting this up for the first time:
- Ensure your test suite runs correctly — see Build and test configuration. Nothing else matters if this is not set up properly.
- Establish an organisation-wide default policy at your standard level, rather than using the strictest rules.
- Integrate the evidence providers you already use.
- Add gates one by one, starting with advisory ones.