QA Find Bugs Dashboard

Dashboard QA bug hunt

Read the shared QA contract first. Read dashboard/AGENTS.md. Use Playwright MCP to test real browser behavior.

Arguments: optional server URL, journey names, wN, SHIP=1, DRY_RUN=1. Default to production and report mode. A target URL changes the client under test; inspect its API origin independently. Record whether the running client matches local HEAD before declaring a source fix missing from production.

Run in the background

• Default to a headless browser with an isolated QA profile. Keep the user's windows, tabs, mouse, keyboard, and system clipboard undisturbed. A fresh context inside a headed browser can still open a visible window; it does not satisfy this requirement.
• Launch Playwright MCP with --headless --isolated. For Claude Code, check mcpServers.playwright.args in the repo's .mcp.json; for Codex, check the active [mcp_servers.playwright] configuration, normally in ~/.codex/config.toml. Inspect effective launch settings, including overrides and any attached-browser endpoint, before the first browser action. A config edit takes effect on a new MCP server/browser session, not an already-running headed session. Do not attach to the user's regular browser.
• If the current MCP session is headed, establish a separate headless session before continuing UI checks. An already available Playwright runtime in a QA-owned process is an acceptable fallback when MCP cannot be restarted safely. Preserve the same login and evidence workflow. If no background session is available, report the UI checks as blocked and continue independent source/API investigation; do not silently launch a visible browser or stop another task's browser server.
• Use Playwright's page/context APIs for clicks, typing, keyboard navigation, focus assertions, viewport changes, screenshots, and downloads. Do not call bringToFront, activate desktop apps, drive the OS mouse/keyboard, or open downloaded artifacts in desktop viewers. Browser-local focus checks remain part of accessibility QA.
• For uploads, use file inputs/file-chooser APIs with authorized fixtures. For print checks, inspect print media or a headless PDF where supported; this does not verify the native print dialog. Run visible-browser, native-dialog, or actual screen-reader checks only when explicitly requested. Otherwise record that coverage as unverified and continue the background journeys.
• Record the browser mode and session ownership with the run evidence. Reuse the owned headless browser with fresh contexts as needed, and close only this run's contexts, browsers, and helper processes during cleanup.

Prepare the browser

• Record the initial browser session. Authenticate using QA_EMAIL and QA_PASSWORD from dashboard/.env, unless the user supplies another path. From the repo root, run node .agents/skills/qa-shared/scripts/qa-login.mjs --env-file dashboard/.env. The helper hides the password and transfers session cookies in memory. Inspect features/auth/hooks/use-login-form.ts, graphql/query/auth.graphql, and the backend auth resolver/cookie helper for the current contract. Verify the resulting account and role, not merely a 200.
• Use an ordinary desktop viewport (for example 1440×1000), then repeat the relevant controls at a narrow viewport. Record locale, theme, and active filters. Prefer accessible roles and names from snapshots to brittle selectors.
• If the account is unavailable, continue public-ledger and signed-out journeys and explicitly leave authenticated behavior unverified.
• For local reproduction, install existing dependencies with yarn install --immutable inside dashboard/; start yarn dev. Never assume the local server uses a sandbox backend. Existing scripts/perf-fixture-api.mjs can isolate loading behavior, but results against its synthetic owner/fixtures must be labeled local simulations.