QA on the diff, not on the repo

Don't test the repo. Test the diff.

Start by reading the output of `git diff [BASE]...[BRANCH]`. That diff is your entire scope. Don't open files that don't appear there, unless you need to confirm how something that did change is used.

For each file in the diff, deliver:
1. What changed, in one line.
2. The concrete risk that change introduces.
3. The minimum test that covers it: test name, input and expected output.
4. If a test that covers it already exists, tell me which one and don't write a new one.

Then, and only then:
5. List who calls the code that changed. That is where the collateral damage is, not in the edited file.
6. Run the tests and paste the real output. If something fails, show the exact error without summarizing it.

Rules:
- Coverage is not the goal. A test that fails when the bug shows up is worth more than ten that only pass.
- Don't write tests that prove the mock works.
- If a change can't be tested automatically, say so and explain how to verify it by hand.
- Don't claim it passes without having run anything. "Should pass" is not a result.