Adversarial Qa

---
name: adversarial-qa
description: >
  Exploratory, adversarial QA: exercise a feature through whichever surface(s)
  it exposes — UI, API, or both — and surface issues the plan and committed
  tests did not anticipate — not a re-verification of the spec. Invoked as
  /adversarial-qa for an ad-hoc session, or applied by the adversarial-qa
  sub-agent in the /feature workflow.
---

# /adversarial-qa — Exploratory QA

Exercise a feature in the running app and surface anything that looks wrong,
confusing, or likely to bite a real user. This is exploratory and adversarial,
not a re-verification of the spec — committed end-to-end tests encode the plan's
Requirements deterministically. Your job is to go beyond them.

If a plan was provided (inline or by path), read the Requirements section only
to understand what the feature does — not as a checklist to tick through.

---

## What to do

1. Determine the surface(s). From the plan's Requirements (or the diff, if no
   plan was given), decide whether the feature exposes a **UI** (templates,
   views, a controller path that renders a view/fragment/client-driven
   response), an **API** (a REST or other network-callable endpoint with no
   view layer), or both. Probe every surface the feature exposes — findings
   from one do not substitute for checking another.

2. Set up and drive the feature, per surface identified in step 1.

   - **UI surface** — start the local dev server with the project's dev-server
     command and drive the feature at the documented app URL (both in
     `AGENTS.md` → *Commands*) in a browser via the Playwright MCP. When you
     are done, stop it with the documented stop command — never `kill` by PID
     or hunt processes with `lsof`. If the server will not start or Playwright
     is unavailable, STOP and report the blocker. Do not substitute `curl`,
     SQL, or any other workaround for browser exploration on a UI surface —
     those answer different questions than what a real user experiences.

     For mechanical setup with a known, fixed sequence — logging in,
     navigating through boilerplate screens to reach the feature under test —
     batch the steps into one `browser_run_code_unsafe` call instead of a
     click/type/snapshot round trip per step; each round trip returns a full
     accessibility snapshot, which adds up fast. Reserve the granular tools
     (`browser_click`, `browser_snapshot`, etc.) for the actual exploration in
     step 3, where you need to see state after each action to decide the next
     one.

   - **API surface** — start the server the same documented way and issue
     requests against the same app URL (`AGENTS.md` → *Commands*) with `curl`
     via `Bash`. Stop the server the same documented way when done. If the
     server will not start, or a request needs credentials you don't have,
     STOP and report the blocker.

3. Probe beyond the happy path. Try things the planner likely did not
   enumerate, per surface:

   - **UI** — narrow viewports, keyboard-only navigation, browser back button,
     multiple tabs on the same form, paste of weird/long/XSS content,
     reloading mid-edit, error-toast timing, interactions with unrelated UI on
     the same page, stale state after a failed submit.

   - **API** — malformed, missing, or extra fields; wrong `Content-Type`;
     auth/authz boundaries (missing token, expired token, wrong role or
     tenant); idempotency and duplicate submission; pagination and limit edge
     cases; concurrent or racing requests; oversized payloads and
     unicode/injection strings in fields; status-code and error-envelope
     correctness; rate limiting.

4. Surface anything that looks off — even if it is not part of this feature's
   plan. Do not act "smart" by working around issues, inferring intent, or
   deciding a bug is "probably expected". Report it and let the developer
   decide.

5. Before writing the report, list the known deferred issues with
   `gh issue list --label known-issue --state open` and compare them against
   what you found. A finding that matches an open `known-issue` goes in the
   *Known issues* section of the report (cite the issue number), NOT in
   Findings — the developer has already triaged it once and should not have
   to re-triage it on every QA pass. If the observed behaviour is worse than
   or different from what the issue describes, that difference IS a finding.

---

## Evidence

Only capture evidence once you've decided something is a finding worth
reporting — never while just looking around.

- **UI** — `browser_take_screenshot` returns an image, which costs
  meaningfully more than the text snapshots from `browser_snapshot`, so
  screenshotting every step of the exploration adds up quickly for no
  benefit. Take one only once a finding is confirmed.
- **API** — capture the request and response that shows the problem: method,
  URL, relevant headers, status code, and body.

Save each finding's evidence under `.qa-evidence/` at the repo root
(gitignored); every finding in the report MUST cite at least one evidence
file there, with a one-sentence description of what it shows.

---

## Output Format

```
### Findings
- [Short description] — [evidence path] — [severity: bug / concern / nit]

### Known issues (already deferred — no action needed)
- [#issue-number] [title] — [still present / not observed on this pass]

### Blockers (if any)
[Anything that prevented you from exploring — server won't start, Playwright
unavailable, credentials needed, etc.]
```

An empty `Findings` section is a valid output if you genuinely probed the
feature and found nothing worth flagging. An empty output because you "ran out
of ideas" is not.