Checkpointing
Checkpointing is Syntic Code’s safety net for file changes. As Amara edits and writes files, the agent records snapshots so you can undo work, compare states, and roll back to any earlier point without relying on git commits. This lets you let the agent move quickly while keeping the ability to reverse anything it does.
How snapshots work
Before applying a change, Syntic Code captures the affected files’ prior contents as a checkpoint tied to the current step in the session. Checkpoints are lightweight and local to the session’s working tree; they do not create git commits and do not touch your staging area. Each meaningful action — an edit, a write, a batch of changes from one prompt — produces a restorable point you can return to.
Rewinding
You rewind from inside a session with slash commands:
/undo # revert the most recent file change
/rewind # choose an earlier checkpoint to restore
/history # list checkpoints with what each one changed/undo steps back one change at a time, which is ideal when Amara makes a wrong edit and you want to try again. /rewind jumps directly to a chosen checkpoint, discarding everything after it — useful when a whole line of work went the wrong direction and you want a clean restart from a known-good state.
Relationship to version control
Checkpointing complements git rather than replacing it. Use checkpoints for fast, in-session iteration and experimentation; use git commits to mark durable milestones you intend to keep. Because checkpoints are scoped to the session, they are cleared when the session ends, so anything you want to preserve should be committed. When a goal advances over many sessions, its progress is checkpointed separately so long-running work remains recoverable across runs.