code-review-and-quality

Review a pull request by first understanding its intent, then checking tests, then walking the implementation across five axes: correctness, readability, architecture, security, and performance. Label every finding with a severity such as Critical, Required, Nit, or Optional so the author knows what must change before merge.

A code review checklist should cover correctness against the spec, edge case and error handling, test adequacy, naming and readability, architectural fit, input validation and injection risks, and performance issues like N+1 queries. It should end with a verification step confirming tests pass and the build succeeds.

A pull request of around 100 changed lines is ideal and reviewable in one sitting, while roughly 300 lines is acceptable for a single logical change. Changes approaching 1000 lines should be split using stacking, file-group, horizontal, or vertical splitting strategies.

Request changes when there are unresolved Critical or Required findings such as security vulnerabilities, broken functionality, missing regression tests, or structural regressions. Approve when the change clearly improves overall code health, even if it is not perfect.

Review dependency upgrades by reading the changelog rather than trusting semver, upgrading one dependency per change, and verifying with a green test suite before and after. Also review the lockfile diff since a single direct bump can pull in many transitive changes.