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.
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
- 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.