Snapshots & version history
A snapshot is an immutable point-in-time copy of a project — a saved version you can return to or restore. Snapshots live inside the project alongside the live working copy; anyone with access to the workspace can open them through the editor's version history.
Saving a snapshot
The editor's toolbar has a clock icon that opens the version-history dropdown. The Save snapshot action at the top of the dropdown captures the current state of the project under a timestamp label. Each snapshot freezes:

- every state's JSX,
- every transition,
- every frame size,
- the project's goal and description,
- any free-floating canvas elements (drafts on the canvas).
Snapshots default to a timestamp name (e.g. "May 14, 2026, 3:42 PM"). Double-click a snapshot row in the dropdown to give it a more descriptive name — handy when there are several snapshots from the same afternoon and you want to label the one that matches a particular review or milestone.

Browsing snapshots
The version-history dropdown lists every snapshot on the current project, most-recent first. Click a row to open the snapshot — the canvas switches to a read-only view of the frozen project at that moment. The toolbar's clock icon turns coloured while you're viewing a snapshot so it's clear you're not editing the live project.

Click Live at the top of the dropdown to return to the editable working copy.
Restoring a snapshot
The Restore button on a snapshot row overwrites the live project's states, transitions, and canvas elements with the snapshot's contents. The original snapshot is not modified; restoring is a one-way copy into the live project, not a branch.
Restoring is destructive to the live project. Save a fresh snapshot first if the current live state is worth keeping.
Deleting a snapshot
Snapshots can be deleted from the version-history dropdown. Comments attached to the deleted snapshot are also removed. See Comments & feedback.
Snapshots vs the live project
The live project keeps changing; a snapshot never does. Two common workflows flow from that:
- Review checkpoints — save a snapshot at the end of each working day or iteration so reviewers can compare versions without being confused by in-progress changes. Comments left on a snapshot stay attached to that version.
- Release pinning — save a snapshot at the moment a feature's design is locked and reference it from the PR that implements it. The implementation matches a fixed reference rather than a moving target.
How sharing works
Statecraft has two ways to put a prototype in front of someone:
- Workspace invite for collaborators who need to leave comments. Anyone you've invited to the workspace can open every project in it, see every snapshot, and leave comments (if they're an owner or editor — viewers can only read). There is no separate per-snapshot or per-project share link; access is the workspace itself.
- Play URL for stakeholders or user-testing participants who just need to click through. Play links are public — no sign-in, no workspace membership — and render the prototype with no editing chrome, so it works for anyone you can email a link to. Comments aren't available in Play.
To collect feedback on a specific snapshot, invite the reviewer to the workspace as an editor and direct them to the version-history dropdown. To show the prototype to someone outside the workspace, open it in Play and share the URL.