Acceptance-Gated Phase Lifecycle
petrova intermediate 6 min read
ELI5
A phase is a fenced box of work. You only open the next box once the auditor has stamped the current one and the reviewer has run a friction round on top. There is no rewinding — friction surfaced after a box closes goes into the next box, never back into the closed one.
Technical Deep Dive
State diagram
stateDiagram-v2 [*] --> not_started not_started --> next : phase N-1 closed next --> open : 01-phase-open prompt + entry criteria met open --> open : implementer ↔ auditor loops on milestones open --> blocked : auditor verdict = block blocked --> open : remediation lands open --> closing : all acceptance gates pass closing --> verification : 02-phase-close invokes 03-verification-round (MR-10) verification --> closed : friction classified (closed / in-budget / deferred) closed --> [*] closed --> frozen : explicit thaw decision doc required to revisit note right of closed MR-7 forbids editing closed decision docs. Friction → next phase only (MR-2). end noteStatus semantics
MILESTONES.md carries an Active phase pointer at the top and per-phase status keys:
- not-started — declared in MILESTONES but not yet eligible.
- next — predecessor closed; this phase is the one
01-phase-open.mdwill operate on. - open — phase-open decision doc exists; implementer/auditor cycles in flight.
- blocked — internal sub-status; an auditor
blockverdict on a milestone routes back to the implementer (audit.failevent in AGENTS.xml). The phase staysopen; only individual milestones reportblock. - closed — phase-close decision doc landed; cannot be reopened (MR-7).
- frozen — a closed phase explicitly archived; revisiting requires a “thaw” decision doc.
Entry criteria check
01-phase-open.md Step 2 demands a one-line verdict per criterion: met, not-met, or n/a with a citation. If any criterion is not-met, the planner subagent stops — opening anyway would defeat the gate the prior phase’s verification round earned.
Acceptance gate vs verification round
Two distinct mechanisms operate at close:
| Concern | Acceptance gate | Verification round |
|---|---|---|
| Question | ”Did the spec’d work get done?" | "What friction did the work produce that the gates didn’t catch?” |
| Owner | auditor subagent | auditor → reviewer (mandatory MR-10) |
| Output | pass / block / advisory per gate | findings list classified closed / in-budget / deferred |
| Falsifiability | gates must be falsifiable; vague “we’ll know it” gates are how phases never close | findings can be subjective; the round welcomes UX feel, doc/code drift, A11y gaps |
Nested milestone numbering
MILESTONES.md uses M{N}.{n} for primary subphases and M{N}.{n}.{m} for friction carry-overs from a prior phase. The double-nest exists specifically so deferred items from phase 6’s close (e.g. M7.2.1) look like first-class phase-7 members without losing their lineage. The orchestrator’s CI invariant validates that every M-ID referenced in AGENTS.xml exists in MILESTONES.md.
Refusal conditions at close
The reviewer’s <refusal_conditions> (AGENTS.xml.tmpl) include:
- Auditor verdict is
blockand remediation not recorded — route to implementer. - Verification round produced >3 deferred items — stop; ask whether to reopen the phase. (Two such phases in a row signals phase decomposition was wrong.)
- Invariant violation surfaced and was not addressed.
Key Terms
- Active phase pointer — the block at the top of
MILESTONES.mdnaming the currentlyopenphase. There is exactly one active phase at any time. - Carry-over — a deferred friction item from phase N that becomes a phase N+1 milestone before phase N’s close commit lands.
- Thaw decision doc — the explicit doc required to revisit any work in a
frozenphase; without it, frozen phases are opaque.
Q&A
Q: What four statuses can a phase carry, and which are terminal?
A: not-started, next, open, closed (plus optional frozen for archived). closed is terminal under MR-7; frozen is terminal-with-explicit-thaw-required.
Q: Why is ‘reopened’ deliberately not a status? A: MR-7 + MR-2. Decision docs are append-only; friction must flow forward. A “reopen” status would invite retrofitting closed work, which is the failure mode the entire control loop is designed to prevent.
Q: What’s the difference between an acceptance gate and a verification round? A: Gates ask “did the planned work happen?” (mechanical, falsifiable, owned by the auditor). The round asks “what did the work miss that the gates didn’t catch?” (subjective probing — UX, drift, doc/code skew — owned by the auditor and read by the reviewer). Both run; neither replaces the other.
Examples
Phase 7 is open with M7.1, M7.2.1 (carry-over from phase-6 close — live-dot redesign), and M7.2.2. The implementer ships M7.1, the auditor blocks once on a missing test, the implementer remediates, the auditor re-runs and verdict is pass. Phases 7’s three gates pass after the third milestone lands. Reviewer pastes 02-phase-close.md, the verification round surfaces two findings (one closed-trivial, one deferred to M8.1.1), the close decision doc lands together with the M8.1.1 entry — phase 7 becomes closed, phase 8 becomes next.
neighbors on the map
- Promotion Lifecycle Gates promoting a prompt from draft to tested
- Site Hosting Modes & Lifecycle Stages adding a new fork branching on platform vs user_git
- RALPH Console Wrapper (SS-07) submitting a RALPH run from the console UI