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. ## 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 product, architecture, or compatibility decision remains open, return to the active planning workflow before finalizing the specification. ## Separate Requirements from Implementation Describe observable behavior, contracts, constraints, and acceptance evidence. Include implementation decision