What Protuno Can And Cannot Change
Read only and Execute, what the site’s mode actually controls, and what a run will never stop to ask you.
This is the part worth reading before anything else. Protuno’s safety model rests on one setting you control per site, plus a clear-eyed view of what can and cannot be undone afterwards.
Read only and Execute: the two site modes
Every connected site is in one of two modes, changed from the site’s own screen:
| Mode | What it means |
|---|---|
| Read only | Analyses and reports. Changes nothing. |
| Execute | May change files, the database and settings. |
A site you connect as a live site starts in Read only. A site you connect as a staging site starts in Execute, on the reasoning that staging is where you want things tried. If you are connecting a staging install that matters, check the mode after connecting rather than assuming it.
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. Ten of the seventeen only read. The other seven exist to 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 not to treat it as a substitute for not connecting a site you are unsure about.
A run never pauses to ask you
None of the seventeen ready-made playbooks stops to ask you mid-way. What protects a site is not a prompt. It is that the site is in Read only unless you changed 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 Run history. None of the seventeen defaults uses one.
If you want a conversation before a change, that is what Ask Agent is for. It proposes, you approve, 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.
Comments