Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
The English summary is being prepared. Showing the original description.
Use when any case fails or you reject a criterion - what goes in the review_criterion note, the failed case and the numbered need_revision comment, with severity
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
A defect's evidence lives in three places, each with its own job — never duplicate the full report into all three:
| Place | Contents |
|---|---|
| Failed case | actual = the observed output, verbatim. evidence = exact command/flow plus frequency, e.g. "3/3". |
| Rejected criterion note | Expected (quote the criterion), actual, reproduction, environment: short SHA, URL/base, width or device, browser/runtime. |
| need_revision comment | A numbered index, one line per defect: 1. [AC2 · case "export rejects >10k rows"] 500 instead of 422 — S2. Keep it inside the 15-line comment budget (concise-board-comments) — the reproduction lives in the criterion note and case evidence, not here. |
A task fails when:
Anything else — taste, polish beyond the floor — is a note on the criterion, never a failure.
grep_code hit is fine (the named debugging exception); a proposed fix is not your job.❌ "Export broken" — no repro, no expected, no severity.
✅
Case: export-pagination-10k (failed, 3/3)
actual: HTTP 500, body {"error":"internal"}
evidence: curl -X GET "$BASE/api/export?limit=10001" -H "Authorization: Bearer $TOKEN" — ran 3x, same result
Criterion note (AC2, rejected):
Expected: "requests over the 10,000-row limit return 422 with a clear message" (AC2)
Actual: 500 with no message, see case export-pagination-10k
Repro: curl -X GET "$BASE/api/export?limit=10001" ...
Env: SHA a1b2c3d, http://localhost:5173, desktop 1440
need_revision comment:
1. [AC2 · case "export-pagination-10k"] 500 instead of 422 at limit+1 — S2
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
The English summary is being prepared. Showing the original description.
Use when the diff adds or changes an endpoint, resolver, RPC, job or query that takes an object id, a role check, a request binding or a tenant filter - BOLA/IDOR, function-level authorization, mass assignment and tenant scoping
The English summary is being prepared. Showing the original description.
Use on every UI change - semantic HTML, labels for controls, keyboard-navigable dialogs/menus, visible focus, and never color as the only signal
The English summary is being prepared. Showing the original description.
Use when a task changes any screen, form, dialog, menu or control - Lighthouse/axe scan of the changed screens, a keyboard walk, and the thresholds that fail a task
The English summary is being prepared. Showing the original description.
How to work a task returned with review, QA or UAT findings. Use when a task is in need_revision or PR review comments are in your context.
The English summary is being prepared. Showing the original description.
Use when the repository keeps its alerting in code, or a person asks for alerts outside TaskTrooper - PrometheusRule YAML, a Cloud Monitoring alert policy in Terraform, a Datadog monitor, each routed to TaskTrooper's alert ingest URL so it opens an incident here
The English summary is being prepared. Showing the original description.