Gates
A gate sits between each pair of phases: a check that has to pass before the next phase starts. Gates block by default, and any of them can be waved through with a one-line reason that stays in the feature's history. Seatbelt, not cage.
What a gate is for
A pipeline you can skip from idea straight to build is not a pipeline, it is a suggestion. The expensive failures in agent work all have the same shape: a lot of code written against a plan nobody checked. Gates catch that, and they are cheap, because each one asks for something you were going to produce anyway.
A gate that cannot be overridden eventually blocks something legitimate, and then the tool is the problem. So no gate is final. But skipping one is a decision, and decisions get written down.
A check does not just refuse
A blocked gate names the condition that is not met, right next to the control that
clears it. The gate into review does not say "not ready". It says
3 tickets not yet terminal (2 pending, 1 burning), so you know whether to
wait or go and look.
If the check is wrong for your situation, override it. One click and one sentence, and the sentence joins the feature's activity stream:
gate G1 overridden: regression verified by handSessions, overrides, generated docs, and blocked runs all land in that one stream, in order. Work that ran while you were somewhere else is still readable afterwards, which is what makes an override an audit trail rather than a hole.
The gates, in order
Each gate guards the entry to a phase. Two wait on you. The rest clear themselves as soon as the work they describe exists.
| Gate | Guards entry to | Clears when |
|---|---|---|
| G1 | spec | Decisions are captured, before anyone writes a spec. |
| G2 | tickets | The spec is written, before it gets broken into tickets. |
| G3 | build | A human approves the tickets. The Burn click. |
| G4 | review | Every ticket has reached a terminal state. |
| G5 | shipped | A human merges the feature branch. The Merge click. |
The two decisions
G3 and G5 are the only places runcastle stops and waits for a person. Everything between them runs without you.
Approve the plan
The spec and the ticket list come out of one unbroken conversation, so nothing is rebuilt from a summary of a summary. You skim it and say go. This is the cheap moment to disagree: a ticket list takes a minute to read, and it is the last point before agents start writing code against it.
Approve the merge
runcastle sets your work aside, checks out the finished branch, and starts it on its own port so you can click through the feature before it lands. Then it puts your work back. An agent can tell you every ticket finished and every check passed, and still not know whether the thing feels right.
Everything else happens between those two clicks and does not need you awake for it: grilling, writing the spec, cutting tickets, burning them in containers, and looping fixes back through build.
Why not just remove them
The alternative to a gate is not freedom, it is an agent quietly building on a plan nobody checked. Gates are also what make the rest of the loop safe to leave alone: you can walk away from a build because something is guaranteed to stop before the branch merges itself.