to-speclisted

# To Spec Turn the current conversation and codebase understanding into a spec. Do not start a new interview. If a consequential question is unresolved, publish a truthful `draft` or `blocked` spec and name the decision or evidence needed; do not invent an answer merely to make the spec look ready. Verify the model-invoked `/delivery-proof` companion is installed. If it is missing, say so and apply the complete embedded proof contract rather than omitting the gate. Use the project's configured issue tracker, domain glossary, and ADRs. Run `/setup-matt-pocock-skills` if the tracker conventions are missing. ## Process 1. Read the relevant code, prior decisions, prototypes, research, and tracker history. 2. Separate the desired outcome from the proposed implementation. Preserve decision provenance: user-owned choices are confirmed, explicitly delegated, provisional, or blocked; facts may be evidence-backed. Evidence can inform a choice but cannot authorize it. 3. Prefer existing public test seams. If a consequential new seam was not settled earlier, record it as an unresolved decision instead of soliciting a fresh answer here. 4. Apply `/delivery-proof` to every acceptance criterion. If that companion skill is not installed, the required/achieved level, environment, independent-oracle, non-vacuity, and truthful-blocking rules embedded below still apply. 5. Run the readiness audit below, then publish to the configured tracker. ## Spec template ### Status `draft | blocked