# Phase Vocabulary

The canonical phase numbering and names for forge's prototype-driven SDLC. Skills, agents, and command files reference this when stating phase context. Other files must NOT invent their own numbering.

## The seven phases

| # | Canonical name | Primary skill | Primary agent | What happens |
|---|---|---|---|---|
| 1 | **Concept** | `concept-slides` | `concept-designer` | Low-fidelity slide deck capturing the product idea — hook, sub-concepts, sketch fidelity, user journey, deferrals |
| 2 | **Wireframe** | `build-wireframe` | `wireframer` | Single-HTML annotated wireframe with click-through demo and callouts; static, no real backend |
| 3 | **Prototype** | `build-prototype` | `prototype-builder` | Working interactive build with mocked data — fast iteration, manual verification, no test rigor |
| 4 | **Iterate** | `iterate-prototype` | `prototype-reviewer` | Tighten interactions, fix gotchas, capture conventions as side effects of doing the work |
| 5 | **Codify** | `harden` | `prototype-codifier` | Transcribe locked prototype into architecture pages, ADRs, slice graph — the bridge to production-build |
| 6 | **Production-build** | `build-tdd` | `builder` | Real code with full TDD discipline, production standards, gates, and reviews |
| 7 | **Deliver** | `deliver-deploy` / `deliver-db-migration` / `deliver-onboarding` | (skills only; no dedicated agent) | Ship to production: migrations, deploy, onboarding docs |

## Softening rule

Phases are **defaults, not requirements**. The work-item manifest at `.forge/work/{type}/{name}/manifest.yaml` tracks the plan under `phase_plan.{phase}` (v6) with values like `active`, `active-light`, `skipped`, `complete-inline` — skips, reduced-rigor runs, and retroactive entries are all legitimate. See `templates/manifests/v6/SCHEMA.md` §3 for the full vocabulary. Examples:

- A 30-line bugfix may skip concept + wireframe + prototype entirely and start at codify
- A library extraction may skip prototype + iterate (no UI surface to verify against)
- A spike may stop at prototype and never codify

Commands (`/feature`, `/bugfix`, `/greenfield`, `/refactor`) ask the AI to propose phase skips at preflight; the user confirms. Forcing all seven on every work item is wrong shape with current model capability.

## Which rules apply when

All eight common rules auto-load every session except `testing.md`, which is paths-conditional (loads only on test files and `src/` code).

The content of the following rules is **scoped to Phase 5+ work** even though they auto-load — agents reading them should treat their guidance as applying from codify onward:

- `rules/common/testing.md` — TDD becomes mandatory at Phase 5; Phases 1–4 (prototype work) are exempt because mock-heavy tests under-catch wiring bugs (see `skills/build-tdd` and `skills/iterate-prototype`)
- `references/common/quality-gates.md` — full gate set (the rule stub at `rules/common/quality-gates.md` fans out to this reference)
- `rules/common/git-workflow.md` — conventional commits + branch hygiene; relevant once Phase 5 codify produces code-shaped artifacts

The other five rules (`security`, `guardrails`, `verification`, `skill-selection`, `forge-system`) apply across all phases.

## How to reference this in agent/skill files

When a file needs to state its phase context, use the canonical name and number together on first mention:

> "Dispatched at Phase 5 (codify) lock."
> "This skill runs in Phase 6 (production-build), after harden has produced the architecture and slice graph."

Do NOT:
- Use a different number for the same phase across files
- Use only the number ("Phase 5") without the canonical name on first mention
- Coin new phase names ("hardening phase", "the codification step") — use `codify` everywhere
- Refer to a non-existent phase ("Phase 4 lock" when you mean Phase 3 prototype lock or Phase 4 iterate lock)

## Skill-name vs phase-name mismatches (intentional)

Two skills carry names that don't match their phase name:

| Phase | Phase name | Skill name | Why mismatch is OK |
|---|---|---|---|
| 5 | codify | `harden` | "Harden" describes what the work feels like (production-grade hardening of prototype decisions); "codify" describes what the output is (codified plans). Both names persist; use phase name when stating context, skill name when invoking. |
| 7 | deliver | `deliver-*` (multiple) | The phase has several skills, not one; "deliver" is the phase, each skill is one delivery surface. |