QA

Test the change the way a user would, capture evidence, and report what you found. A passing type check, or one screenshot of a loaded page, is not QA.

Do not fix code during QA unless asked. Report it.

When to use

• Asked to QA, test, or verify a pull request, branch, or feature in the running app.
• The risk is behavior a user can see, including permissions.

When to skip

• The change cannot affect a user-visible flow (copy-only is still worth a look; a lockfile bump is not).
• You were asked to fix a known bug. That is iterate-browser, and it ends in a code change.

The loop

1. Scope. Read the pull request or git diff <base>...HEAD. Write a short plan: the happy path, the edge cases the diff introduces (empty state, validation, permission denied), and one nearby flow that could regress. For each scenario, note the setup it needs before the behavior is visible.
2. Environment. Local browser tools, or a remote desktop when that is what the run has. Prefer a recording for multi-step or intermittent flows. Save artifacts where the run will keep them.
3. Start the stack. Use the repo's dev command. Reuse servers that are already healthy. Poll the health check and the app URL before opening a browser. An expected local warning is not a failure.
4. Setup. Do whatever setup the scenario needs so you can verify the work: an account, permissions, seed data, a feature flag. Record what you changed so you can put it back. Never point a write at production. Never print a secret.
5. Sign in. Walk the real login, including the identity-provider redirect. Wait until the app shell renders.
6. Exercise. For each scenario: navigate, then click, type, and submit as a user would. Capture before, the result, and any error or empty state. Watch the browser console and the server log. Confirm the persisted result, not only the toast — reload, or read the row back.
7. Clean up. Restore the setup you changed. If the flow destroyed disposable dev data, reset that data only. Stop servers you started.
8. Report. Lead with the verdict.

Flag a finding when behavior differs from the pull request or the test plan, or looks wrong to a user: broken layout, missing translations, wrong numbers, unhandled errors, access that should have been denied.

Report

## QA: <feature>

**Verdict:** Pass | Pass with findings | Fail
**Environment:** <where>, with <setup used>

### Scenarios
- Pass: <scenario> — <what happened>
- Fail: <scenario> — <what happened>, expected <expected>

### Findings
1. **blocker | major | minor** — <one line>
   Steps. Evidence. Suspected file:line if known.

### Not tested
- <scenario and why>

Embed the screenshots. Blockers first.

Related

• iterate-browser — reproduce a known frontend bug and fix it.
• babysit — stay on the pull request until checks and review threads are green.
• skills-index — vault catalog.