Review Is the Product’s Safety Valve
Orca’s review layer determines whether a promising agent attempt can become a change that another person is willing to inherit. This chapter follows the selected worktree from a diff against its starting point through line-level feedback, revision, hooks, commit, push, and hosted review. The practical judgment is not whether Orca can display generated code; it is whether the interface keeps the reasoning, evidence, and irreversible Git actions connected long enough for a human to make an informed decision.
Read the change against its starting point
A completed agent session gives the operator a candidate. The first useful question is not “does this look polished?” but “what changed in this worktree, relative to the point from which it began?” Orca’s diff viewer is built around that question. It can show staged, unstaged, and untracked changes together and compare the worktree with its start-from ref, another branch, or a selected commit. That scope matters because a parallel attempt is meaningful only when the reviewer knows which edits belong to the attempt and which files were already present.
The starting point is especially important in a race among agents. Suppose one worktree began at the repository’s default base and another began on a branch that already contained a partial fix. Their final files may both appear to solve the login problem, but their diffs do not carry the same meaning. The first diff describes an independent proposal. The second may describe an incremental correction. Orca can show both, but it cannot make their ancestry equivalent after the fact. The reviewer must preserve the distinction when deciding which evidence transfers from one attempt to another.
A diff is also more than a list of changed lines. Orca combines changes across file states, includes line numbers on both sides, supports image and HTML previews where relevant, and offers a three-way view for merge conflicts. It allows staging by file, hunk, or line, much like an interactive Git operation with a visual context. These features reduce the chance that the operator reviews only the most obvious source file while missing a generated artifact, an untracked test fixture, a configuration change, or a conflict resolution that changes the behavior elsewhere.
Visual staging creates a useful separation between inspection and publication. An agent may have changed five files, but the accepted commit may need only three. A reviewer can stage the hunks that belong to the fix, leave unrelated experimentation out, and inspect what will actually enter history. This does not prove that the selected set is correct. It does make the boundary of the proposed change explicit, which is a precondition for meaningful review.
The diff can also show provenance. Orca records ranges it observed an agent touch and marks AI-originated lines in the review surface. When a human edits those lines, attribution changes back to human. That signal can focus attention: a reviewer may scrutinize a complex generated algorithm more closely than a small hand-written adjustment. But it is not a permanent Git fact. Attribution is local to Orca unless the metadata is exported, so it cannot by itself serve as a committed compliance record or prove who authored every line in a repository’s history.