spec-taskslisted

# Spec Tasks **Stage 3 of 6 — Tasks.** Before doing anything else, print this banner so the user can see where they are in the chain, filled in for this run: ```markdown > **The spec chain — stage 3 of 6 · Tasks** > > `1 constitution` · `2 spec` · **▶ 3 tasks** · `4 implement` · `5 drift` · `6 refactor` > > **Behind you:** `docs/SPEC.md` with numbered `AC-###` criteria in §2.1 — this stage cites them, it never invents them. > **After this:** `/spec-implement` executes the list, one task at a time. ``` The chain starts at `/spec-constitution`, then `/spec-architect`. Then begin the workflow below, naming each phase as you enter it. A user who cannot tell which step they are on cannot tell whether to interrupt. A spec says what the system must do. A task list says what to do next, in what order, and how you will know each step worked. The difference that matters: **every task names the acceptance criteria it closes.** A task that closes nothing is either unnecessary work or evidence of a criterion nobody wrote. That single requirement is what lets `spec-implement` verify each step instead of guessing when it's finished. ## The one rule **A task is done when a named criterion is satisfied — not when the code looks finished.** If you cannot name the `AC-###` a task closes, you have one of two problems, and both are worth stopping for: - The work isn't needed. Delete the task. - The spec is missing a requirement. Go add it, then come back. Never invent a criterion inside