Safety net
Handing an AI write access to a live client site is only reasonable if you can undo it. One step back before every page write, a snapshot before every design-system write, every write logged. Every write is logged and shows up in site history.
Before every write
One step back is put aside before the change lands, not after — a WordPress revision, or a saved copy of the previous content where revisions are switched off, and you are told which of the two you got. One command puts the page back exactly as it was, and the restore is itself undoable. The list runs newest first with a module count, saved copy included, so you can see the shape of a change before you restore it.
A real audit trail
The last 200 tool calls are logged with what changed and when. If a client asks why their page moved, there is an answer — and if a run goes wrong, you can see exactly how far it got before you roll it back.
Switches you control
read_only, draft_only, auto_draft, protect_design, confirm_overwrite, enforce_tokens. Claude can tighten any of them and can never loosen one for itself — the switch is not reachable by the thing it restrains.The working rules
Reads are free and touch nothing. Writes are journaled — what changed, where, from what to what, and when. Risky work — migrations, design-system changes, bulk fixes — takes a snapshot first. And undo is per-change, not per-catastrophe: reverse one fix and leave the other forty-nine standing.
What undo will not do
It reverses stored content and settings, not time. An optimized image is written alongside its original, so undoing the fix simply points references back — nothing 404s. The journal itself is never rewritten: it is the paper trail, and the paper trail is the point. The full argument is in our guardrails essay.