Gates
Gates sit between the phases. Each one is a check that has to pass before the next phase starts. They block by default, and every one of them can be waved through with a one-line reason that is kept in the feature's history. Seatbelt, not cage.
What a gate is for
A pipeline that lets you skip from an idea straight to a build is not a pipeline, it is a suggestion. The expensive failures in agent work are all the same shape: a lot of code gets written against a plan nobody checked. Gates are where that gets caught, and they are cheap because each one asks for something you were going to produce anyway.
The rule the whole design bends toward is flexible guidance over brittle machinery. 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 one condition that is not met, right beside 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 to go and look. A red X is not a gate doing its job.
If the check is wrong for your situation, override it. That takes one click and one sentence, and the sentence joins the feature's activity stream:
gate G1 overridden: regression verified by handSessions, overrides, generated docs, blocked runs — all of it lands in one stream per feature, 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 of them wait on you; the rest clear themselves the moment 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 two places runcastle stops and waits for a person. Everything between them runs without you. That is the whole promise: human in the loop at only the two ends.
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 own 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. The merge gate wants a human behind the wheel: an agent can tell you every ticket finished and every check passed, and still not know whether the thing feels right.
Everything else — grilling, writing the spec, cutting tickets, burning them in containers, looping fixes back through the build phase — happens between those two clicks, and does not need you awake for it.
Why not just remove the gates
Because the alternative to a gate is not freedom, it is an agent quietly building on a plan that was never checked. And because a gate is what lets the rest of the loop be unattended: you can walk away from a build precisely because something is guaranteed to stop before the branch merges itself.
The gates are guardrails on a road you are still driving. They block by default, they tell you exactly what they want, they take an override with a reason, and they keep that reason where the next person — including future you — will find it.