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

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.

Configuration and deliberate redundancy

1. 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.
2. 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.
3. 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)