A quality gate is a check that work must pass before it can progress. Gates are how "good enough to ship" stops being a judgement call and becomes something the system enforces the same way every time.
Blocking and advisory
Every gate is one or the other, and the distinction is the whole design:
- Blocking — failure stops the task. The work does not progress until it passes or a human overrides it.
- Advisory — failure is recorded as a finding and attached to the pull request, but the task continues.
Start advisory. Watch what a gate actually flags on real work for a week or two, then promote the ones that earn it to blocking. A gate that blocks on its first day, tuned against nothing, mostly teaches people to work around it.
Blocking gate
- Coverage below 80%Fails
The task stops
It goes back as rework instead of opening a pull request you would only reject.
- Someone with authority can override it. The override records who, when and on what.
Advisory gate
- Coverage below 80%Fails
A finding is recorded
The task continues through review.
- The finding is attached to the pull request for you to weigh.
What gates can check
Gates sit on top of the verification stage and can cover:
- your own test suite passing
- coverage thresholds
- linting and static analysis
- security scanning, set in Security
- browser tests against a running preview
- evidence from external providers attached to the pull request
The most valuable gate is almost always your existing test suite, because it already encodes what your team decided matters.
Where a gate can stop work
Gates run during verification, after the developer agent has finished and before review. A blocking failure sends the task back as rework rather than producing a pull request you would only reject.
That ordering is deliberate: it is cheaper to fail inside the run than to fail on your screen.
Policies
Gates are grouped into policies, which are what you actually attach to projects. A policy is a named set of gates with their blocking/advisory settings, so you can have one standard for production services and a lighter one for internal tools.
Policies are versioned. You publish a change, and you can roll back to a previous version if a new gate turns out to be too aggressive.
Overrides
A blocking gate can be overridden by a human with the authority to do so. The override is recorded — who, when, and on what.
That record is the point. A gate nobody can override becomes something people route around; a gate anyone can override silently is not a gate. An override that leaves a trace is both usable and accountable.
What gates do not do
Gates check properties. They do not judge whether the work solves the right problem — that is what acceptance criteria in the specification are for, and what your review is for.
A change can pass every gate and still be the wrong change.