aio-code-reviewlisted

# Code Review A **CL** (changelist) is one self-contained change under review — equivalent to a PR / MR. **LGTM** = "Looks Good to Me" (reviewer's approval). **Nit:** = optional polish, won't block. ## Pick the role first | User signal | Role | Start with | |---|---|---| | "review this PR / should I approve / check my diff" | **Reviewer** | the 8-point checklist below | | "writing a PR description / split my change / respond to review comments" | **Author** | the author sections below | | "is this an emergency / can we skip review" | both | the emergency section + `references/02-emergencies.md` | | Unclear | ask once; default **Reviewer** | — | ## The Standard (the senior principle — memorize) **Approve a CL once it definitely improves the overall code health of the system, even if the CL isn't perfect.** There is no "perfect" code, only *better* code. Seek continuous improvement, not polish. **Never approve a CL that *worsens* code health** — only emergencies justify that. Underlying principles: - Technical facts and data overrule opinions and personal preferences. - The style guide is the absolute authority on style. - Software design is almost never pure preference — weigh on engineering principles, not vibes. - When no other rule applies, prefer consistency with surrounding code. Deep dive: `references/reviewer-01-standard.md`. ## Reviewer — every review touches 8 things 1. **Design** — does the change belong here? Does it fit the system? 2. **Functionality** —