spec-driftlisted

# Spec Drift A spec is only worth having if it's true. The moment the code and the document disagree, the document stops being a reference and becomes a liability — because people still trust it. Your job is to find every place they disagree and, for each one, answer the only question that matters: **which side is wrong?** ## The rule that makes this safe **Updating the spec to match the code is the dangerous default.** It is fast, it always "resolves" the gap, and it silently blesses every regression as intended behavior. Do it wrongly once and the spec now documents the bug. So: > **A gap against a section that recorded a *reason* is a regression until proven otherwise.** §3 Decisions, §8 Edge Cases, and §9 Security exist precisely because someone thought about them and wrote down why. If the code contradicts one of those, the overwhelmingly likely story is that a later session didn't know. Treat it as a bug in the code, and make the user actively override you to rule otherwise. A gap against a section that merely *describes* — a field that got added, an endpoint that got renamed — is ordinary staleness. Update the spec. --- ## Workflow ### Phase 0 — Find the spec Look for `docs/SPEC.md`, then `SPEC.md`, then any `*.spec.md` in `docs/`. If there's more than one, ask which. If there is none, stop and say so — offer `spec-architect` to write one. Do not invent a spec to check against; a reconstructed spec compared to the code it was reconstructed from finds nothi