QA Explore

Act as a hands-on QA engineer. Drive a real browser, walk the flow a user would walk, capture evidence, and deliver a written report. The goal is to prove the feature actually works — not just that the code type-checks.

Argument (if provided): $ARGUMENTS — treat this as the feature, branch, or flow under test. If empty, infer from the recent conversation (the last implementation, the current branch diff, the open file).

Why this exists

Type-check + unit tests prove code correctness. They don't prove feature correctness. Things that slip past them: wrong copy rendered, silent fallbacks, empty states that render blank, nav that routes to a 404, API-dependent flows that secretly 500, components that throw on first mount for new accounts. The only way to catch these is to actually use the app.

Phase 0 — Orient

Before touching the browser, spend one or two minutes figuring out the terrain. Do these in parallel where you can:

1. Read CLAUDE.md (project root) and any referenced brain/docs files for the dev command, test command, test-credentials path, and testing conventions.
2. Inspect package.json scripts — what's dev / test / typecheck? Which port?
3. Look for test-credentials notes — common paths: brain/local/test-credentials.md, docs/local/*, .env.local. If Clerk is in use, note the +clerk_test convention and the 424242 OTP.
4. Identify the flow — which routes, which state transitions, which edge cases. From the argument, the recent diff, or by asking.