Changing your data model

With write abilities exposed (Level 2 or a Custom selection), an assistant can build and change your data model: create post types and taxonomies, create fieldsets and edit their fields, and import or restore configuration. Everything goes through the same checks as the dashboard, and each change is recorded with a way to undo it.

How a careful change looks

1. Look first. The assistant reads the current model.
2. Check the change without saving. Every write can run as a dry run that reports errors and saves nothing.
3. Apply it as one task. Several related changes, such as "create a fieldset, add six fields, attach it to Books", can be sent together, so they apply in order under a single task name and can be reviewed and undone together.
4. Report the undo. Each change says how to reverse it.

It's reasonable to ask your assistant to follow these steps and show you the dry-run result before it saves.

Editing fields one at a time

Assistants add, change, remove and reorder fields individually, rather than resending the whole fieldset. That way a field the assistant didn't mention can't be deleted by accident. If you expose the ability that updates a whole fieldset, expose the individual field abilities too.

Renaming fields

Renaming a field's key doesn't move the values already stored under the old key: until they're moved, the field looks empty on existing content. See Renaming fields and moving values.

When someone else changes the same thing

An assistant can pass along a fingerprint of what it read, and the change is refused if anything changed in between, instead of overwriting another person's work. Changes that run at the same time wait for each other rather than colliding.

Things an assistant can't do

• Change code-defined objects directly. When a post type or fieldset comes from a PHP or JSON file, the assistant must first copy it into the database, or write the change back to the file. See Config as code.
• Create, delete or change user accounts, roles, passwords or email addresses. VX only reads and writes user field values.

Technical details for LLMs

• Structural writes: vx-framework/create-post-type / update- / delete- (delete accepts keys), same for taxonomies; fieldsets vx-framework/create-fieldset (inline fields / location), vx-framework/update-fieldset (config.fields replaces the whole array), vx-framework/duplicate-fieldset, vx-framework/delete-fieldset; fields vx-framework/add-fields (fieldset, parent — a Group, Repeater, Section or Tabs key — after), vx-framework/update-field (merge), vx-framework/delete-fields (all-or-nothing), vx-framework/reorder-fields (one level, every key once), vx-framework/move-fields (into, out of or between sections and tabs, within the scope the fields are stored in); config vx-framework/import-config, vx-framework/override-config, vx-framework/reset-config, vx-framework/set-config-source, vx-framework/detach-config, vx-framework/write-config-to-project; vx-framework/restore-revision; vx-framework/flush-permalinks.
• Option pages and dictionaries: vx-framework/create-option-page / update- / delete- (delete removes stored values), same for dictionaries, plus vx-framework/set-dictionary-entries (replace | append).
• Relations: vx-framework/create-relation / vx-framework/delete-relation (stored links kept).
• Shared controls on every write: dry_run: true; batch_id (groups a task in the journal); if_match = the config_hash from the read (refused with conflict + current hash if changed). Deletes: destructiveHint; final-state writes: idempotentHint (safe to retry after a dropped connection).
• vx-framework/apply-changes: up to 25 vx-framework/* steps in order, one lock, one batch_id; stops at the first failure unless stop_on_error: false; returns each step's response and a combined undo list (last-first, usable directly as changes). Dry-run validates each step against the current site, so steps depending on earlier ones report missing targets. Over MCP each step must itself be exposed.
• Every write holds a database lock for the whole call. Over MCP, ok: false responses are returned as tool errors (full JSON as text); valid: false from a dry run is not an error.
• Code-owned objects are read-only: vx-framework/override-config first, or vx-framework/set-config-source to file for write-through. Check vx-framework/get-config-source.