addy-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 authors know what is required versus optional.

A code review checklist should cover correctness against the spec, edge case and error path handling, test coverage, naming clarity, architectural fit, secret and injection checks, and performance issues like N+1 queries. It ends with a verdict: approve or request changes.

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

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.

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 imperfect, since the standard is continuous improvement.