sumo-qa-strategisinglisted

# Strategising sumo-qa work Help the user produce a risk-prioritised, repo-anchored QA strategy by walking the strategy one section at a time: inventory the actual repo, surface per-area risks, fit specialty tools, prioritise, design the pyramid, phase the rollout. The user has org context (team size, release cadence, regulatory pressure, current pain points) the AI can't infer from code alone — surface it through questions, don't assume it. **Announce at start:** *"Walking the repo for a phased QA strategy."* ## 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. <HARD-GATE> Do NOT emit a strategy in one message. Walk the sections one at a time: inventory → risks → tools → prioritisation → pyramid → rollout → residual. A strategy dumped in one turn is generic consulting; a strategy built collaboratively is implementable. </HARD-GATE> ## The Iron Law **WALK THE REPO FIRST.** No repo-wide plan without using the host's file tools to map the actual codebase — strategy that doesn't cite specific service names, module paths, and existing test directories is generic consul