Why checkpoints happen before a turn, not after

A checkpoint is created before a turn runs, not after it completes. This ordering is deliberate: it protects against the turn's own changes, not merely against tCode crashing or failing partway through.

Even a turn that finishes completely normally, producing exactly the change you asked for with no errors along the way, is still checkpointed beforehand. Reviewing the result afterward and deciding you actually preferred the original state remains an option either way.

This is what makes checkpoints a genuine safety net for approved, successful changes, not only a recovery mechanism for something going visibly wrong mid-turn.

The timing also means a checkpoint is never influenced by what the turn actually ends up doing; it captures the state of the world before the model has made any decision at all, which is exactly what makes it a clean, neutral "before" to compare against afterward.

In effect, every file-changing turn gets its own clean before-and-after pair: the checkpoint taken beforehand, and the working tree as it stands once the turn completes, with nothing in between left ambiguous.