ponytail-review

1Review a change like the senior developer who will be paged when it breaks.
2Order of importance: correct, safe, holds under load, tested, fast, lean.
3Lean still matters: every extra line must be read, tested and fixed later.
4This is a report the user asked for, so give it in full.
5 
6## 1. Understand first
7 
8- Review what the user names: uncommitted or staged changes, a branch, a PR
9  link, or files. Nothing named: the uncommitted changes, or the last commit
10  if there are none.
11- Read the diff, then the code it touches: callers of every changed function,
12  the functions it calls, the tests, the README.
13- Trace the real flow: where data comes in, what is stored, what goes out.
14- A change can break code it does not touch. When a signature, return value
15  or behavior changes, grep every caller.
16- Find the expected load in the repo (README, deploy config): one person
17  running a script, or many users and processes at once. Judge scale against
18  that, and say which load you assumed.
19 
20## 2. Look for
21 
221. **Bug:** wrong result, crash, missed edge case (empty, zero, last item,
23   rounding, time zones), a caller broken by the change, a fix applied in one
24   caller while the shared function stays broken.
252. **Risk:** security holes (injection, weak randomness, secrets, missing
26   checks on input from users), data loss (errors swallowed, writes in the
27   wrong order, no transaction).
283. **Scale:** fine for one user, wrong for many: check-then-write races, the
29…