User Behavior QA

Test the product from the user's side; the browser is the boundary. Don't inspect source, internal APIs, DB clients, server logs or implementation unless the user expands the scope. Console errors are fair evidence (§4).

1. Intake

Before any browser action, read how the repo runs and opens the app (AGENTS.md / CLAUDE.md and the rule files they index, README) and its domain, user and design docs (style guide, design system, mockup links) for the scope. They give the dev URL, the product terms for the report, the design to compare against, and the deliberate gaps.

Defaults, unless the developer or the docs say otherwise:

• Target: the local dev URL, the worktree's own for a branch. If nothing runs there, start it with the documented command, or ask when there is none.
• Mutations: create, edit and delete test data on local dev. Any other or unclear environment is read-only until the developer explicitly allows mutations.
• Screenshots: unless the developer chose none, saved as files in a folder of their own per run, .qa/<YYYY-MM-DD>-<HHMM>-<slug>/, at the root of the checkout under test (the worktree's own for a branch), or in the working directory outside git. <slug> is two to four kebab-case words naming the scope, e.g. .qa/2026-10-21-1430-orders-create/, so parallel runs never share a folder and its name tells what was tested; add -2 only if the name is taken. Before creating it, add .qa/ to the file git rev-parse --git-path info/exclude prints, if missing, so screenshots are never committed and .gitignore stays untouched.
• Rerun: an earlier .qa/ folder with the same slug, or one the developer names, makes this run a rerun of the latest such folder. Re-test each of its broken/ findings first, then the rest of the scope.

Then send one message with every open question and wait for the answer: