sumo-qa-deciding-approachlisted

# Deciding the QA approach **Announce at start:** *"Picking the QA approach for this change."* ## Output discipline (mandatory) Inherits the global discipline from `using-sumo-qa`: **output discipline** (never surface internal taxonomy labels — say *"behaviour change in pricing"*, not *"Classification: business_logic_change"*), **output economy** (spend output on findings not framing; no preamble or self-narration; one question per turn; no closing pleasantries), knowledge authority hierarchy, internal scaffolding stays internal, and specialty-tool fit. ## The Iron Law SHAPE FIRST, then REACHABILITY. Decide single-change vs repo-wide vs `no-tests-recommended` *before* picking a per-change approach — wrong shape means wrong-shaped tests. When the shape is single-change, check reachability/load-bearing *before* picking a test-writing approach — orphan code routes to `recommend-removal`, not test scaffolding. ## When to Use `using-sumo-qa` routes here on every QA-shaped intent; this skill ALWAYS runs before any other QA skill. Even simple intents pass through — `no-tests-recommended` and `verify-existing` exist for cases that don't merit new tests. ## Checklist Track these as an ordered work list (use the host's task primitive if available, otherwise a numbered inline tracker) and complete in order: 1. Read the user's intent verbatim and any supplied target paths. 2. Call `sumo_qa_load_classifications()` and `sumo_qa_load_approaches()` — the only catalogues this router l