CI gates

Detection and replay tell you about failures. Release gates stop them from shipping. A gate runs your candidate agent version against Lumni’s regression library in CI and blocks the deploy if a known failure comes back.

What a gate checks

• Known failures. Does the candidate reproduce any failure in the regression library? If a false_success you already fixed comes back, the gate catches it.
• Regression tests. The replay cases promoted from past incidents run against the new version.
• Policy checks. Does the candidate violate a guardrail you’ve defined?

Fail-open by default

Lumni can never break your deploy

Gates fail open. If Lumni is unreachable, times out, or returns an Uncertain verdict, the gate does not block — it lets the deploy proceed and records why. Blocking is a decision you opt into per gate; the default can never turn Lumni into a single point of failure for your releases.

Wiring it in

Add a step to your pipeline that submits the candidate version and reads back a verdict. Conceptually:

.github/workflows/deploy.yml (sketch)

- name: Lumni release gate
  run: |
    lumni gate \
      --version "$GITHUB_SHA" \
      --suite regression \
      --fail-open        # default; omit --block to stay advisory

The gate exits non-zero only when it’s configured to block and a known failure reproduces. Otherwise it annotates the build and moves on.

The payoff

A gate turns every incident into a permanent guarantee: once a failure is in the regression library, the same bug can’t ship twice. That’s the loop that closes — detect → diagnose → replay → gate.