Reviewing AI-generated code before it reaches the main branch

September 18, 2026 · Workflow · Review · 4 min read

The review panel states the arrangement in two sentences a reader can check against the installed application. The first names what is captured: source files, untracked files, binary files, executable permissions and symlinks. The second names what is not: generated and dependency folders are excluded, and external files and external services are not rolled back.

Those two sentences do most of the work. A review surface that describes only its coverage invites a reader to assume the rest, and the assumption is usually wrong in the direction of trusting the snapshot more than the snapshot warrants.

The baseline is recorded, not remembered

ClearFrame checkpoints a project before a task uses its first tool, and the panel states that earlier tasks have no retroactive backup. A project edited before ClearFrame was involved has no checkpoint covering those edits, so the first checkpoint of a task is the boundary review works against.

That boundary is what makes a change reviewable. Without a recorded baseline, a reviewer compares the current tree against a recollection of the previous one, and the comparison degrades as the session lengthens. The failure is quiet: the reviewer does not notice the drift, only the wrong conclusion later.

A checkpoint is a record of file contents at a moment. It is not a record of intent, and it does not know why a file changed. Two edits that produce the same bytes are indistinguishable in the snapshot, whether one was a deliberate fix and the other an accident.

What a restore actually writes

Selection is per file. Committing writes only the files selected in the review, and staged work elsewhere is left as it is. A restore saves the current contents first, so the action has a stated undo path rather than being the end of the history.

Two limits sit alongside those mechanics. Generated and dependency folders are excluded from the snapshot, so a change to a build output directory is not something the panel restores. External files and external services are outside the rollback entirely, which means a task that changed a remote system has left a change that no local restore can reach.

The per-file granularity has a second consequence worth naming. A reviewer who wants to keep part of a file and reject the rest is choosing between two whole versions. The mechanism compares and restores files, not regions within them.

Isolation is a separate property from review

ClearFrame states that each task works in an isolated copy and that integration preserves a recovery checkpoint. Review and isolation are distinct properties, and conflating them hides which one is doing the work. Isolation bounds what an unfinished task can affect. Review is the moment a person decides whether finished work is written to the original.

The isolation boundary is not a defense against a hostile agent. It bounds partial work. Two tasks editing one working tree can each build on the other's half-finished state, and the reconciliation cost of that is larger than the parallelism it buys. Separate copies mean neither task observes the other until someone decides the work is ready to meet.

What the reviewer is deciding

Three questions come apart on this surface, and a review process that answers them as one tends to over-trust the result. The first is what changed: the panel answers that, per file, against a recorded baseline. The second is whether the change is correct: the panel does not answer that, and neither does any snapshot. The third is whether the change belongs in this project: only the person reading it can answer that, and the answer depends on facts that are not in the tree.

Keeping the three apart is what makes the surface usable as evidence. A recorded baseline answers the first question well, which is a genuine improvement over comparison by memory. It answers the second not at all, and a process that treats a clean restore point as a correctness signal has confused a file operation with a judgement.

A checkpoint is not a certification

Nothing in this surface reports whether a change is correct. A checkpoint records what the files held at a moment and lets a person restore them. It does not evaluate the work, run a test, or assert anything about the software's quality.

ClearFrame holds no third-party security certification, and the security page states that under what is not claimed. The distinction matters when review is being used as evidence: a recorded baseline shows what was in the tree, and says nothing about whether the change that replaced it was sound.

What the panel provides is a recorded baseline, a per-file selection, an undo path, and an explicit statement of what falls outside the snapshot. The last of those is the one usually left out, and it is the one that decides whether a reviewer can rely on the others.

The desktop application's review mechanics are documented at /docs/, and file recovery covers the capability this surface does not have.