spec-driven-workflow

# Spec-Driven Workflow — POWERFUL ## Overview Spec-driven workflow enforces a single, non-negotiable rule: **write the specification BEFORE you write any code.** Not alongside. Not after. Before. This is not documentation. This is a contract. A spec defines what the system MUST do, what it SHOULD do, and what it explicitly WILL NOT do. Every line of code you write traces back to a requirement in the spec. Every test traces back to an acceptance criterion. If it is not in the spec, it does not get built. ### Why Spec-First Matters 1. **Eliminates rework.** 60-80% of defects originate from requirements, not implementation. Catching ambiguity in a spec costs minutes; catching it in production costs days. 2. **Forces clarity.** If you cannot write what the system should do in plain language, you do not understand the problem well enough to write code. 3. **Enables parallelism.** Once a spec is approved, frontend, backend, QA, and documentation can all start simultaneously. 4. **Creates accountability.** The spec is the definition of done. No arguments about whether a feature is "complete" — either it satisfies the acceptance criteria or it does not. 5. **Feeds TDD directly.** Acceptance criteria in Given/When/Then format translate 1:1 into test cases. The spec IS the test plan. ### The Iron Law ``` NO CODE WITHOUT AN APPROVED SPEC. NO EXCEPTIONS. NO "QUICK PROTOTYPES." NO "I'LL DOCUMENT IT LATER." ``` If the spec is not written, reviewed, and approved, implementation does...