Why a checkpoint captures the whole tree

A checkpoint captures your entire working tree at that moment, not just the specific files a given turn is expected to touch based on what it said it would do.

This is what makes /rewind reliable even in the case where a turn ends up editing something genuinely unexpected partway through, a file that turned out to also need a small change once the primary fix was understood better.

There is no separate, narrower tracking of "which files this turn might change" that could fall out of sync with what actually changed; the whole tree before the turn and the whole tree after it are both known exactly, with nothing in between left to infer.

This also means a checkpoint is never invalidated by a turn behaving in a way that was not anticipated when the checkpoint was taken; it was already a complete snapshot the moment it was created, so there is nothing for a later surprise to be inconsistent with.

The alternative, tracking a narrower list of files a turn is expected to touch, would introduce exactly the kind of drift this design avoids: a list that turns out wrong the moment a turn edits one file more than expected would be worse than no list at all if /rewind depended on it.