Code review checks the scoped work
Code review checks the scoped work
Code review is not the place to fix everything nearby. It is the place to assess the work that was specced and built.
The rule
Review the PR against the ticket:
- Does it solve the stated problem?
- Does it preserve behaviour we still need?
- Are the important failure modes handled?
- Is there enough test evidence for the risk?
- Will the next engineer understand the shape of the change?
Do not turn the PR into a redesign session, backlog cleanup, or "while we are here" exercise. If a better idea changes the scope or spec, write it down as follow-up work.
The escape hatch
Block the PR if the current slice is wrong, unsafe, insecure, likely to corrupt data, likely to harm users, or built on an architectural decision that will be painful immediately.
That is not scope creep. That is review doing its job.
The line: block for the current work being wrong; create follow-up work for the wider system being imperfect.
If review shows the ticket itself is wrong, stop treating it like a code problem. Move the conversation to the ticket, spec, product thread, or design discussion. A pile of PR comments will not fix a bad premise.