Use when a case needs data, a user/role, or a third-party dependency - seeding through the product first, test credentials, namespacing on shared environments, and stubbing an external HTTP service by hand
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
make seed, npm run db:seed, prisma db seed — find it via get_project_brief or the README).Record the seed commands you ran in the case's evidence.
The repo's docker-compose service (docker compose up -d db returns), else its documented local DB. No container runtime available → say so as a blocker (qa-verify-before-verdict's triage table), don't improvise a different engine — a SQLite stand-in for Postgres hides real dialect bugs.
Pull from .env.example or the repo's own seed fixtures. Never a real person's account. A third-party sandbox key you don't have is a human blocker (ask_user), not something to work around.
On stage: prefix everything you create with qa-<task-key>-…, clean it up when you're done, never run a destructive scenario there.
docker run -d --rm -p 8089:8080 wiremock/wiremock:3.13.2
curl -X POST localhost:8089/__admin/mappings -d '{"request":{"method":"POST","url":"/charge"},"response":{"status":402,"jsonBody":{"error":"declined"}}}'
# point the app's dependency URL env var at http://localhost:8089, drive the scenario, then:
curl -s localhost:8089/__admin/requests | jq '.requests[].request.url' # no jq: node -e 'let d="";process.stdin.on("data",c=>d+=c).on("end",()=>JSON.parse(d).requests.forEach(r=>console.log(r.request.url)))'
Or use the repo's own mock server if it already has one — prefer that over standing up a second one.
Save a working boot+seed recipe to project memory (save_memory, scope=project) once it cost you real effort — the next QA round on this repo should not rediscover it.
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.