Open Code Review: inspect review scope, filters and model work
Trace Open Code Review from file selection to findings
Follow deterministic scope selection, model-assisted grouping and review execution while resolving a documentation mismatch against the pinned implementation.
What you will learn
- Read selection in the current implementation
- Keep later decisions separate
- Understand what grouping contributes
Before you start
- Git changes and merge-base comparisons
- Basic CLI use and model API credentials
Choose a review scope, explain exclusions, prepare a controlled pilot and distinguish source inspection from runtime evidence.
Key takeaways
- Current source adds a secret-path check missing from the five-gate diagram.
- Deletion and size checks follow static exclusions.
- Selection does not predict provider success.
Read selection in the current implementation
The pipeline prepares configuration and Git diffs, filters files, groups related changes and dispatches review work. In selection.go, selectFiles produces a decision for each input diff. The comments explicitly describe this function as pure, with preview and real execution sharing its decisions.
The architecture page still describes five static gates. The pinned implementation adds secret-path checks before user exclude and include rules. For the exact order, use the current function: binary, secret paths, user exclude, user include, extension allowlist and default path rules.
Keep later decisions separate
After static filtering, selectFiles handles deleted files and the per-file diff token limit. A deleted file remains in the working change list even though it is not dispatched for content review. This preserves change context without pretending that deleted content is a new file to analyze.
Budget exhaustion, resume reuse and provider failure depend on execution. The function’s own explanation excludes them from static selection. A preview can therefore match the final selected set while the run still fails to complete reviews of all those files.
Understand what grouping contributes
The architecture documentation describes a model call over file metadata, followed by related-file groups. It also documents splitting oversized groups and restoring coverage for omitted files. Those mechanisms help manage inputs; they do not establish that every interaction between files has been understood.
Use separate records for selection, grouping, execution and accepted findings in a trial. When a result is missing, locate the earliest stage that diverged from expectations. This article inspects the documented orchestration and current selector but does not claim an end-to-end execution trace.
Decision guide
| Criterion | Option A | Option B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Implementation steps
- 1
Locate selectFiles and whyExcluded in the fixed revision.
- 2
Compare preview exclusions with the implemented order, including secret paths.
- 3
Record execution outcomes separately from static selection.
Copy-ready example
binary / secret / user exclude: reject
user include match: admit past static gates
otherwise: extension → default path
then: deletion and per-file diff size
execution: budget, resume and provider outcomesFrequently asked questions
Can user include rules override all exclusions?
No. Binary and secret-path checks precede user includes, and user excludes also win.
Why retain a deleted file in change context?
It still helps describe the change even though there is no new file content to dispatch for review.
Sources
- Open Code Review / pages/src/content/docs/en/architecture.mdSource checked 2026-09-18
- Open Code Review / internal/agent/selection.goSource checked 2026-09-18
- Open Code Review / internal/config/allowlist/secret_path.goSource checked 2026-09-18