code-reviewlisted

# Code Review ## Iron Law `FINDINGS FIRST. BLOCK ON CORRECTNESS, SAFETY, DATA LOSS, AND UNPROVEN CLAIMS.` ## When to Use - Independent review of your diff in the `workflow` completion loop, after `proof` and before claiming done. Default for any non-trivial agent-generated change; use a fresh-context subagent, review agent, or separate session when the host provides one. - Diff review: local, branch, or a GitHub PR through the host's GitHub surface. - Review-comment follow-up on the user's own PRs. ## When NOT to Use - Commit grouping or history repair only; use `git-workflow`. - A narrow domain-only review where `security`, `database`, `api`, or `ui-design` is sufficient. ## Rules 1. Review owns defect discovery; `proof` owns checks. Find behavioral bugs, regressions, unsafe edge cases, missing evidence, and merge blockers. 2. Findings come first, in severity order, each with a file/line or thread anchor, the issue, its impact, a fix direction, and the evidence or missing proof. Summaries come after. Use a question only when ambiguity blocks the finding. | Severity | When to use | |---|---| | Critical | Exploitable security, data loss, broken auth, destructive migration, outage risk | | High | Incorrect behavior, broken contract, missing authorization, race, serious regression | | Medium | Maintainability, error handling, observability, compatibility, or test gaps likely to cause defects | | Low | Non-blocking clarity, skip unle