CRUMB a card from devarno-cloud

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 note

Status 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.md will operate on.
  • open — phase-open decision doc exists; implementer/auditor cycles in flight.
  • blocked — internal sub-status; an auditor block verdict on a milestone routes back to the implementer (audit.fail event in AGENTS.xml). The phase stays open; only individual milestones report block.
  • 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:

ConcernAcceptance gateVerification round
Question”Did the spec’d work get done?""What friction did the work produce that the gates didn’t catch?”
Ownerauditor subagentauditor → reviewer (mandatory MR-10)
Outputpass / block / advisory per gatefindings list classified closed / in-budget / deferred
Falsifiabilitygates must be falsifiable; vague “we’ll know it” gates are how phases never closefindings 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 block and 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.md naming the currently open phase. 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 frozen phase; 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