給 AI agent 的「完成定義」自我把關 spec：讓它交件前先驗收自己

Before you report this task as done, you MUST self-verify against the Definition of Done below. Treat "done" as a claim you have to prove, not a feeling. If you cannot satisfy a check, do NOT silently skip it — state exactly which check failed and why.

## The task
{{TASK_DESCRIPTION}}

## Acceptance criteria (the change is correct only if ALL hold)
{{ACCEPTANCE_CRITERIA}}

## Out of scope — do NOT touch
{{OUT_OF_SCOPE}}

## Definition of Done checklist — go through every item and mark ✅ / ❌ with evidence
1. **Behavior** — The change satisfies every acceptance criterion above. For each criterion, say in one line how the code now satisfies it.
2. **Scope discipline** — You touched only what was needed; nothing in the out-of-scope list changed. List the files you modified and confirm none are out of scope.
3. **Tests** — Run the project's test command (`{{TEST_COMMAND}}`). Paste the real, unedited result (pass/fail counts). If you could not run it, say so explicitly and why — never claim it passed without running it.
4. **Lint / typecheck / build** — Run `{{QUALITY_COMMANDS}}`. Paste the actual output. Any new error you introduced must be fixed, not suppressed.
5. **New coverage** — If you added or changed behavior, you added or updated at least one test that would FAIL on the old code and PASS on the new code. Name it. If you intentionally didn't, justify it.
6. **Edge cases** — List the edge / error cases relevant to this change (empty input, null, concurrency, failure path, etc.) and confirm each is handled or explicitly out of scope.
7. **Conventions** — The new code matches existing patterns, naming, and error-handling style in the surrounding files (don't invent a new style).
8. **Rollback / risk** — If this change is risky (touches data, auth, money, migrations, shared infra), describe how to revert it (single commit? feature flag?). If low-risk, say so.
9. **No placeholders** — Confirm there are no `TODO`, `pass`, `...`, stubbed functions, or commented-out "will do later" left in the diff.

## Final output — the verification story
End with a short paragraph a human reviewer can read in 30 seconds: what you changed, why it's correct, what you ran to prove it, and any check that is ❌ with the honest reason. Do not say "done" anywhere unless items 1–9 are all ✅ or have a stated, accepted reason.

Before you report this task as done, you MUST self-verify against the Definition of Done below. Treat "done" as a claim you have to prove, not a feeling. If you cannot satisfy a check, do NOT silently skip it — state exactly which check failed and why.

## The task
{{TASK_DESCRIPTION}}

## Acceptance criteria (the change is correct only if ALL hold)
{{ACCEPTANCE_CRITERIA}}

## Out of scope — do NOT touch
{{OUT_OF_SCOPE}}

## Definition of Done checklist — go through every item and mark ✅ / ❌ with evidence
1. **Behavior** — The change satisfies every acceptance criterion above. For each criterion, say in one line how the code now satisfies it.
2. **Scope discipline** — You touched only what was needed; nothing in the out-of-scope list changed. List the files you modified and confirm none are out of scope.
3. **Tests** — Run the project's test command (`{{TEST_COMMAND}}`). Paste the real, unedited result (pass/fail counts). If you could not run it, say so explicitly and why — never claim it passed without running it.
4. **Lint / typecheck / build** — Run `{{QUALITY_COMMANDS}}`. Paste the actual output. Any new error you introduced must be fixed, not suppressed.
5. **New coverage** — If you added or changed behavior, you added or updated at least one test that would FAIL on the old code and PASS on the new code. Name it. If you intentionally didn't, justify it.
6. **Edge cases** — List the edge / error cases relevant to this change (empty input, null, concurrency, failure path, etc.) and confirm each is handled or explicitly out of scope.
7. **Conventions** — The new code matches existing patterns, naming, and error-handling style in the surrounding files (don't invent a new style).
8. **Rollback / risk** — If this change is risky (touches data, auth, money, migrations, shared infra), describe how to revert it (single commit? feature flag?). If low-risk, say so.
9. **No placeholders** — Confirm there are no `TODO`, `pass`, `...`, stubbed functions, or commented-out "will do later" left in the diff.

## Final output — the verification story
End with a short paragraph a human reviewer can read in 30 seconds: what you changed, why it's correct, what you ran to prove it, and any check that is ❌ with the honest reason. Do not say "done" anywhere unless items 1–9 are all ✅ or have a stated, accepted reason.