GoBuildWP Change Ledger: Review and Roll Back AI Changes

What the ledger records

Supported changes are written to a change ledger on your own site: which credential acted, which ability ran, when it ran, and enough redacted context to investigate afterwards. It is designed to support accountability without becoming a second database of sensitive values.

Since GoBuildWP 1.15.0 the ledger uses a database table when available, with existing history moved across on update. Table-storage retention defaults to the newest 10,000 changes or 90 days, with large before-images pruned after 30 days; the retention policy is filterable. If the table cannot be created, smaller fallback storage keeps working and Diagnostics says why. Inspect the retained recovery data on the actual entry.

The redaction goes by field name. Values under keys that name a secret (passwords, tokens, API keys, cookies) are replaced before the entry is stored; every other input is kept, truncated to a fixed length, and each entry also carries a short result summary and, where the ability supports it, a before-image of the record. Treat the ledger as holding site content, and if you need a full audit trail of that data, that requirement belongs to your own logging and retention policy, not to the plugin.

Since GoBuildWP 1.15.1, email addresses are masked too, wherever they appear in a record: the input, the result, the before-image and the undo verification come back masked, first letters only, when the record is read, in wppilot/get-change, wppilot/export-changes, the Changes screen and its download. Masking happens on the way out, so what is stored is unchanged and an undo still restores the exact original.

Read a change before you react to it

Since GoBuildWP 1.14.0 the ledger has its own screen, GoBuildWP > Changes, for anyone who can manage GoBuildWP. It lists every recorded change newest first and filters by ability, agent, date range, status and kind, so the work of one agent on one afternoon is a filter away rather than a scroll. Opening a row shows its redacted input, its result and, after an undo, whether the observed state matched. An agent can read the same record with wppilot/list-changes and wppilot/get-change, but the screen is the view that does not depend on the agent that made the change.

Whichever way you read it, confirm which WordPress identity performed the operation, which ability was used, and what the recorded inputs and result show.

Unexpected attribution deserves investigation before more writes. Compare the recorded actor, credential and client with the loaded configuration and the intended operator. Attribution alone does not prove that a credential was created on the wrong user.

• The acting credential is the one you expected
• The ability name matches the work that was requested
• The timestamp lines up with the session
• Nothing sensitive has leaked into the recorded context

Roll back what can be rolled back

Rollback is available for supported reversible operations. Where it applies, it restores the previous WordPress state for that record and marks the original entry as rolled back, with the time it happened; it does not add a separate ledger entry for the rollback.

The Changes screen undoes at three sizes: one change, one bulk batch, or every undoable change the current filter shows, newest first and at most 200 at a time. A bulk write records one entry per item under a shared group, so a batch can be undone whole or item by item. After a multi-change undo the screen reports any change that did not come back, and those are the ones to look at by hand.

Since GoBuildWP 1.16.0 recorded writes are grouped by agent session: one MCP connection, one wp wppilot mcp serve process, or one credential and client until 30 idle minutes pass. The Changes screen has session controls; agents can use list-sessions, undo-session and redo-session. First call list-sessions with session_id and inspect conflicts, unchecked targets, not_reversible and not_redoable. Missing after-state or an unreadable target can leave a conflict check unperformed. Detected conflicts refuse the run; unsupported entries cause the default undo or redo refusal. Explicit allow_partial=true leaves those unsupported entries unchanged. Undo runs newest first and stops at a failed restore. Redo requires its own retained image and checks. Review the result and keep external effects outside recovery claims.

Rollback is never universal, and treating it as an undo button is the mistake to avoid. Some operations are irreversible by nature. Others have already been observed by systems outside WordPress. An email that has been delivered, a webhook that has fired, a payment provider that has recorded an event, a CDN that has cached a page.

Before relying on rollback for a risky workflow, test it on staging with the exact operation you intend to run in production. Knowing in advance whether an operation is reversible is worth more than discovering it afterwards.

What rollback does not cover

Backups remain necessary. Rollback addresses supported WordPress records; it does not restore a database, repair a schema migration, or reverse a change made outside GoBuildWP.

After a rollback, verify the rendered site rather than trusting the tool response, and check any external system that may already have reacted. Write down which of those checks you actually performed. An unverified assumption is the thing that bites later.

Native snapshots are capped at 512 KB per target, and a bulk call has a 1 MB before-image budget. Oversize targets or later items may lack complete recovery data. They are still recorded with their recovery status and reason; inspect the actual entry before relying on undo.

• Front end verified while logged out
• Caches cleared where relevant
• External providers checked for actions already taken
• A backup exists that predates the session

Export the record for a client or an audit

The same filters download as CSV or JSON from the Changes screen: when, which ability, who and which agent, the batch, whether the change can still be undone and why not, and the redacted input. Before-images are never exported, and a CSV cell a spreadsheet would run as a formula is defused before it is written.

An agent can pull the same rows with wppilot/export-changes, which is read-only and returns at most 500 rows or 256 KB per call with an offset for the next page. Use it for reports; use the screen or wppilot/list-changes to decide what to undo.