code-reviewlisted

# Code review Review has three jobs, in order: **catch defects the author can't see**, **keep the codebase one system rather than many**, and **spread context**. Style policing is not on the list — a formatter does it better and without friction. Before you start, read the description and know what the change is *trying* to do. A review that misunderstands the intent produces confident, wrong feedback, and costs the author more than no review at all. ## Passes, in this order Reviewers who start at line 1 and comment as they go spend all their attention on naming and run out before the part that matters. ### 1. Is this the right change? Cheapest to fix now, most expensive later. Does it solve the stated problem? Is it in the right place? Does it duplicate something that exists? Is the scope right — one concern, or three tangled together? If the answer is "this shouldn't be built this way", say it immediately and stop reviewing details. Twenty line-level comments on code that needs restructuring is wasted work for both of you. ### 2. Correctness Where bugs actually live: - **Boundaries**: empty, one, many, max, past-max, negative, zero, null. - **Error paths**: every error is handled or deliberately propagated; nothing is swallowed; partial failure leaves a defined state. - **Concurrency**: shared mutable state, unsynchronized access, an operation assumed atomic that isn't, a goroutine or task nobody stops. - **Data**: migration safety, backfill, whether old and n