Quality gate

A local AI quality gate that validates a branch through a review, test, docs, lint, push, PR and CI pipeline in a disposable worktree before it reaches your push target.

The quality gate puts an AI-driven validation pipeline in front of your real remote. Instead of pushing straight to origin, you push through the gate: it spins up a disposable worktree, runs the pipeline, and only forwards the branch to your push target - and opens a clean PR - once every check passes. Your own checkout is never touched.

It is on by default, and still experimental: its commands, findings and output may change between releases. It costs nothing until a code task is committed, and it switches off per project or globally.

How it works

        your branch
            │  git push gate   (or /gate, or enigma gate)
            ▼
   ┌──────────────────────────────────────────────────────────┐
   │  disposable worktree: your checkout stays untouched        │
   │  intent → rebase → review → test → docs → lint             │
   │        → push → PR → CI                                     │
   └──────────────────────────────────────────────────────────┘
            │  every check green
            ▼
        clean PR, opened for you

Each step either passes on its own or stops with a finding for you to act on:

  • auto-fix - mechanical, low-risk. Authorize it and the pipeline applies the fix and re-reviews.
  • no-op - informational; nothing to do.
  • ask-user - the review could not settle it mechanically. The pipeline stops, and it reaches you only if fixing it would go against what you asked for; otherwise the agent authorizes the fix.

Safe, mechanical fixes are applied automatically; anything that touches your intent is escalated for you to approve, fix, or skip. Nothing reaches the configured push target until every check is green.

How much it asks you

Who settles a finding is yours to set, in the dashboard’s Quality gate view or as fix_policy in ~/.enigma/gate/config.yaml:

  • Fix, and ask about the rest (assisted, the default) - the agent settles what the review found and comes back only when the answer is not already yes: the finding contradicts what you asked for, undoes a deliberate decision, changes agreed behavior, or takes a very large change. It is never asked whether to repair a defect.
  • Fix without asking (auto) - the agent settles everything and never checks back.
  • Always ask (ask) - nothing is fixed until you say so; every finding reaches you first.

The setting governs the run, not just the wording your agent uses: the drive loop stops at exactly the gates the policy says are yours. Driving a single run with --yes still overrides it.

Each fix lands on your branch as enigma(<step>): <summary>, with the same leading type emoji your agent’s own commits carry; PR titles and bodies stay emoji-free. See Configuration for the commit-emoji toggle that turns those emojis off.

Set it up

The gate is already on: installing enigma deploys the /gate command to your agents, and enigma update delivers it to a deployment you installed earlier. What is left is one command per repo:

enigma gate init

enigma gate init sets up the gate in the current repo: a disposable bare repo that fronts your real remote, a post-receive hook, and a git remote named gate. Your agent runs it on its own the first time it needs it. enigma config gate prints whether the gate is on where you are.

$ enigma gate init
$ enigma config gate

The repo needs an origin remote (the gate routes PRs to it), and your work must be committed - the gate validates committed history.

Turn it off

Per project, everywhere, or from inside your agent:

enigma config gate off

-l writes gate: false into this repo’s .enigma.json and leaves your other projects alone; -g switches it off everywhere. /gate off does the project-scoped one from your agent, and /gate status reads the current value. Restart the agent afterwards - memory is read at startup.

$ enigma config gate off -l
$ enigma config gate off -g
$ /gate off

Which branch

Any branch, including the default one. On a feature branch the pipeline ends by opening a PR and watching its checks. On the default branch there is nothing to open a PR against, so the PR and CI steps are skipped and the validated push lands directly on that branch - review, tests, docs and lint still run in full.

If a branch must only ever be reached through review, list it:

enigma config gate-protected-branches add main

Branch names are matched exactly. axi run then refuses that branch and says how to lift the protection. The list is empty by default, lives in .enigma.json, and a project’s own list overrides the global one.

$ enigma config gate-protected-branches add main
$ enigma config gate-protected-branches
$ enigma config gate-protected-branches remove main

Automatic driving

You do not have to ask your agent to run the gate or initialize repos by hand. The deployed agent memory carries an always-on instruction: once the agent has committed a code task, it drives the gate itself on whatever branch that work is on - running enigma gate init once if the repo is not set up yet - then handles findings the way fix_policy says (by default: applies every fix it can, and comes back only for an ask-user finding whose repair would go against what you asked for), and leaves the PR ready for you to review and merge (it never merges on its own).

This is per project. To opt a single repo out while the gate stays on everywhere else, set gate: false in that repo’s .enigma.json (or run /gate off there); the agent skips automatic driving there.

An instruction on its own gets skipped, so verified completion backs it at turn end: while the gate is on here, the stop is denied when the agent’s final message reports the gate as not run or offers to run it, and when the turn ends leaving committed work no run has ever seen. The exits are the ones above and each has to be named rather than asked about - you told it to skip, gate: false, a protected branch, nothing committed to validate, an ask-user finding to escalate, or the gate not being able to stand up here at all (no origin remote, or init or the daemon failing).

Three ways to trigger it

Every change runs through the same pipeline. Pick the entry point that fits how you are working:

  • git push gate <branch> - the explicit Git path. Push your committed branch to the gate remote instead of origin.
  • enigma gate - the run overview. Inspect the active run, resume it, or start one.
  • /gate - the agent skill. Tell your coding agent to do a task and gate it with /gate <task>, or use bare /gate to validate work that is already committed. It drives the pipeline, applies the safe fixes, and stops to ask you about anything that needs a human call.

Acting on findings

When the pipeline parks at a gate, read its findings and respond:

enigma gate axi status                       # where the run is parked
enigma gate axi respond --action approve     # accept the gate
enigma gate axi respond --action fix --findings <ids>
enigma gate axi respond --action skip

While a run is active the pipeline owns the findings and the fixes - decide and respond rather than editing the code yourself. A run ends with one outcome:

  • checks-passed - validated and CI green; the PR is open for you to review and merge.
  • passed - cleared the gate and the PR was merged or closed.
  • failed / cancelled - read the output, fix what it points at, commit on the same branch, and run it again.

Commands

enigma gate <init|status|runs|rerun|doctor|eject|daemon|axi>

init sets up (or repairs) the gate; status/runs inspect runs; rerun re-runs the current branch; doctor diagnoses a misbehaving gate; eject removes the gate from the repo; axi is the machine-readable interface the /gate skill drives. See Configuration for the gate toggle.

$ enigma gate init
$ enigma gate status
$ enigma gate doctor
$ enigma gate eject

The gate is experimental: its commands, findings and output may change between releases. Read the help lines in its output for the exact next step.