# Phase Template

> **Output template** for `phases.md` generated by `/fluent-feature-phase`.
> The skill writes this structure to `accounts/<PROFILE>/features/<slug>/phases.md`.

---

## Template

````markdown
# Delivery Phases: <Feature Title>

| Field | Value |
|-------|-------|
| Feature | `<slug>` |
| Profile | `<PROFILE>` |
| Retailer(s) | `<RETAILER_REF>` |
| Business Spec | `accounts/<PROFILE>/features/<slug>/spec.md` |
| Complexity Tier | `SIMPLE` / `MEDIUM` / `COMPLEX` / `VERY COMPLEX` |
| Total Phases | `<N>` |
| Created | `<YYYY-MM-DD>` |
| Approved | `---` |

## Phase Overview

| Phase | Name | New | Modified | OOTB/Reused | Dependencies | Status |
|-------|------|-----|----------|-------------|--------------|--------|
| 1 | <name> | <count> | <count> | <count> | None | PENDING |
| 2 | <name> | <count> | <count> | <count> | Phase 1 | PENDING |
| 3 | <name> | <count> | <count> | <count> | Phases 1-2 | PENDING |
| ... | ... | ... | ... | ... | ... | ... |

---

## Phase 1: <Phase Name>

### Summary

<2-3 sentence description of what this phase delivers and why it's first.>

### Artifacts

| Type | Name | Source | Description |
|------|------|--------|-------------|
| Workflow | `<ENTITY>::<SUBTYPE>` | NEW | <what this workflow does> |
| Ruleset | `<RulesetName>` | NEW | <trigger event, what it handles> |
| Rule | `<RuleName>` | NEW | <what this rule does> |
| Rule | `<OOTBRuleName>` | OOTB | <configured with props: ...> |
| Setting | `<setting.key>` | NEW | <setting purpose and shape> |
| Status | `<STATUS_NAME>` | NEW | <category: BOOKING/FULFILMENT/...> |

### Dependencies

- **Prior phases:** None (this is Phase 1)
- **External:** <any external system prerequisites, or "None">
- **Existing artifacts:** <any EXISTING artifacts this phase assumes are deployed>

### Acceptance Criteria

- [ ] <Entity> can be created and reaches `<STATUS>` status
- [ ] Event `<EventName>` triggers ruleset `<RulesetName>` and transitions to `<STATUS>`
- [ ] <Observable business outcome>
- [ ] No regression on existing `<ENTITY>::<SUBTYPE>` flows

### Skills to Run (ordered)

1. `/fluent-feature-plan` — scope to Phase 1 artifacts (optional if phases.md is detailed enough)
2. `/fluent-rule-scaffold` — scaffold NEW rules
3. `/fluent-workflow-builder` — create/edit workflow JSON
4. `/fluent-settings` — create settings
5. `/fluent-build` — compile module
6. `/fluent-module-validate` — validate before deploy
7. `/fluent-pre-deploy-check` — preflight checks
8. `/fluent-module-deploy` — deploy module (rules + settings)
9. `/fluent-workflow-deploy` — deploy workflow
10. `/fluent-e2e-test` — verify acceptance criteria

### Deployment Notes

<Any special considerations: deploy order, settings before workflows, version bumps, etc.>

### Risk Assessment

| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
| <risk description> | LOW/MEDIUM/HIGH | LOW/MEDIUM/HIGH | <mitigation strategy> |

---

## Phase 2: <Phase Name>

### Summary

<2-3 sentence description of what this phase adds on top of Phase 1.>

### Artifacts

| Type | Name | Source | Description |
|------|------|--------|-------------|
| ... | ... | ... | ... |

### Dependencies

- **Prior phases:** Phase 1 (must be deployed and verified)
- **External:** <or "None">

### Acceptance Criteria

- [ ] ...

### Skills to Run (ordered)

1. ...

### Deployment Notes

<...>

### Risk Assessment

| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
| ... | ... | ... | ... |

---

<!-- Repeat Phase N sections as needed -->

---

## Phase Transition Checklist

Before advancing from Phase N to Phase N+1:

- [ ] All Phase N acceptance criteria pass
- [ ] Phase N deployed to target environment
- [ ] No regression on prior phases (re-run prior acceptance criteria)
- [ ] `status.json` updated: `currentPhase: N+1`
- [ ] Stakeholder sign-off on Phase N (if required)

## Artifact Traceability

| Spec Use Case / Acceptance Criteria | Phase | Artifacts |
|--------------------------------------|-------|-----------|
| <UC-1: description> | 1 | <Rule>, <Ruleset>, <Workflow> |
| <UC-2: description> | 2 | <Rule>, <Workflow modification> |
| ... | ... | ... |

> Every spec use case and acceptance criterion MUST appear in this table.
> If any row is missing, the decomposition is incomplete.
````

---

## Phase Status Values

| Value | Meaning |
|-------|---------|
| `PENDING` | Phase not yet started |
| `IN_PROGRESS` | Phase implementation underway |
| `BUILT` | Phase artifacts compiled/packaged |
| `DEPLOYED` | Phase deployed to target environment |
| `VERIFIED` | Phase acceptance criteria pass |
| `SKIPPED` | Phase deemed unnecessary after approval |

---

## Guidelines for Skill Authors

When writing `phases.md`:

1. **Every artifact from the spec/plan must appear in exactly one phase** — no gaps, no duplicates (except EXISTING references for context)
2. **The Artifact Traceability table is mandatory** — it proves full spec coverage
3. **Phase 1 is always the happy path** — the simplest end-to-end flow
4. **User actions belong in the same phase as their rulesets** — a button with no backend is worse than no button
5. **Settings go in the same or earlier phase than rules that read them** — rules fail silently on missing settings
6. **Each phase must have at least 2 acceptance criteria** — one positive test, one no-regression check
7. **Skills to Run must be ordered** — scaffold before build, build before deploy, deploy before test
8. **Risk Assessment is mandatory for phases with NEW integrations or cross-entity flows** — optional for simple phases
