stage-3-verifylisted

Stage 3: verify. Starts as soon as the assumption map (0.5) shows a deadly feasibility assumption — do NOT wait for stage 2 to finish (if verify fails, all validation work on that direction is wasted). Two evidence types, never interchangeable: "the demo works" ≠ "people want it", and "people are in pain" ≠ "the AI is good enough". Load `method-rules`; read `state.json`. Templates: the `stage-3-verify-templates` skill. ## Gate R1 — can we do it at the required quality (error-analysis-first) For plain SaaS this gate is light. For AI-core products it is where most products silently die post-launch. The order is **error-analysis-first** — never write evals for imagined errors. 1. **Dirty spike** (`spike/`): core only — real input → processing → output. No UI, no auth. Real data sources by rung: public datasets in the domain (baseline); user-provided real files in `private/` (handoff — ask the interviewed/waitlist contacts, one more reason stages 2∥3 run together); a "value-for-data" exchange page (market-evidence). Maintain `spike/data-manifest.md`: for every real dataset/file used — source, owner, permission obtained (how), sensitivity, storage location (`private/` for anything personal). No real customer data enters the spike without a manifest row. 1b. **Run contract** (`spike/run-contract.json`) — write this BEFORE any scored run, and validate it with `node "${CLAUDE_SKILL_DIR}/../../scripts/validate-run-contract.js" <idea-dir>`. A harness you generated is not evidence ju