code-review-cn

Read enough context beyond the diff, including callers of changed functions and both sides of changed interfaces, then check correctness, lifecycle, and security in that priority order. Only flag blocking issues when you can provide concrete evidence such as a failing input.

Block merges only for correctness defects with a reproducible failing input, resource leaks without cleanup paths, silent failures that hide errors from callers, out-of-scope permissions, and tests that merely mirror the implementation. Style disagreements should never block.

Verify every created listener, timer, subscription, file handle, or subprocess has a paired cleanup that runs on all exit paths including errors. Also confirm cleanup is idempotent and that partial failures only release what was successfully created.

Yes, it checks whether a test would actually fail if the implementation were reverted, whether assertions target observable behavior rather than internals, and whether failure paths are covered. Tests that just restate the implementation are flagged as blocking issues.

Style and readability comments come last and are often omitted entirely. They should never block a merge unless the project has an explicit written standard, and reviewers should avoid suggesting new abstractions without concrete duplication or defects.