A policy is a named, versioned set of quality gates. Policies are what you attach to projects; gates are what actually run.
For the concepts — blocking versus advisory, where gates sit in a run — read Quality gates first. This page covers managing them.
Manage them in Quality Control. Its rail lists the organization default and every project. Choose one to see how new work is screened, what it checks on every change, its QA level and where checks run, each with a switch that applies as soon as you flip it. The confirmation lets you undo the change, and a row's settings change how that check works.
- Organization default3 projects follow it2 of 5
- StorefrontOwn setup4 of 5
- Docs siteFollows default2 of 5
- Billing APIFollows default2 of 5
- Mobile appFollows default2 of 5
- Anti-slopSends a change back when it weakens tests, swallows errors, ships placeholders or adds structural debt.
- Unit testsFinds and runs the repository's unit tests on every change.
- Browser tests2 of 3differs from defaultRuns your browser journeys against the change.
- Translationsdiffers from defaultChecks that changed strings are translated and that their placeholders and plural forms match.
- Repository checksRuns your own commands, such as formatting, file size, migrations, integration tests and security scans.
- Thorough QAThoroughQA collects live evidence and screenshots against the Specification. When it is off, work gets Standard QA.
Quality Control: the policies in force and the latest gate run. Illustrative data.
Creating a policy
A policy is a set of checks plus, for each, whether failure blocks or advises.
Most organizations need two or three policies, not one per project:
- a strict policy for production services
- a standard policy for everything normal
- occasionally a light policy for internal tools and prototypes
More than that and nobody can remember which project has which.
The organization default and a project's own setup
A project follows the organization default until you change one of its switches. That change gives the project its own setup, copied from the default, and later changes to the default no longer reach it. A row can copy one check back from the default, and the project's menu can reset the whole project to the organization default. The full policy behind the switches, with expectations, dependencies between checks, repair budgets and versions, opens from the same menu as the advanced editor. For a project that follows the default, the editor starts from a copy of it, and nothing changes for the project until you publish that copy.
Set the default to your standard checks, the ones most projects should run, not your strictest — the strictest should be opted into deliberately, project by project.
Pull requests
Pull requests that people and other tools open reach Coroid through the Coroid GitHub App. The Pull requests group in Quality Control decides what happens to them, for the organization default and for each project:
- Coroid Quality Control runs the checks above on every pull request and reports the result as the Coroid Quality Control check on GitHub.
- Coroid Review has Coroid's Reviewer read each pull request and comment on the lines it questions. It reads the pull requests that Coroid Quality Control checks.
Coroid Review's settings:
- What it posts. Advisory, the default, comments and never fails its check, with one exception: a confirmed critical or high security issue fails it when Security enforces security review (see Code scanning and security review). Blocking requests changes when it finds a problem, and its check fails. Make Coroid Review a required check in GitHub if a blocking review should stop the merge.
- Which pull requests. By default it waits until a draft is marked ready, and skips pull requests Coroid opened, because Coroid's Reviewer already reviewed them inside the task. It can skip pull requests from bots too.
- When it reviews. It waits for a quiet period after the last push, five minutes by default. A newer push replaces a review that has not started. Re-run on GitHub starts one at once.
- Review depth. How much the Reviewer may read and write in one review.
It follows Coroid's review rules and the rules in your repository's
review-rules folder. A project that follows the organization default gets the
default's settings, as with every other control.
When something breaks
Three switches under the organization default turn failures into follow-up work for every project. Each switch runs one automation, listed in Factory under Automations; the agent reads the code and opens a task, and the task goes through the same specification, build, verification and review as any other.
| Switch | When | What the agent does |
|---|---|---|
| When a task fails, open a fix task | A task fails | Finds out why and, when the cause is in the code, opens one task that fixes it |
| When a deployment fails, investigate | A deployment fails | Reads what changed in that version and opens one task that says what went wrong and what to change |
| When a release is rolled back, plan the fix | A release is rolled back | Opens one task that records what was rolled back, why, and what must change before it ships again |
Switching one off pauses its automation; switching it on again resumes it. Every change offers Undo. The automation's page in Factory says it is managed by Quality Control. Pausing it there is the same as switching it off; changing its instructions makes it your own after you confirm, and the switch no longer turns it on or off.
These were templates in New Work. An automation you created from one before keeps running. If you never changed it, switching the matching switch on takes it over instead of starting a second one. If you did change it, it stays yours: the switch's row names it, and you can adopt it so the switch manages it.
Rolling out safely
The failure mode with gates is not that they are too weak. It is that a well-intentioned blocking gate stalls every task in the organization at once.
A safe sequence:
- Add the gate as advisory.
- Let it run on real work for a week or two. Read what it flags.
- Tune it against what you learned.
- Promote to blocking on one project.
- Roll out more widely once it behaves.
- 1Add the gateAdvisory
- 2Watch it for a week or twoAdvisory
- 3Tune it to what it flaggedAdvisory
- 4Block on one projectBlockingOne project
- 5Roll out more widelyBlockingMore projects
Versioning and rollback
Policies are versioned. Every switch publishes a new version, and its confirmation can undo it by returning to the one before; older versions can be restored from the advanced editor's version history.
Rollback is the reason you can afford to be decisive about publishing. If a new gate turns out to be mistuned, reverting is a single action rather than an archaeology exercise.
Overrides
A blocking gate can be overridden by someone with authority. The override is recorded — who, when, and against what.
Watch your override rate. A gate overridden most times it fires is not enforcing anything; it is generating friction and a paper trail. Either fix the gate or drop it.