novahiz-assess-definelisted

# novahiz-assess-define **Step 3 of 5** in the assessment roadmap. No file changes here. The deliverable is a specification draft. Previous step: `novahiz-assess-research`. Next step: `novahiz-assess-shape`. ## Entry Research is done. Define what the solution does for its users, not how the code will be written. ## What to define ### 1. User-facing behavior What does the user see, do, and experience? Write stories or scenarios. ### 2. Core capabilities What must the solution do? List the essential features and leave the nice-to-haves out. ### 3. Success criteria How do you know it works? Concrete outcomes tied back to the success signals from intake. ### 4. Scope boundaries In scope, out of scope, and future. ### 5. Non-functional requirements Performance, security, accessibility, scalability. ## Define method Resolve remaining ambiguity with the harness `question` tool, following the `novahiz-clarify` pattern: sweep the risk families, then ask frontier batches. ``` question({ questions: [ { header: "<ambiguity>", question: "<why it matters for the spec>", options: [ { label: "<recommended>", description: "<consequence>" }, { label: "<option>", description: "<consequence>" } ] } ] }) ``` ## Output A specification draft with all five sections. Someone else should be able to read it and know exactly what to build, while implementation choices stay open. The spec stays in the chat. Nothing is written to dis