code-review-and-quality

Review the changed lines plus surrounding context across five axes: correctness, readability, architecture, security, and performance. Run linters and tests as evidence, label findings by severity, and conclude with an approve or request-changes verdict.

A thorough checklist covers correctness (edge cases, error paths), readability (naming, control flow), architecture (coupling, patterns), security (input validation, secrets), and performance (algorithmic complexity, memory). Each axis should have concrete questions to answer.

Identify the root document containing \documentclass that includes the modified files, then compile with latexmk -pdf -interaction=nonstopmode -halt-on-error. A non-zero exit is a blocking failure; warnings like overfull boxes are non-blocking.

Request changes when critical or important findings exist, such as failing tests, security issues, or correctness bugs. Approve when the change definitely improves overall code health, even if it is not perfect.

If latexmk or pdflatex is unavailable, the review must explicitly state that compilation is unverified in the summary. Never claim a document compiles without empirical build logs.