/super-qa

name: super-qa
description: >-
  Super QA canonical workflow for functional bug-bash, evidence capture, and fix-ready issue filing.
  Crawls routes from `docs/super-qa/queue.md` with Playwright, records screenshots/logs/HARs, files
  product-readable issues with clear type/priority/area labels, and continues until traversal is
  complete or only human-gated blockers remain. Crawling is always browser-driven, but the regression
  test it leaves behind is written at whichever layer the defect actually lives — unit or integration
  in Vitest, e2e in Playwright only when the browser is the thing that broke. Use when the user says
  "run super-qa", "QA review", "bug bash", "verify and fix", or invokes `/super-qa`.

**For a board worker, before writes or worktree creation:** follow [skill readiness](../super-board/references/skills-readiness.md). Resolve this lane for the actual host, load the report's files/fallbacks, halt on missing requirements and recheck each conditional helper before use.

super-qa — BFS Route-Crawler that Builds the Spec Suite

Auth bootstrap — auto-discover, never ask

Before iter 1, resolve a test login. **Never ask the user; discover or create.** Order:

1. **Cached creds** at `.claude/settings.local.json` `.e2e.user` / `.e2e.pass` — use them as-is. 2. **Env-file fallback** — read in order: `.env.production.local`, `.env.local`, `.env`. Pull `SUPABASE_URL` + `SUPABASE_SERVICE_ROLE_KEY`. If both present, auto-create `e2e-test@<owner-domain>` (owner from `git config user.email` domain, fallback `erictech.ca`) via:

   curl -sS -X POST "$SUPABASE_URL/auth/v1/admin/users" \
     -H "apikey: $SUPABASE_SERVICE_ROLE_KEY" \
     -H "Authorization: Bearer $SUPABASE_SERVICE_ROLE_KEY" \
     -H "Content-Type: application/json" \
     -d "{\"email\":\"$E2E_USER\",\"password\":\"$E2E_PASS\",\"email_confirm\":true,\"user_metadata\":{\"role\":\"e2e-test\",\"created_by\":\"super-qa-bootstrap\"}}"

Generate a 24-char random password (`openssl rand -base64 24 | tr -d '/+=' | cut -c1-24`). Save to `.claude/settings.local.json` `.e2e` so the next run skips bootstrap. Verify by logging in (`POST /auth/v1/token?grant_type=password` returns access_token). 3. **Unauth-only fallback** — if neither cached creds nor env-file admin key exist, log "no admin key — restricting to public routes" and proceed with `/login`, `/signup`, `/forgot-password` only. Do NOT halt.

The bootstrap is **non-interactive**. If the curl returns an existing-user error (`User already registered`), reset the password via the same admin endpoint and continue. Save creds either way.

QA loop state board — GitHub Project as the state store

State for the QA↔Build loop lives in a GitHub Project named **`Super Ultimate QA`** (auto-discovered by title at the user/org level). It has six Status columns:

| Column | Meaning | |----------|------------------------------------------------------| | Queue | Work the next iteration will pick up | | Testing | Feature currently being explored or verified | | Done | Spec passing, no action needed | | Bug | Failing spec; Super Build picks these up next | | Flaky | Only passes on retry; quarantine + investigate | | Skip | Out of scope; documented and parked |

This board is the durable, machine-readable state for the loop. `docs/super-qa/queue.md` remains the BFS route seed and audit log, but **all actionable findings land on the project board** so the build lane can pick them up without parsing markdown.

Project resolution

Resolution order (used by `scripts/super-qa-file-bug.sh` and the orchestrator):

1. If `SUPER_QA_PROJECT_TITLE` is set, query `gh project list --owner $SUPER_QA_PROJECT_OWNER --format json` and pick the project whose title matches (case-insensitive). 2. Otherwise default to title `Super Ultimate QA`. 3. Owner defaults to `$(gh repo view --json owner -q .owner.login)` or `SUPER_QA_PROJECT_OWNER` if set.

If no matching project exists, the loop halts with a one-line error and instructs the operator to create one. Do not silently fall back to the repo's primary project — column semantics differ.

Filing semantics

When the worker finds a red spec, it calls `scripts/super-qa-file-bug.sh`. The script:

• Creates the issue with `source:qa` label and full evidence body.
• Adds the issue to the resolved **Super Ultimate QA** project.
• Sets the Status field to `Bug` (override with `SUPER_QA_TARGET_OPTION_NAME`).

A `Flaky` retry-only finding goes to `Flaky`; out-of-scope routes go to `Skip`. The same issue may also live on a repo-level project for normal triage — Status on the QA project is the loop state; status elsewhere is independent.

Algorithm overview

You are the orchestrator. Your job: drive a BFS crawl of the target app that **builds `e2e/paths/` into a comprehensive Playwright suite** while fixing any bugs it stumbles on. Each iteration is a fresh worker — a sub-agent you launch in this session with the Agent tool — that does ONE iter and exits. There is no worktree: the worker commits directly to the active branch (default `main`). This pack ships no headless dispatcher for this loop.

Autonomous mode — NO AskUserQuestion mid-loop

`/super-qa` is invoked by an operator who walks away (often overnight). The loop must run end-to-end without the orchestrator pausing on `AskUserQuestion`.

**Decide-and-proceed, don't ask, on these classes of issue:**

• Harness script bugs (parser errors, broken xargs, missing

`chmod +x`, stale lock files). Fix locally, commit as `🐛 [fix] super-qa: <what>` (writing-standard.md § 1), then continue.

• Missing env auto-loads, leftover MCP zombies, log-dir creation.
• Lint / formatting nits introduced by the worker that block its own commit.
• Choosing between equivalent dispatch modes (sequential vs sequential —

parallel is unsafe, never p