Read the actual files in scope using the host's file tools. Do NOT ask the user for file content the host can read directly. When .sumo-qa/repo-map.json is present, sumo_qa_query_repo_map locates candidate tests and files for the area by path / tag / type (e.g. test_file) — a fast way to find what already exists, sharpening the named risks (step 4) and test set (step 7). Absent or stale → read the files directly; it's an accelerator, never a substitute for reading the code.
Context bundle (optional input). If the host supplies a context bundle — a compact, host-neutral record of the issue/PR summary, changed files, any test/CI evidence (each with a source + freshness marker), and user constraints — PREFER it to seed scope and the user-constraint list: validate and read it via sumo_qa_format_context_bundle. When NO bundle is present, fall back to reading the files and the ticket directly — it is an accelerator, never a requirement, with no GitHub or network dependency. Treat any stale/unknown/absent test/CI fact in the bundle as stale: it informs which risks remain unproven, it never lets you claim a risk is already covered. The bundle sharpens the named risks (step 4); it does not replace reading the code.
Identify 3-7 named risks. Each risk MUST be specific (not "input validation breaks" but "currency conversion at the GBP→USD boundary rounds incorrectly when the rate is supplied with >6 decimal places"). Anchor each in a file path or domain term from the user's words, and do not invent thresholds, rules, states, or edge cases that are not present in the supplied change or code. When the intent is refactor/move/extract without behaviour change, name preservation risks: rendered values, exact formatting, thresholds, rounding, disabled states, and public contract must remain unchanged. Do not merely restate the production formulae as generic calculation risks.
Anchor-fit rule (pinned): the cited line must be semantically about the risk, not merely the nearest plausible-looking line. If the risk is about behaviour X and the cited code does Y, you have a stapled anchor — delete the risk. Before listing a risk, ask: "if I removed this line, would the risk still make sense?" If yes, the anchor is wrong.
Stapled-anchor example (BAD): Risk: "discount must be correctly calculated when subtotal is at the tax threshold" citing const tax = subtotal * 0.0825. The cited line computes tax, not discount, and the sketch defines no tax threshold — this is a fabricated edge case wearing a real line number.
Grounded example (GOOD): Risk: "valid promo code does not subtract from total" citing const total = subtotal + tax + shipping; — the cited line is the exact site where the discount must be applied.
Security-relevance pass (grounded, pinned): run the internal security-relevance check from using-sumo-qa while naming risks. If the change creates a CONCRETE security failure mode — auth/authorisation, secrets, input sanitisation, rate limiting, audit logging, token lifecycle, or a security-relevant config/dependency movement — name it as ONE of the anchored risks (cite the file:line / behaviour, e.g. "old token still validates after refresh — no revoke-on-refresh"), give it a catalogue technique (step 5) and a concrete test (step 7), exactly like any other risk. Security CO-APPLIES, so step 2's single-classification load missed security_change's catalogue entries — when this pass fires, also load sumo_qa_load_standards(classification="security_change") and sumo_qa_load_rules(classification="security_change") before applying its must-consider probes. Deeper evidence → sumo-qa-security-testing. If the change has NO grounded security surface, OMIT security entirely — no generic "consider security" line. NEVER dump a vulnerability checklist (OWASP categories). For a security risk, the next action is a TEST/review/static/dynamic/config/dependency check phrased against the named risk — do NOT bolt on a scanner or vendor product name because the surface is security; a tool name is earned only via the discovery discipline (observed surface + the user's actual stack), exactly as for any other risk. An ungrounded scanner name on a security risk is the vendor/tool-name-dump anti-pattern.
Surface-signal rule (pinned): when the change touches a recognisable surface — schema/model validation, request/response or IPC protocol, CI/config/deploy, async/retry/idempotency, auth/token — name the risk from the surface, not the library. Two changes on the same surface get the same probes (a removed field over any transport → "an existing consumer still referencing it keeps working or fails loudly, not silently"); the loaded rules (sumo_qa_load_rules) carry these per surface — apply them tech-agnostically, going library-specific only when the user or repo supplied the library. Cover the surface's distinct probes (don't restate one in three costumes), and make each test assert a concrete outcome — the input and what must hold — not that a consumer "accesses" a value (async retry → "a redelivered message double-charges unless an idempotency key makes the side effect run exactly once"; contract → "an old-shaped payload is still accepted or explicitly version-gated").
Review-feedback memory (advisory hints only). If the team saved recurring review lessons (sumo_qa_capture_review_feedback, under the #92 user-pack feedback/ subdir), consult them as a HINT source to sharpen — never replace — the named risks: apply a lesson only on a trigger_signal match with THIS change, surface it SEPARATELY as its OWN labelled line placed OUTSIDE the numbered risks ("advisory hint from saved review feedback: …") — NEVER as a risk's title or as risk #1's name (a risk titled "Advisory hint — …" reads as folded-in, not separated) — and treat a match as an ordinary anchored risk (gets a technique in step 5). It NEVER overrides a canonical classification/change-rule (only a #92 pack does); absent/empty memory changes nothing. Do NOT auto-capture — saving is a separate, explicit, user-confirmed step storing only the user's own summary, never raw code/diff/secret/body.
Output: conversational prose, sectioned (risks, tests, techniques, specialty tools, open assumptions). No JSON blob.
Risk-to-test ledger appendix (optional, structured). The prose brief is the deliverable. When the user wants a paste-into-ticket artifact ("give me the ledger", "track these as a traceability table"), project the SAME named risks + proposed tests into the structured ledger via sumo_qa_format_risk_ledger and append it below the prose — never instead of it. A planning ledger needs NO code change and NO test run: every row is evidence_status: planned with test holding the proposed check (a planned: … phrase or a test path you'd write), source_anchor the risk's file/domain anchor, and residual: open. The tool only validates and formats — YOU name the risks (step 4). Skip it when the user just wants the prep brief.
