# Pull request

## Linked work

This links the change back to the agreed need or bug.

Closes **[Issue URL or number]**

## What changed

Describe what the user can now see and what changed about shipping. Don't just list filenames.

- [Behavior change]
- [Test or shipping change]

## Why

Tie the change to the done checklist (acceptance criteria). Then a reviewer can judge whether it fits and stays in scope.

[Tie the code to the user need and the done checklist.]

## How you checked it

Write the exact check and what you saw. Different checks answer different questions. "Tests passed" is not enough detail.

| Check | Command or run | Result |
|---|---|---|
| Unit/integration tests | | |
| Static checks (tools that read the code without running it) | | |
| Build | | |
| Manual check against the done checklist | | |

## Risks and rollback

Think about how the change could fail and how to get back safely to the last known-good state.

- Likely failure case:
- Security/privacy consideration:
- Compatibility or migration concern:
- Rollback or safe-recovery path:

## Proof

Use these as gates for the review, not boxes to tick for show.

- [ ] Each done-checklist item maps to a test or a demo you saved.
- [ ] Required CI checks pass on the latest commit in this pull request.
- [ ] No secret, personal data, private course record, or copied solution is included.
- [ ] I can explain this change without reading the code line by line.

---

## About this template

A pull request asks to merge your branch so someone can review it first. The description should let a reviewer judge the change without reading every line.

> **What this teaches:** I can present one change for review. I link the user need, the code, the tests, CI, the risk, and the way back.

Before you open the pull request, guess the question or failure a reviewer is most likely to find. Don't use a green CI badge instead of explaining what you tested.

Paste this template into the pull request description for the Issue and branch named by the current block. Click GitHub's create button, reopen the pull request, and check that the description and links are there. Don't put private course notes in the project pull request.

**Explain it back:** In two minutes, explain the need and the changed behavior. Then give your strongest proof, the main remaining risk, and the rollback path.

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