jungho-git/review

Review

• Shared examples and formatting reference: references/EXAMPLE.md.
• Keep new guidance, snippets, and edits aligned with that file.

Scope

Use this rule when:

• the user asks for a review
• verifying a change before handoff
• performing a post-implementation correctness pass

Review should prioritize real bugs, regressions, commit issues, expected failure points, and missing coupled changes before optional commentary.

Review Order

• correctness bugs
• regression risks
• commit-related issues
• expected failure points
• missing coupled files or callers
• practical fix suggestions
• practical maintainability concerns
• optional improvements

Review Context

• Review the changed code in context, not the changed lines alone.
• Trace the full flow that can reach the change: entry points, callers, services, adapters, persistence, external APIs, jobs, events, and error paths.
• Include project relationships that affect correctness: module boundaries, shared contracts, generated code, configuration, deployment assumptions, feature flags, and backward compatibility.
• When data persistence is involved, inspect table relationships, DDL, migrations, constraints, indexes, nullable columns, default values, triggers, seed data, and relevant query plans when available.
• When the current project does not contain enough context, inspect related projects, sibling repositories, shared libraries, API providers, consumers, database repositories, migration repositories, or deployment repositories when they are locally available or explicitly provided.
• State which related projects or schema sources were inspected, and state when they were not available.

Practical Rules

• Do not label something a bug without a plausible failure path.
• Separate confirmed findings from likely risks.
• Keep optional suggestions clearly optional.
• Prefer concrete file, commit, schema, table, API, or contract references over vague discomfort.
• Identify commit-related problems when relevant: incomplete commits, missing generated artifacts, omitted migrations, stale lockfiles, unrelated churn, split changes that must ship together, and history that hides a required dependency.
• Identify expected failure points before proposing fixes: null or empty input, transaction boundaries, concurrency, retries, idempotency, permission checks, timezone or encoding differences, partial deployment, rollback, and data migration edge cases.
• Include a practical fix suggestion for each actionable finding when the likely fix is clear.
• Flag excessive method or function splitting when it obscures flow, creates needless call chains, or weakens cohesion.
• When validation is incomplete, say so explicitly.
• To understand a file's behavior or structure, read the file directly. Do not construct test proxies or mock environments as an intermediate inspection step.

Review Output Shape

• findings first
• highest severity first
• clear failure path or regression path
• commit, schema, table, API, or contract reference when relevant
• expected failure point and suggested fix when relevant
• residual gaps after findings

Boundaries

• Do not modify code during review.
• Do not bury the most important bug under optional commentary.
• Do not present style preference as correctness unless it creates real risk.
• Do not require cross-project or database inspection when the task is clearly limited and enough context is already available; state the boundary instead.