“Completed” is a useful status only if a reader can ask, completed what? In cline/cline, a public commit restores the View Changes action on the latest completion row. It opens a multi-file comparison from a checkpoint taken when the user’s last message began to the workspace as it stands now. The move is small in the interface and large in posture: the agent’s final prose no longer has to be the only account of its work.
The implementation matters because it puts the comparison boundary in the product, not in a vague promise to “show a diff.” Cline’s controller hands the request to the SDK checkpoint path, and the completion card exposes it only on the newest finalized turn. A reader reviewing an agent’s work gets a concrete question to answer: do these files, in this interval, match the job that was asked for?
The button waits for evidence
A follow-up adds a useful refusal: the control starts faded and disabled while Cline asks the host for the number of changed files. If the answer is zero, it stays disabled and says there are no changes since the last message. That is a better failure mode than turning every completion into an invitation to hunt through an empty diff.
A receipt is not a result
The checkpoint diff cannot tell a reviewer whether the change is correct, safe, tested, or even sufficient. It can make the right next step cheap: inspect the delta before accepting the completion. The next signal worth watching is an end-to-end test of difficult workspace states—untracked files, renames, conflicts, and outside edits—because that is where a clean boundary has to earn the reader’s trust.