Create or update a milestone — a bounded phase map that defines which invariant bundle to establish through multiple pragma cycles. Use when coordinating multi-slice phases, tracking migration state, or determining readiness to accelerate. Owns docs/milestone.md.
Create or maintain a milestone — a bounded phase map that defines which invariant bundle to establish through multiple pragma cycles. A milestone is a learning/control point, not a delivery batch.
See The Invariant Threshold for the governing principle. A milestone answers: which invariants are we establishing in this phase, and what acceleration does crossing this threshold unlock? The milestone identifies invariant bundles for this phase; capsule documents remain the authority for invariant wording.
Mode + context: $ARGUMENTS
Modes:
create — define a new milestone from roadmap directionupdate — revise after slices land, assumptions change, or phase status shiftsreview — assess milestone health and readiness to advance or complete/pragma:card/pragma:capsule/pragma:roadmapDefault: docs/milestone.md for the active milestone. Completed milestones
move to docs/milestones/[name].md. Only one milestone should be active at a
time.
One observable phase-level result. What is true when this milestone is complete that is not true now?
Which roadmap item(s) this advances. Link to docs/roadmap.md decisions,
constraints, or strategic intent.
The invariant bundles this milestone must establish. This is the core section — it defines what the phase is for without duplicating capsule law text.
Format:
Invariant bundles:
- IB-01: [bundle name]
Capsule refs: [docs/capsule.md#... | docs/capsule-<feature>.md#... | not yet formalized]
Threshold evidence: [how we'll know this bundle now holds]
- IB-02: [bundle name]
Capsule refs: [...]
Threshold evidence: [...]
Acceleration unlocked:
- [what becomes safe to delegate/accelerate once these hold]
Rules:
not yet formalized is allowed only while creating a pre-capsule milestone.
During update or review, any active bundle still marked this way must
route to /pragma:capsule update before recommending /pragma:card or
/pragma:slice.A two-part checklist that separates semantic readiness from execution readiness. Assess honestly.
Ready to formalize/update capsule?
- [ ] Key nouns are stable enough for a capsule
- [ ] 3–7 invariants can be stated clearly
- [ ] One happy path is concrete and specific
Ready to accelerate slices in this phase?
- [ ] Relevant capsule is linked for every active invariant bundle
- [ ] High-risk unknowns are isolated to spikes or assumptions
- [ ] The next slice can be verified cheaply
If most boxes are unchecked, the right action is not more implementation planning — it is more narrowing, spiking, or reframing.
Phase-level outcomes. Not individual cards — those emerge during pragma execution. These are the boundaries of what this phase covers.
Work intentionally sequenced after this milestone. This is a temporary sequencing boundary, not a permanent project exclusion.
Capsule documents this milestone depends on.
Format:
- Project capsule: docs/capsule.md
- Feature capsule(s): docs/capsule-<feature>.md
If no capsule exists for an active bundle, mark it and route to
/pragma:capsule before carding.
Link to specific assumption IDs from docs/assumptions.md that this
milestone depends on. If any are invalidated, the milestone must be reviewed.
Format:
- A-001: [statement] (confidence: NN%)
- A-003: [statement] (confidence: NN%)
Falsifiable, observable criteria for phase completion. These are phase-level, not slice-level — they describe the state of the system, not individual behaviors.
Format:
- [ ] [observable criterion]
- [ ] [observable criterion]
Candidate spikes, cards, and supporting actions. This is a suggested ordering, not a locked delivery plan. Resequence when evidence changes.
Format:
1. [spike | card | characterize | contract | harden]: [description]
2. [spike | card | characterize | contract | harden]: [description]
3. ...
Rules:
Current state of each major work area within the milestone. Use completion markers and brief status notes.
Format:
- [area]: COMPLETE | IN PROGRESS | NOT STARTED — [brief status]
Stability boundaries — components, schemas, interfaces, or behaviors that this milestone explicitly preserves. This prevents collateral damage and makes the change surface visible.
Risks specific to this phase, with mitigation strategies.
Format:
- [risk] (source: A-### | D-### | R-### | local) → [mitigation: spike | assumption tracking | fallback plan]
Unresolved questions that may affect sequencing or scope. Each should have a path to resolution (spike, prototype, stakeholder input).
Format:
- [capsule-gap | roadmap-decision | assumption | spike]: [question]
Resolution path: [/pragma:capsule update | /pragma:roadmap update | /pragma:assumptions update | /pragma:spike]
For migration milestones, track what legacy components are still live and what coexistence constraints exist.
Format:
- [legacy component]: [status: active | deprecated | removed]
Coexistence constraint: [what must remain true while both exist]
Cutover readiness: [criteria for retirement]
When this milestone should be re-examined, even if no explicit review is scheduled.
Default triggers (always include):
After writing or updating, check:
not yet formalized?update/review, are all active bundles capsule-formalized (no
lingering not yet formalized)?/pragma:card during execution./pragma:roadmap first./pragma:capsule./pragma:spike, /pragma:shaping-*, or further narrowing./pragma:card./pragma:spike./pragma:roadmap (and optionally /pragma:shaping-* before re-entering)./pragma:capsule update/pragma:roadmap update/pragma:assumptions update/pragma:contractdocs/assumptions.md — any invalidated?none required when no change)planning/pragma:capsule (if gate passes and capsule needed),
/pragma:card (if capsule exists and next behavior is clear),
/pragma:spike (if gate fails due to uncertainty),
/pragma:roadmap update (if milestone completes), or first non-none
authority delta command/pragma:consult