to-speclisted

# Write Specification Preserve what must be built and why without freezing volatile implementation details. Synthesize settled decisions; do not reopen them or invent missing requirements. Read `references/evidence.md` when assessing requirement quality, traceability, or acceptance criteria. Keep one owner for the specification; if delegation is explicitly authorized, use `delegate-work` only to collect independent repository or external evidence, then reconcile it before writing. ## Respect the Specification Contract - Work read-only except for the requested specification artifact. - Return the specification in the response by default. - Save it to a file only when the user requests a file, provides a path, or an established repository workflow requires one. - Do not publish to GitHub, Linear, or another external tracker without explicit authorization and an exact target. - Do not repeat a planning interview when the active context is already decision-complete. ## Gather the Settled Context Read: - the user request and accepted clarifications; - the active plan and prototype or research findings; - relevant repository behavior, tests, domain vocabulary, and architecture decisions; - existing issue or specification material and comments; - compatibility, security, data, migration, and operational constraints. Verify important claims against the repository when possible. Preserve the user's language unless the project has a more precise established term. If a material