/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.