stage-2-validatelisted

Stage 2: three sequential gates — problem → solution → money. Skipping a gate creates false positives at that gate. Validation = observed real behavior, never collected compliments. Load `method-rules`; read `state.json` (mode + capabilities decide rungs). Templates: the `stage-2-validate-templates` skill. If the assumption map has a deadly feasibility assumption (AI-core always does), remind the user stage 3 starts NOW in parallel — don't wait for V3. **Every experiment in this stage can end in four ways, and the fourth is not a soft version of the third**: `supported` · `weakened` · `inconclusive` · **`invalid`**. An experiment is `invalid` when the *instrument* failed, not the hypothesis — the mock was broken, the tracking never fired, the wrong audience showed up, the payment link 404'd, consent was mismatched, the sample was contaminated. An invalid run is **repaired and re-run**; its numbers never enter the ledger and never move a gate. Reporting instrumentation failure as market evidence ("we ran it and nobody converted") is one of the easiest ways to kill a good idea with a bug. Before any run that measures something, do the cheap instrumentation check: fire the event yourself, load the page, submit a test row — a dry run with synthetic input validates mechanics only and is never itself evidence. **Participant data**: any interactive contact (interview, mock session, pilot) requires a row in `private/participant-data-manifest.md` BEFORE material enters any artifact