fastapi-qalisted

QA the current change and capture evidence a reviewer can trust. The point is to run *the QA that's valid for this change* — a UI tweak needs screenshots, a backend fix needs the endpoint exercised and the suite run, a CLI change needs its commands run. Don't screenshot a database migration; don't run the full browser e2e suite for a one-line helper. ## Steps 1. **Read CLAUDE.md** for how this project builds, runs, and tests, plus any e2e/screenshot tooling it already has. **Read any `.claude/rules/*.md`** whose `paths:` glob covers the changed files — they often name the ports, fixtures, or QA conventions for that layer. 2. **See what changed.** `git diff master...HEAD` for the branch's work, plus `git diff` / `git diff --cached` for uncommitted edits. **Classify each surface the diff touches** (a change can span more than one — QA each with its own method): - **UI / frontend** �� components, styles, templates, pages, client-side behavior. - **Backend / API / service** — routes, handlers, business logic, jobs, DB. - **CLI / tool** — command entrypoints, flags, output. - **Library / SDK** — importable code with no runtime surface of its own. - **Docs / config / infra only** — no runtime behavior to observe. 3. **Run the QA that fits each surface** (use **`fastapi-run`** whenever you need to bring the app or service up): - **UI / frontend** → **capture screenshots.** Prefer the repo's own tooling (Playwright, Cypress, Storybook, a visual-test harness) — it