qa

# QA — prove it works (verify by default, tests on request) Proving a change works is **never optional** — but that doesn't mean writing tests. Default to **verify** (drive the real thing, watch what it does). Tests / TDD are a **project choice** — **offer them, don't impose them.** After a build, the honest close is: *"Built it — want me to QA it? (I can verify it end-to-end, and add tests / do it test-first if you want.)"* ## Mode 1 — Verify (the default; always do this) 1. **Define "works."** Restate the expected behavior + acceptance criteria in observable terms. If you can't say what correct looks like, you can't verify it. 2. **Pick the lightest real check.** Drive the actual thing over reasoning about it: run the app and click the flow, hit the endpoint, run the script/CLI, render the component. Reuse the project's run/dev command; don't build harness it doesn't have. 3. **Happy path, then the edges that matter** — empty, null, error, loading, zero/one/many, unauthorized, malformed, offline/slow (`~/.mastermind/engineering/core/rigor.md`). Observe *actual* output and state. 4. **Check the invisible** — typecheck, lint, build; console/network for errors; for UI, keyboard + focus, contrast, no layout shift/regression nearby. 5. **Report with evidence** — what you ran and what you observed (command output, response, screenshot). State confidence plainly. Couldn't run a check? Say so; never present unrun work as verified. **Found a bug?** Fix the **ro...