What Protuno Can And Cannot Change

The mode is the control

The site’s mode is what decides whether anything can be written. A site set to Execute grants write access to any playbook that runs on it. A site set to Read only does not get written to: every tool that could change the site is removed from the run’s inventory before the model sees it, so it cannot make the change rather than being asked not to.

The Read Only / Can Write label on a playbook card is real and is enforced, but only for scheduled runs: a routine for a playbook that can write will not fire on a read-only site, and the routine row says so. 17 of the 27 only read. The other 10 can change something.

Two limits worth knowing, because the guardrail is good rather than absolute. Tools are removed by matching their names against a list of changing verbs, so an ability the plugin adds under an unfamiliar name would survive. And the REST tool is deliberately kept, because it is the main way a site is read at all; on a read-only site it is held to reads by instruction rather than by removal. Neither is a reason to distrust the mode. Both are reasons to do the work on staging and keep your live site in Read only, rather than treating the mode as the only thing between an agent and the site you care about.

You approve before anything changes

When you ask a Super Agent for a job, your AI app shows you the plan, and the plan appears as a card in Protuno. Only you can approve it, by pressing Approve there. Your AI app cannot approve for you. Each agent also has a trust level on each site, set on the agent’s page under On this site:

• Read. Looks, never touches. Runs only playbooks that read the site.
• Ask. Plans, then waits for your yes. Every step that changes the site asks again first, with Approve this change on the job card.
• Auto. After you approve the plan, it runs without stopping to ask. Playbooks that need a backup make one as their first step.

New agents start at Ask. On top of that, the work runs on your staging site, that your live site stays in Read only unless you change it, and that the sequence about to run was written down in full before it ran, so you can read it first.

A playbook you build yourself can carry an approval checkpoint, which holds the run at that step until somebody approves it. The run then shows as Waiting on you in Activity. None of the 27 ready-made playbooks uses one.

If you want a conversation before a change, have it in your AI app. It proposes, you approve in Protuno, and nothing is applied until you do.

Rolling a run back

Every run records what it changed, as it changes it, by re-reading the target and confirming it is different. The run’s report carries a Rollback this run button, and opening it shows exactly what would be put back and what would not, before you commit to anything.

The record is the honest part. A change made through a named capability is recorded with enough to reverse it. A change made by running arbitrary PHP is recorded as “cannot be undone”, because nothing observed what the snippet did. So a report will tell you “every change this run made can be undone”, or “4 changes can be undone; 2 cannot”, rather than offering a button that might mean either.

What rollback fully covers

Three playbooks are known to make only reversible changes, and they are exempt from the pre-run backup gate for that reason:

Playbook	How it goes back
Plugin Safe Update	Reinstalls the previous version from wordpress.org. It also rolls itself back during the run: each plugin folder is stashed before its update and restored if the site stops working.
Spam Comment Deleter	It never deletes. It moves comments between moderation states, and rollback moves them back.
Broken Link Checker	Each edit lands as a post update that records the post’s previous body, so rollback restores the text. The edit is also a WordPress revision, so you can restore it by hand from the post history.

What rollback does not cover

Everything else. WP Doctor, WP Hardening, Database Optimisation and AI SEO Optimiser all change things by running PHP on the site, which records “cannot be undone”. Those runs get the backup gate instead: the run refuses to start until a restorable backup exists.

Database Optimisation is the clearest case, and the one worth reading twice. Its deletes are permanent. It does not run table optimisation and it does not use raw SQL; it removes revisions, spam and other bloat through WordPress’s own delete functions, and it skips any category that looks anomalous. Its second and third steps take a database backup and prove that backup is sound, before anything is deleted. That backup is the way back. Take your own as well if the site matters.