Activity log and undo

Every change made through a VX ability, whether by an AI assistant, WP-CLI or another integration, is added to an activity log: what changed, who ran it, how it arrived (MCP, command line, REST or dashboard), the task it belonged to, and how to reverse it.

Reviewing changes

Ask your assistant to list recent changes, or use the vx-review-changes prompt. From the command line:

wp vx-framework abilities run vx-framework/list-changes --user=admin

Each entry says whether it can still be undone, has already been undone, or has been changed again since. Changes that ran as one task are grouped.

Note

The AI screen doesn't currently include a view of the activity log. Review and undo changes through your assistant or WP-CLI.

Undoing

A change can be undone on its own, or a whole task at once, newest change first. Undo is safe by default:

• It checks first whether anything changed the object since. If it did, undoing would also throw that later work away, so undo stops and says so. It can be forced once you've checked.
• It can be tried as a dry run, which reports whether it would work without changing anything.
• Undo works one way. There's no redo; to put a change back, restore it from the fieldset's revisions or ask the assistant to make it again.

Changes that cannot be undone

Most changes can be reversed. These can't:

• Permanently deleting a post (skipping the trash).
• Deleting a term. WordPress has no trash for terms, so the term, its field values and its assignments to posts are gone.
• Writing configuration to a project file, or deleting a project file. Recover those from version control.
• Moving or deleting stored field values in Meta Watch.

How long a change stays reversible also depends on history: configuration undo relies on revisions, and only the 15 most recent revisions per object are kept. An older entry stays in the log, marked as no longer reversible.

What the log keeps

The log keeps the newest 1,000 entries. To undo field value changes, each entry stores the values that were there before, including values of sensitive fields. Anyone who can read the log (including an assistant with the default read-only access) can see those earlier values.

Technical details for LLMs

• Journal: {prefix}vxframework_ability_activity; fields per row: ability, author (name recorded with the row; System for CLI/cron), origin (mcp | cli | rest | dashboard), batch_id, summary + detail bullets, undo descriptor. Writes that partially persisted (ok: false, persisted: true) are journaled too.
• vx-framework/list-changes: cursor paging (before_id = previous next_cursor while has_more), filters batch_id, origin. Entry state: undo_available, unavailable_reason (undone | reversal | expired | none), undone { at, by, by_name }, reverts_id, superseded.
• vx-framework/undo-change: id or undo_batch_id; dry_run; force overrides the drift check (compares guard_hash). Over MCP the reversal may only run abilities that connection can already call. Reversal rows carry reverts_id and can't themselves be undone; no redo.
• Undo strategies: restore_revision (vx-framework/restore-revision), delete (matching delete ability), reset_to_code (vx-framework/reset-config), restore_values (content write with previous values), restore_post_revision (block documents), none (with note).
• Retention: 1,000 rows (vxframework/abilities/activity/max_entries); config revisions 15 per entity, so restore_revision undos expire earlier. Filter what's recorded with vxframework/abilities/activity/record.
• Prior values (including is_sensitive() types) are stored inline in undo descriptors and returned by vx-framework/list-changes.