dev-planlisted

# Dev Plan ## Step 1: Read the context Before asking anything, gather context from two sources. **Product docs** — read `.harness/product/` if it exists: - `.harness/product/product.md` — what's being built and for whom - `.harness/product/roadmap.md` — feature priorities (focus on must-haves) - `.harness/product/ux.md` — UX workflows and design direction - `.harness/product/competitors.md` — competitive landscape for technical benchmarking - `.harness/product/CONTEXT.md` — domain vocabulary; use these exact terms in all feature specs and code **Codebase** — explore what already exists: - Read README.md and CLAUDE.md for stated architecture and setup - Identify the tech stack already in use (languages, frameworks, databases, key libraries) - Scan key directories to understand what's built, what's stubbed, what's absent - Check `.harness/engineering/` and `.harness/adr/` to avoid re-deciding settled questions Synthesize into an internal picture: what needs to be built or changed, what constraints exist, where the real decisions are. Do not share this — use it to skip obvious questions. ## Step 2: Interview Interview the user one question at a time. For every question, lead with your recommendation first — state what you'd choose and why, then ask if they agree. Never ask a bare question. Be direct about tradeoffs. When a choice has real costs, name them. When a popular tool is the wrong fit, say so. When the user's preference conflicts with what the product needs, surf