Keep, undo, accept & reject
Two verb pairs cover every decision, separated by how much they act on.
Two verb pairs cover every review decision, distinguished by how much they act on. Keep and Undo act on one review unit; Accept and Reject act on a whole scope. Everywhere, the verbs mean the same thing and act on the same numbers.
Keep and Undo
Keep and Undo act on a review unit — one decision, however many captured records it took to make it. Keep marks it accepted. Undo reverts it on disk with a position-anchored merge that preserves the edits around it — later changes to the same file stay in place.
Accept, Reject, and Clear
Accept and Reject act on a scope — a file, a folder, a prompt, a task, or the whole session — by keeping or reverting every pending edit in that scope. Clear drops a scope's resolved edits from view without touching disk.
The resulting edit states are accepted and reverted on every surface; the store encodes them as kept and undone.
Keeping or reverting a single edit opens the next one still awaiting review, crossing into another file when that's where it is. Bulk operations don't move you — they have no single next edit — and a resolve that didn't happen doesn't either. It's a setting in both editors, on by default.
Rewind and Redo
Rewind reverts every unreviewed edit from one of your asks onward — not only the edits that ask produced. That distinction is the point: rejecting a prompt mid-session undoes a base that later edits were built on, while rewinding puts the tree back to the state it had before you asked.
The Redo offered on the result restores exactly what that rewind reverted, and nothing else — an edit you had rejected before the rewind stays rejected. The command-line redo --from-prompt is the wider verb: it re-applies every undone edit from that ask onward, including those earlier rejections.
If a later edit genuinely overlaps the change, the undo is refused rather than corrupting the file — see Conflicts.