Definition of Done

The per-task / per-PR engineering checklist. It exists in two forms that must agree:

• This document is the canonical, human-readable list — the order of steps a developer should expect to do.
• Each task carries it. /breakdown renders this checklist into the body of every GitHub Issue it creates, so the steps are visible in the task itself — not hidden inside a skill or an agent the developer never opens.
• process-guardian enforces it. That agent is the executable form, with the exact validator command for each item; it blocks closure when any required item is unverifiable.

Why the steps live in the task

A checklist buried in a skill is a checklist nobody reads. The process steps — especially the ones that are easy to forget at the end of development, like saving the endpoint in Postman — belong in the task, in order, so any human (or the next AI session) can see what is left to do without reverse-engineering the workflow. This page is the source; the task is where it is consumed.

The feature-level DoD vs. this task-level DoD

This is the task / PR checklist (one PR's worth of work). The feature-level DoD — all P0 acceptance criteria pass, PM sign-off, all states match the prototype — lives in Design Doc §16 and is checked once across the whole feature. A feature is Done only when every task is Done and the feature-level DoD passes.

The checklist (ordered)

Run top to bottom; cheap/local checks first. Each item is REQUIRED, WAIVABLE (with a written reason on the ClickUp task), or NON-WAIVABLE.

1. Traceability

• REQUIRED — PR title ends with a valid CU-id as the trailing token (bare … CU-86c9v71z4 is the convention, uniform with the branch suffix _CU-<id>; [CU-<id>] also accepted); branch + commits match the convention; PR body links the ClickUp task.

2. Code-quality gates

• REQUIRED — the repo's lint / typecheck / test / build (Node) or composer test + PHPCS (PHP) all exit 0. Run /verify.

3. Tests are real

• REQUIRED — new behavioral code has matching tests, or the PR body states "no tests because:" with a one-sentence rationale. E2E consulted where the surface warrants it.

4. API endpoints saved in Postman

• REQUIRED for any added/changed HTTP endpoint — the endpoint is saved in the organization R&D Postman workspace collection with a sample request and a sample (saved) response example. The collection runner / newman is green; its output is a verdict, same standing as test. Use the postman-endpoint skill for the procedure. Never commit or paste API keys / OAuth secrets — use the Postman Vault / environment.

  Internal @MessagePattern RPCs have no HTTP surface to save in Postman — note "RPC, no Postman entry" instead, and lean on the contract test (contracts-schema).

5. Security & data

• NON-WAIVABLE — no secrets in the diff; no destructive operations against shared databases without a Hard-Floor approval.

6. Contracts & docs

• REQUIRED IF APPLICABLE — a changed FE↔BE / RPC contract updated its consumers (contracts-schema); docs/changelog updated where relevant.

7. Design-review bridge

• REQUIRED IF APPLICABLE — if a design tracking Issue exists, the PR references it and summarizes how its comments were addressed.

8. Review readiness

• REQUIRED — PR is draft by default; marked ready-for-review only when the human asked. Run /pr-review before requesting review.

9. State sync

• REQUIRED — the task's "AI Context" block has a final entry (what shipped, PR number, follow-ups), flushed to both trackers by state-sync.

10. Deploy bridge (at close)

• REQUIRED — the deploy succeeded for the target environment and the (vendor-neutral) observability stack is clean for the post-deploy window. Then /done moves the ClickUp status to Done.

See also

• process-guardian — the executable enforcer (per-item validators).
• /breakdown — renders this checklist into each GitHub Issue.
• /done — the gate that runs the checklist at closure.
• Design Doc §16 — the feature-level DoD.
• postman-endpoint skill — how to save an endpoint with a sample request + response.