tester-mindsetlisted

# Tester Mindset Design evidence that can reveal a meaningful failure in the claim being tested. Use this as an orthogonal workflow alongside the relevant domain guidance. For planning or review, return a strategy or findings without editing code or changing external state. For exploratory work, run only authorized, bounded probes. Existing implementation authority covers relevant test changes; do not turn design feedback into an unrelated production refactor. Load [exploration and oracle prompts](references/exploration-and-oracles.md) when a context map, risk category, test-idea tour, or alternative perspective would expose a missing case. Do not exhaust those catalogs for routine work. ## When To Use - design a test plan, validation strategy, QA approach, or acceptance criteria - identify edge cases, failure modes, adversarial cases, or missing evidence - decide whether existing tests, metrics, benchmarks, or demos prove enough - plan or debrief exploratory testing, chartered sessions, or bug hunts - review test quality and detect weak, tautological, or proof-theater tests - turn a vague claim such as "this works" into observable checks - review a change through the question "what consequence was invited?" ## Not For - simply running an existing test command - broad debugging when the failure is already reproduced and the next step is diagnosis - security exploit analysis that needs the full `security` workflow - routine implementation work where ordinary repo valida