code-reviewlisted

# Code Review Review a change for correctness first, quality second. A review is not a formatting pass — it's a search for the ways this diff is wrong or will become wrong. Approve when you'd be comfortable being paged for it at 3am. ## Scope the review before reading line-by-line Don't review the diff in isolation. A diff shows what changed, not whether the change is correct. 1. **Read the description / linked issue.** What is this change *claiming* to do? You're verifying the claim, not just the syntax. 2. **Read the surrounding code, not just the red/green lines.** A removed null check looks fine in the diff; whether it's a bug depends on the caller three functions up. Open the files. 3. **Reproduce the claim mentally (or actually).** Trace one real input through the new path. If the PR says "fixes the retry loop," follow a failing request through the loop and confirm it now terminates. If you can run it, run it. 4. **Check the tests changed with the code.** New behavior with no new test is a finding. A test that passes against *both* the old and new code tests nothing. ## What to actually look for Go in this order — correctness bugs are worth more than style nits. | Category | Concretely | | --- | --- | | **Logic bugs** | Off-by-one, inverted conditions, wrong operator (`&&` vs `\|\|`), `=` vs `==`, swapped args, fallthrough. | | **Edge cases** | Empty list/string, zero, negative, `null`/`None`/`undefined`, single element, max size, duplicate keys, u