It restores, it does not delete
Restoring writes through WordPress, so every post it touches gains a revision. Undoing an agent never destroys what the agent did — both versions stay in your history.
The path a change takes
Proposal. A run examines your site and produces a list of what it would do and why. Nothing has happened. Each finding opens to show the reasoning and the page's current metadata.
Approval. You approve, or decline. Declining is always available, including when a licence has lapsed — you should never be unable to say no.
Work. Approved jobs queue and run in the background. Before any job touches a post, that post's current state is recorded against the run. If that recording fails, the edit does not happen.
Undo. Restore one post, a ticked selection, or everything the run touched.
What undo actually does
It covers the featured image too
The image a run chose is replaced by the one that was there before. The newer image stays in your media library; undoing an edit is not a reason to delete a file.
A selection is checked
Ticking posts restores only those, filtered against what that run actually recorded. A post id from another run cannot be restored through the form.
Two shapes, two controls
A run that edited posts restores them. A run that only added rows — the librarian — has nothing to restore, so undoing it removes what it made. Those are separate buttons on purpose.
What the record actually holds
The state captured before a job runs covers the fields an agent is capable of changing, and nothing else: the title, the content, the excerpt and the plugin’s own post meta. That is the entire surface the agents write to.
It is not a backup of your site and does not pretend to be one. A post’s meta includes rows written by your theme, your other plugins and WordPress itself, and putting those back from a record made by a content agent would be a larger promise than it can keep. Restoring returns what the agent could have touched, which is what undo needs to mean.
Approving by email
Approval can arrive as an email carrying an approve link and a reject link, so a draft can be cleared by someone who is not going to log in to review it. There are two shapes. The plain one publishes or rejects. The staged editorial workflow instead moves the post to the next status in the pipeline, and sends one final reminder if the first review window passes with no answer.
How the links are kept safe
A link in an email that changes something is, by its nature, reachable without logging in. That is true of every approve-by-email design and it is worth being plain about rather than quiet about. What can be controlled is how much a leaked link is worth, so the token is:
Single use
It works once. A forwarded email cannot be replayed.
Scoped to one post
It is generated per post and stored against that post. It confers nothing anywhere else.
Not a shared secret
It is 32 random characters, generated for this purpose. It is never the scheduling token and is never reused.
Never shown again
Once the email is sent the token does not appear anywhere in the admin screens.
The worst case is therefore bounded: someone holding a leaked link can affect one unpublished post, once.
Why not just WordPress revisions
Revisions are a fine rollback until a site sets WP_POST_REVISIONS to false or caps it low. A restore that is only sometimes available is not a restore, so the prior state is recorded explicitly rather than assumed.
Run a safe proposal
Start a run with conservative ceilings, read the proposal, and approve nothing you do not want.