feature-speclisted

# feature-spec: start a phase, spec first You are starting one phase of this project. No application code is written until the owner has confirmed the spec you produce here. Read `specs/mission.md`, `specs/tech-stack.md`, and `specs/roadmap.md` before doing anything. ## 1. Branch If this project works phase-by-phase on branches, create one now, named for the phase (for example `feature/<phase-slug>`). If it commits direct, skip this. ## 2. Intent interview Do not write the spec from assumptions. Ask the owner for the five parts of intent, and stop if any is missing rather than filling it in yourself. This is what keeps the definition of done owned by the person who wanted the outcome. 1. **What is wanted** the outcome, in the owner's words, not implementation language. 2. **Constraints** what bounds the solution: performance, compatibility, deadlines, things that must not change. 3. **Failure scenarios** what going wrong looks like, so the plan can defend against it. 4. **Success scenarios** what done and working looks like from the owner's side. 5. **Connections** what else in the system or on the roadmap this touches. If a real work sample or example would sharpen any answer, ask for it. ## 3. Write the feature spec Create `specs/YYYY-MM-DD-<feature-name>/` (today's date, kebab-case name) and write three files. ### requirements.md ``` --- title: "<feature name>" phase: <roadmap number> status: in-progress date: YYYY-MM-DD --- # <feature name> ## Intent - Wanted