Application map / References / Push gate

The Push Gate (no-mistakes)

The operating model for the nine-step pre-share validation pipeline that gates every substantive push to the product monorepo.

What it is

A locally-installed git-push gate: pushing a branch to it intercepts the push and runs a nine-step serial pipeline — intent → rebase → review → test → document → lint → push → PR → CI babysit — each step executed by a fresh AI agent, before the change reaches the shared remote as a PR. It is the sole correctness gate for the two-app monorepo and it catches real defects across parallel agent-driven branches.

Behavioral properties that shape everything else

• A clean end-to-end run is inherently bounded at roughly half an hour to an hour of step work — multi-hour "hangs" are stalls, not normal runs.
• Gate model: with review auto-fix disabled, review findings park the run at an approval gate; a run never advances past a gate on its own. axi run and axi respond block by design until the next gate, checks-passed, or a terminal outcome — there is no webhook or notification mechanism.
• The CI step babysits the open PR after checks pass, re-arming an idle timeout whenever the base branch advances; the lingering "running" status after checks-passed is cosmetic.
• The CI monitor treats any failing check as fixable (log-collect → fix agent in a worktree → force-push-with-lease, bounded attempts); there is no per-check ignore list, so a chronically red check burns every attempt.
• There is no built-in agent watchdog: a hung agent stays hung until something kills it. rerun reuses nothing; re-pushing a branch supersedes its active run; axi abort --run <id> reaps an orphaned monitor from anywhere. Gates are answered from a checkout on the run's branch.

The operating model

1. CI executes exactly once. The mirrored second CI system's workflows are deleted; GitHub Actions is the single orchestrator. Managed runners participate as runners (a label swap that keeps check names), never as a second CI system.
2. Cadence: one run per PR-ready branch push. Not per commit (runs cost tens of minutes and a re-push supersedes anyway) and not per merge (nothing new exists at merge time). "Every merge is validated" is enforced by branch protection on main — required checks, PRs required, no direct pushes — a mature GitHub feature, not glue. Both workflows drop their paths: filters on PR triggers so every required check reports on every PR (a required check that never reports blocks the merge forever).
3. Monitoring is two layers. The driving protocol for the live session: start with a rich --intent; poll status non-blocking; on a parked gate, respond — fixing findings you can judge and escalating ask-user findings to a human (the permission layer blocks agents from self-answering them); treat outcome: checks-passed as done — report the PR link and hand the merge to the human, never wait for the merge. The structural backstop: a launchd babysitter, session-independent, that reaps hung CI-fix agents (safe — the kill burns one retry attempt) and surfaces parked runs and hung non-CI steps for a human/agent decision. This babysitter is deliberately the only custom glue in the design.
4. Configuration: bounded idle CI timeout; review auto-fix disabled (findings are judgment calls); fully unattended --yes runs only on explicit per-conversation consent; concurrent runs on different branches allowed.
5. Deliberately kept: local test/lint duplicating CI (catching before sharing is the point), the document step, and a redundant independent build signal as an honest cross-check.
6. The test step is provisioned, not improvising: deterministic step commands from committed pipeline config, real credentials at runtime through the machine-authed secrets manager, the proven test framework as both test framework and browser tool, and standing guidance inlined verbatim into every pipeline agent (injection is the only reliable channel — "see the other file" pointers are weak links).

Stall taxonomy (how to read a "hung" run)