Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Use when a criterion mentions speed or limits, or the change touches a list, query, endpoint or page that could get slower - timing loops, the N-vs-10N data check and Lighthouse on a production build
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
설치 방법 보기설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
Not full load testing — a smoke check run locally, never against stage or prod.
for i in $(seq 20); do curl -s -o /dev/null -w '%{time_total}\n' "$BASE/api/tasks?limit=50"; done | sort -n | awk '{a[NR]=$1} END{print "p50="a[int(NR*.5)]" p95="a[int(NR*.95)]" max="a[NR]}'
Then run the same with 10x the seeded rows. p95 growing more than 3x for 10x the data is an N+1 suspicion — report it with the two numbers. Fail bar: p95 >1s for a simple read on localhost, or any number a criterion states explicitly. 0.5-1s is a note, not a fail.
Only when the change implies it (a shared resource, a write path under contention):
npx -y autocannon -c 10 -d 10 <url>
Errors must be 0.
Measure a production build, never a dev server — dev builds are unoptimized and that is where false fails come from:
npm run build && (nohup npx vite preview --port 4173 > "$QA/preview.log" 2>&1 &)
CHROME_PATH="$CHROME_BIN" npx -y lighthouse@13 http://localhost:4173/<page> --only-categories=performance --form-factor=mobile --screenEmulation.width=360 --chrome-flags="--headless=new" --output=json --output-path="$QA/lh-perf.json"
Report LCP/CLS/TBT against "good": LCP ≤2.5s, CLS ≤0.1, TBT ≤200ms. Fail only for a criterion's own number or a CLS shift you can see on a changed screen; other misses are notes, not fails.
Load-test stage or prod. Use k6 only when the repo already ships k6 scripts — not as the default tool.
Record cases as category: other with a title prefix perf: — the category enum has no performance value of its own.
아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
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
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Use on every UI change - semantic HTML, labels for controls, keyboard-navigable dialogs/menus, visible focus, and never color as the only signal
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
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
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
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.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
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
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.