Three checkpoints — one between each step. Gates are blockers.
No forward movement until every criterion is satisfied.
Each gate gates a specific transition
Foundation in place. Problem understood. Architecture documented.
See Context step arrow_forwardPlan approved. Prototype confirmed. Challenger output recorded.
See Exploration step arrow_forwardCode ships. Acceptance criteria met. Insights recorded.
See Production step arrow_forwardApproval requires evidence — not a rubber-stamp
Every gate transition records three explicit fields in the plan's frontmatter evidence: block:
A blank or boilerplate evidence block is a gate failure.
The Gatekeeper subagents (gatekeeper-g1/g2/g3) refuse to issue a pass verdict if the block is empty or generic.
hypothesis names something the team could be wrong about · result is observable, not opinion · reasoning bridges to one of: proceed, fall back, kill.
Context → Exploration
Exploration → Production
exploration-mode: A | Binsights.md existsProduction → Done
insights.md updated with implementation surprisesSpecialised gate validators — mechanically check criteria, spawn proposals for out-of-scope items
Validates uncertainty triplet, scope confirmation, evidence block.
Validates plan approval, Challenger output, Kill Criteria, insights.md.
Validates acceptance criteria, build success, documentation updates.
Items raised at a gate become PROP-NNN proposals — never disappear into prose
When the Gatekeeper or the Challenger surfaces something that should be out of scope, it must be filed as a numbered proposal. Proposals are the framework's memory — nothing valuable is lost between gates, even when we choose not to act on it now.
Each proposal has a clickable triage decision: /promote · /defer · /reject.