Reversible by default
Your agent can wreck a live site and put it back byte for byte, in one command. Here is the whole boundary: what always comes back, what moves instantly, what waits in the trash, and what is gone for good.
Hand your agent a live website and one instruction: wreck it. Break the layout every page hangs from, strip the blocks out of the home page, delete a template other pages include, throw away a page entirely. Then tell it to put the site back. It can — byte for byte, in one command, without you lifting a finger.
That is a drill we run against this engine before we promise anything, and it is why changing a live site here is cheap rather than scary. Every publish captures an immutable revision snapshot: a complete, self-contained copy of the content at that moment. Restoring one is non-destructive — the current state is checkpointed first, then the older one is reinstated, so the rollback is itself just another revision in the history.
Deleting is an undo point, not a cliff. History binds to the page, not to the database row it happened to occupy — so a deleted page, template, collection or record keeps its revisions, and restoring one of them is the undelete. Recreate something by hand under the same name and it picks its old history back up rather than starting from one.
And the whole site rewinds in a single command. Not one page — the site: pages, posts, templates, collections, records, and the site’s own settings, navigation and wiring, all back to one moment, in one transaction that refuses rather than half-applies. It undeletes what died after that moment, removes what was born after it, republishes what was public then, and hands back the timestamp that undoes the entire run. You can look before you leap: ask for the plan instead of the rewind and nothing at all happens.
Where the default stops
A safety net whose edges you cannot see is worse than no net at all, because you lean on it in the one place it was never strung. So here is the whole boundary. Every change you or your agent can make is one of four things.
What can always be undone. Everything your site serves — pages, posts, templates, collections, records, navigation, forms, site settings — leaves history. Every published change can be rolled back, every delete can be undone, and one command rewinds the whole site to any moment. Unsaved drafts that were never published or checkpointed are the one thing no history holds; the site your visitors see is always restorable.
What moves instantly and comes back by hand. Addresses — your site’s handle, a blog’s URL segment, a custom domain — change the moment you change them, and the old links stop working right away. Changing an address back restores it, and spun.ink tells your agent exactly what moved, but there is no history for addresses and no rollback: links other people already have stay broken until you point the address back.
What sits in the trash. Deleting a whole site does not destroy it. The site stops serving, disappears from authoring, and waits in the trash with its history intact — still visible in your site list, marked as trashed. You can restore it any time. It stays there until you, personally, by email confirmation, empty the trash.
What is gone the moment you delete it. Emptying the trash, deleting your account, and deleting a form submission are permanent. Submissions are visitors’ personal data, so deleting one really deletes it, immediately, with no undo — that is a privacy promise, not a gap. For the two big erasures, an AI agent cannot take the last step alone: once your email address is verified, spun.ink confirms with you, the human, by email.
Four classes, and the posture they add up to is the point. You can let the agent try the bold redesign, publish it, and take all of it back if it misses. The safety net is the feature — and so is knowing exactly where it ends.