Why whole-codebase context changes the review
A diff tells you what changed. It doesn’t tell you what the change breaks. The bugs that reach production usually sit one hop away from the edit: a caller that relied on the old behaviour, a second code path that formats the same data differently, a permission check that the new endpoint forgot.
CodeReviewer builds the repo as it’ll look after the merge and follows the change outward. Its findings cite that evidence: the file and line that sets the convention, or the caller that will break. So a reviewer can accept or reject a comment in seconds, without working it all out again.
What a finding looks like
Each finding has four parts: where (file and line), what (a one-sentence statement of the problem), why (the evidence from elsewhere in your code) and the fix (a concrete change you can apply with one click). If CodeReviewer can’t produce all four, it doesn’t post the comment.