Renaming fields and moving values

Values are stored under a field's key. When an assistant renames a key, the configuration changes instantly, but the values already saved under the old key don't move. Until they do, the renamed field looks empty on every existing entry.

The same is true when you rename a key in the dashboard. The difference is that the dashboard asks what to do with the values, while an assistant just renames; a careful assistant tells you this before renaming.

How the values get moved

A rename, or a deleted field that had values, adds an entry to Meta Watch, where you, or the assistant, can:

• preview what would happen: how many values, where, and whether any entries already have a value under the new key
• run the move, which works through large sites in slices until it's done
• delete the old values instead, permanently
• dismiss the entry, leaving the values where they are

If some entries already have a value under the new key, those are skipped by default and reported, and the entry stays open so they aren't forgotten.

If the field's type also changed, the preview warns when some values won't survive the conversion, and the move only runs once that's accepted.

Warning

Moving and deleting values can't be undone automatically. Deleted values are gone. To reverse a move, rename the key back, which queues a move in the other direction.

Relation fields

Renaming a relation field doesn't move anything; it keeps working. Changing its relation key does move the stored links, and the move refuses to run while another field still uses the old key. For a two-way relation, change the key on both fields first, then run the move.

Technical details for LLMs

• vx-framework/update-field with a new key in config renames without moving data and queues a migration only if values exist (an empty list after a rename means nothing to move).
• vx-framework/list-field-migrations (live affected counts, storage locations, type verdict, disposition migrate | keep | delete; status: "all" for finished entries with leftovers) → vx-framework/preview-field-migration (samples, conflicts, verdict vs real values) → vx-framework/run-field-migration (id, disposition, conflict_policy: skip (default) | keep_both, accept_lossy; resumable: returns done: false + cursor; check remaining and left_behind when done: true) or vx-framework/dismiss-field-migration. Neither has an undo.
• Relation key change: entry kind relation_key; lists every field still on the old key (inactive fieldsets included); the run refuses until they're repointed. Order: vx-framework/update-field on each side, then one vx-framework/run-field-migration. Renaming the relation field key freezes the old relation key into the config and moves nothing.
• Type change verdicts: none, compatible, lossy (sampled against real values), incompatible (scalar vs structured storage).