Phase 2: Development

Phase 2 is where code gets written. Every spec passes through five stages in strict order. There are no shortcuts, no stage skipping, and no exceptions.

The cardinal rule: never write code without a failing test.

1. SPEC

Skills: /specsafe-new (create), /specsafe-spec (refine)

Every piece of work starts as a specification. The spec defines what will be built with enough precision that tests can be derived from it mechanically.

A spec includes:

• Purpose -- Why this work exists. What problem it solves.
• Scope -- What is included and what is explicitly excluded.
• Requirements -- Testable statements using normative language (SHALL/MUST).
• Technical Approach -- How the implementation will work at a high level.
• Test Strategy -- What types of tests are needed and what they cover.
• Implementation Plan -- Ordered steps for building the feature.

Only one spec is active at a time. Finish it before starting the next one.

Transitions to: TEST

2. TEST

Skill: /specsafe-test Persona: Reva -- Forge (TEST)

Reva generates tests directly from the spec's scenarios and acceptance criteria. Every test starts skipped. This is deliberate -- skipped tests represent work that has been defined but not yet implemented.

The test suite is the contract. It captures exactly what the implementation must do. If the spec says "SHALL return a 404 when the resource does not exist," there is a test for that specific behavior.

Tests are written to fail first. They will be unskipped one at a time during the CODE stage.

Transitions to: CODE

3. CODE

Skill: /specsafe-code Persona: Zane -- Bolt (CODE)

Zane follows the red-green-refactor cycle with religious discipline:

1. Unskip one test. It fails (red).
2. Write the minimum code to make that test pass (green).
3. Refactor if needed, ensuring all tests still pass.
4. Repeat with the next skipped test.

This loop continues until every test in the suite is unskipped and passing. No test is left behind. No code is written speculatively.

The key constraints:

• Never unskip more than one test at a time.
• Never write code that is not required by a failing test.
• Never skip the refactor step -- clean code is not optional.
• If a test cannot be made to pass, revisit the spec.

Transitions to: QA

4. QA

Skill: /specsafe-qa Persona: Lyra -- Warden (QA)

Lyra is skeptical by design. She does not accept assertions -- she requires evidence. The QA stage runs a full validation of the implementation against the spec.

Lyra checks:

• All tests pass. No skipped tests remain. No flaky tests tolerated.
• Requirements met. Every SHALL/MUST in the spec has corresponding passing tests.
• Edge cases covered. Boundary conditions, error paths, and unusual inputs are tested.
• Code quality. No obvious technical debt introduced during the red-green-refactor cycle.

The QA stage produces a QA Report with a clear recommendation:

A NO-GO is not a failure -- it is the system working as designed. Better to catch problems here than in production.

Transitions to: COMPLETE (on GO) or back to CODE/SPEC (on NO-GO)

5. COMPLETE

Skill: /specsafe-complete Persona: Cass -- Herald (COMPLETE)

Cass manages the final gate. COMPLETE is a human approval step -- the developer reviews the QA report and confirms the spec is done.

When approved:

• The spec moves from QA status to COMPLETE status.
• The QA report is archived alongside the spec.
• The spec is closed and cannot be reopened.

This is ceremony with purpose. It creates a clear record of what was built, how it was validated, and who approved it.

Transitions to: Done. Start the next spec.

The TDD Discipline

The entire Phase 2 pipeline is built around a single conviction: tests define implementation, not the other way around.

This means:

• You do not write code and then write tests to cover it.
• You do not skip the TEST stage because "the code is simple."
• You do not mark tests as passing without actually running them.
• You do not move to QA with skipped tests remaining.

Every stage exists to enforce this discipline. The personas are designed to resist shortcuts. Reva will not let you skip test generation. Zane will not let you write code without a failing test. Lyra will not let you pass QA without evidence. Cass will not let you complete without a QA report.

The process is strict because the alternative -- untested code, ambiguous requirements, skipped validation -- is more expensive in every measurable way.