self-reviewlisted

# Self Review The author's context is a blindfold: you know what the code is supposed to do, so that is what you see. Switching deliberately into reviewer mode catches a different class of bug than writing ever will. You wrote it fast; now read it slow. ## Process Pull up the FULL actual diff (`git diff`, or a diff of every changed file), not your memory of what you changed. Memory is flattering. Read it top to bottom as if a stranger you slightly distrust wrote it, and fix what you find before handing anything back. ## The checklist **Correctness.** Does each hunk do what the task asked, and only that? Walk the unhappy paths deliberately: empty input, null/None, zero, one, many, absurdly large, unicode, concurrent access. Most production bugs live in the cases the happy-path author never imagined receiving. **Leftovers.** Debug prints and temporary logging. Commented-out code. TODOs you meant to resolve this session. Unused imports. Dead branches. Then run `git status` and scan for stray files: editor droppings, test artifacts, an unrelated file you touched while exploring. **Error handling.** Failures should surface, not vanish. No bare catch-and-ignore. Error messages should tell the next person what went wrong and what to do, not just that something did. **Security sweep (changed lines only).** Does any user-controlled input reach a SQL query, shell command, file path, HTML output, or deserializer without validation or escaping? Any hardcoded secret, token, key, o