The review unit
This page explains why the unit of decision is what an agent changed for a prompt.
The single idea that makes review keep pace with generation: the unit of decision is not a raw file write, but what an agent changed for a given prompt. This page explains the review unit and why it's bounded the way it is.
Why raw edits are not the unit
Agents revise the same code several times before settling — a first attempt, a fix, a rename, a cleanup. Reviewing each raw edit would ask you to judge intermediate states that no longer exist. So OAK collapses them.
The review unit
The review unit combines edits to the same lines — or the same detected function — into one unit whose diff is the net change, bounded by the prompt that produced them. A superseded intermediate state never asks for a decision, and accepting or reverting a unit acts on every edit inside it.
The prompt boundary matters: it's what keeps one ask's churn from merging with the next ask's, so a unit always answers "what did this one request do to this code."
A revert acts on the underlying edit records, but review reads in units. So a Rewind dialog names both — the records it will revert and the units they collapse to. The unit count is the one the prompt rows show.
What comes next
Once you're deciding on units, Keep and Undo act on one unit at a time, while Accept and Reject act on a whole scope. A refused revert is a conflict, handled explicitly rather than silently.