pr-qa-guidelisted

# PR QA Guide Produce a QA guide a tester who has never seen the code can follow: what to set up, what to look for, what to test first, where the feature must NOT appear, and what not to file as a bug. **The deliverable is one markdown file.** GitHub-flavored markdown, with `- [ ]` checkboxes a tester can tick as they go. That is what ReviewStage renders on the QA page, what pastes into a ticket, and what a reviewer can diff when the branch moves. Do not produce HTML, and do not try to publish anything, unless the person asking is sitting in an interactive session and explicitly asks for a shareable page — see the appendix at the end. Two properties define a good guide, and they pull in different directions — you need both: 1. **Every sentence is traceable to evidence** — the diff, the actual code, the PR review threads, the commit history, or the ticket. If you cannot point to where a claim comes from, do not write it. Never pad with generic advice ("test edge cases", "verify performance"). 2. **A tester can act on every sentence without reading code.** You derived the tests from the source; you must then translate them out of it. See "Write for a tester" below — this is the step most likely to be skipped, and skipping it makes the guide unusable no matter how sound the analysis underneath. ## Write for a tester (apply to everything QA-facing) - **No code identifiers** in titles, steps or verdicts: no method/class/field names, no commit SHAs, no "the r