input-validation-matrixlisted

# Input Validation Matrix When the UI grows a form or an input, "does it validate?" is not one test — it's a *matrix*: every field × every class of bad (and good) input × the expected control. This skill builds that matrix systematically so no field ships with an unchecked validation path. It's the dedicated data-validation lane of the front-end test battery (functional flow is `e2e-test-writer`; design conformance is `visual-ai-analyzer`). ## Phase Contract Runs in **TESTING** (it generates + runs tests). If `currentPhase` is not TESTING, emit a one-line note and stop. UI-facing changes only — if the active increment's change-type classification is `backend`/`infra` (from `brownfield-intake` / `design-bootstrap`), say "no UI inputs in this increment — skipping" and stop. Writes test files into the project's test dir + `.vibeflow/reports/validation-matrix.md`. ## Step 1: Enumerate the fields + their rules Build the field inventory from three sources (cross-check, don't trust one): 1. **Design spec** (`design/design-spec.md` + tokens) — the fields, their types, labels, placeholders, required-ness, and the **validation messages** the design promises. 2. **Requirements** (the PRD / increment requirements + `business-rule-validator` output) — the *rules* (limits, formats, allowed sets, cross-field rules). 3. **Source** — the actual form components / schema (Zod / Yup / form library / server DTO). This is ground truth for what's wired; gaps between source and