# Pull request

> **What this teaches:** I can present one reviewable change by connecting user need, implementation, tests, CI, risk, and recovery.

Before opening the pull request, predict the question or failure a reviewer is most likely to find. Do not use a green CI badge as a substitute for explaining what was tested.

## Linked work

This provides traceability from the change back to the agreed need or defect.

Closes **[Issue URL or number]**

## What changed

Describe observable behavior and delivery effects rather than listing filenames alone.

- [Behavioral change]
- [Test or delivery change]

## Why

Connect the change to acceptance criteria so a reviewer can judge relevance and scope.

[Connect the implementation to the user need and acceptance criteria.]

## How you verified it

Record the exact check and observed result. Different checks answer different questions; “tests passed” is not enough detail.

| Check | Command or run | Result |
|---|---|---|
| Unit/integration tests | | |
| Static checks | | |
| Build | | |
| Manual acceptance check | | |

## Risks and rollback

Reason about how the change could fail and how to return safely to the prior known state.

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

## Evidence

Use these as review gates, not ceremonial boxes.

- [ ] Acceptance criteria are mapped to tests or demonstration evidence.
- [ ] Required CI checks pass on this head commit.
- [ ] No secret, personal data, private course record, or copied solution is included.
- [ ] I can explain this change without reading the implementation line by line.

## Explain it back

In two minutes, explain the need, changed behavior, strongest evidence, main remaining risk, and rollback path.