CI chain & review gate

Overview

The CI gate is where Inspector's checks stop being advisory and start being enforced. It sits in front of a deploy: if Protect's rule checks — or any Playwright smoke checks layered on top — come back failing, the gate blocks the release instead of relying on someone remembering to look at a report before clicking deploy.

How it works

1. Checks run as part of your release flow — Protect's rule checks, and any Playwright smoke checks you've wired in.
2. Results roll up into a single gate decision — pass or blocked.
3. A blocked release stays blocked until the failing checks are addressed or explicitly overridden by someone with the authority to do so.

Steps

1. •

   Wire Protect and smoke checks into your release flow

   Connect the checks you want enforced — rule checks at minimum, browser smoke checks where you have them.

2. •

   Let a release attempt run the gate

   Every release attempt runs the wired checks automatically, not on request.

3. •

   Read the gate result

   A clear pass or blocked result, tied to which specific checks failed.

4. •

   Fix and re-run, or override deliberately

   Address the failure and re-run, or make an explicit, logged decision to override.

Capabilities

• Pre-ship enforcement — turns Protect's rule checks into a hard gate, not just a report.
• Aggregated gate decision — one clear pass/blocked signal from multiple underlying checks.
• Deliberate overrides — a blocked release can be overridden, but it's an explicit, visible decision, not a silent skip.

Limits & honest scope

The CI gate enforces what you've wired into it — it doesn't invent checks on its own.

• It's only as strong as the checks feeding it. A gate with nothing wired in blocks nothing.
• It blocks releases; it does not fix the underlying issue or roll back a release already out the door.
• Override paths exist deliberately — the gate is a checkpoint, not a lock with no key.

Related

• Inspector overview
• Protect (rule checks)
• Ship overview