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.
• Write journeys (journal edits, New Entry, Open Account, budgets, file
  create/edit/upload/delete, CSV import) run on the QA account's designated
  disposable ledger under the contract's standing write authorization:
  snapshot first, prefix and record each write, restore byte-for-byte at the
  end. Everything outside that authorization still needs the user's go-ahead.
• 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.

Sweep whole journeys

Use selected journey names to narrow this table; otherwise survey the available
surfaces and deepen the journeys that show failures. Report each skipped group.

After a surprising state, capture the screenshot, console errors, request status,
and operation response (sanitized). Use page.evaluate with fetch for an
authenticated API control when appropriate, returning only relevant non-secret
fields. Do not export an unfiltered HAR containing login bodies or cookies.
Reproduce once from a fresh page load before retaining a finding.

Research map

• Thin route wrappers: dashboard/src/routes/; implementation:
  dashboard/src/features/<feature>/.
• Cross-feature infrastructure: dashboard/src/common/, particularly Apollo
  links, auth, filters, navigation and ledger layout.
• Report behavior and exports: features/reports/AGENTS.md; importer and
  ledger-data have their own nested guides. ADRs are in docs/adrs/.
• Shared server causes: read backend-cluster/backend-v2/AGENTS.md before tracing
  src/features/<domain>/api, services, schemas, and ledger adapters. Read the
  ledger package guide if the response originates there. Keep fixes assigned to
  the package that owns the defect; do not create cross-package imports.

Apply the contract's reproduce → research → dedupe → report/optional filing
steps. Finding a bug does not require changing product code or adding a test that
merely repeats the implementation. If the user also requests a fix, reproduce it
with a meaningful regression check and run the owning package's normal gates.