speclisted

# Write/update a spec Specs live in the project's `docs/specs/`. Keep them short, concrete, and implementation-oriented — a useful spec beats a perfect document. ## Steps 1. **Pick the closest template** from this plugin's `templates/specs/`: `feature.md`, `bugfix.md`, `api-contract-change.md`, `migration.md`, `workflow-change.md`, `integration-change.md`. 2. **Link the spec** back to the CRD section, existing docs, code behavior, or the explicit user decision that justifies it. 3. **Separate Stage A / MVP scope from future-stage notes.** Future notes guide naming and boundaries; they do not expand the current implementation. 4. **Write acceptance criteria in EARS form** with stable IDs and a test pointer — each becomes a fail-first test (the red list) for L2+/bug fixes. Five EARS forms (combine for complex): `THE SYSTEM SHALL <r>` · `WHEN <trigger> …` · `WHILE <state> …` · `IF <cond> THEN …` · `WHERE <feature> …`. IDs (`AC1`, `AC2`, …) are stable — **append, never renumber**; a renumber breaks the `→ test:` links and the checkpoint. Keep it proportional: trivial CRUD gets a plain "returns 201 + shape" criterion, not invented branches. 5. **Record the technical approach and tradeoffs** — if the CRD intent is right but a different technical shape is safer, document why. For a **cross-cutting, durable** L3/L4 decision (new dependency, new architectural layer, workflow-state model), also write an ADR to `docs/adr/NNNN-<slug>.md` from `${CLA