# Definition of Done

Use this checklist for every Increment (Scrum's word for a small finished piece of the product). Add stricter lines for your project when you need them. Never remove a line quietly.

## Behavior

These checks tie your code to what the user can see, including errors and edge cases.

- [ ] The linked user story or bug has a done checklist (acceptance criteria) you can measure.
- [ ] Every item on that checklist is met, or clearly rejected with a reason.
- [ ] Error and edge-case behavior is decided on purpose, not left to chance.

## Quality

These checks ask whether someone can maintain the change, and whether automated tests protect what already works.

- [ ] You wrote real automated tests and ran the standard project commands.
- [ ] Existing tests still pass.
- [ ] The code is readable, focused, and has no known dead or duplicated code.
- [ ] You wrote down any known limit or work you put off.

## Security and privacy

These checks make safety part of "done" instead of a separate job left until release.

- [ ] No secret, password, personal path, private record, or real user data is present.
- [ ] Test and demo data is made-up, or clearly approved and cleaned of private details.
- [ ] You thought about input checking, permissions, and risky dependencies for this change.

## Delivery

These checks keep the trail clear: need, reviewed commit, shippable result, and a way to undo it.

- [ ] The Issue, branch, commits, pull request, tests, and CI proof are linked together.
- [ ] Required CI checks pass on the exact commit that was reviewed.
- [ ] The docs and run instructions match what the code really does.
- [ ] You can explain what changed, why it works, one tradeoff, and one likely way it could fail.
- [ ] The Increment is ready to release. If you released it, its version and rollback path are written down.

---

## About this template

The Definition of Done is the checklist a piece of work must pass before you call it finished. It is the same for every piece, so "done" means one thing.

> **What this teaches:** I can tell the difference between "the code runs for me" and a piece that is ready to release. Ready means someone else can check its behavior, quality, safety, and proof of shipping.

Before you start work, read every line and guess which one is most at risk. At the end, point to proof for each check. A ticked box with no proof is not done.

Use this text only where the week page tells you to put it. In Week 0 Task 3, paste it into the pinned private GitHub Issue named `Definition of Done`. Save the Issue, then reopen it to check that the checklist is there. Don't make an unnamed local copy.

**Explain it back:** Pick one line from each section. Explain what proof shows it is done, and what that proof does not show. Then say which line would stop a release if it failed.

**Delete this whole section once you have filled the document in.** What is left should read as a finished document on its own.