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 by severity so the author knows what blocks merge.

A code review checklist should cover correctness against the spec, edge case and error handling, clear naming, architectural fit, input validation and secret hygiene, N+1 queries and unbounded operations, and verification that tests and builds pass.

A pull request around 100 changed lines is reviewable in one sitting, 300 lines is acceptable for a single logical change, and 1000 lines should be split. Split large changes by stacking, file groups, horizontal layers, or vertical feature slices.

AI-generated code needs more scrutiny, not less, because it is confident and plausible even when wrong. Apply the same five-axis review, verify tests actually test behavior, and never rubber-stamp with an unexamined approval.

Upgrade dependencies one package per change, read the changelog rather than trusting semver, verify with a green test suite before and after, and review the lockfile diff since a single bump can pull in many transitive changes.

Request changes when Critical issues exist, such as security vulnerabilities, data loss, or broken functionality, or when required findings are unresolved. Approve when the change improves overall code health even if it is not perfect.