Field key conflicts

Two fields conflict when they have the same key and store their values in the same place. Two separate price fields on Books would overwrite each other's values. A price on Books and a price on Writers don't conflict: each post type stores its own values.

When keys clash

Keys are compared among active fieldsets that share a Location:

• one scope per post type and per taxonomy
• one shared scope for all users

A fieldset without Locations can't clash, which is why a fresh duplicate can keep all the original's keys. Only top-level fields are compared; fields inside a Group or Repeater only need unique keys among their siblings.

The editor prevents most conflicts: the key input shows Taken, and the Locations tab lists overlaps and keeps Save disabled until they're fixed. Conflicts can still arrive another way, for example from code or an import. The Field key conflicts card on the Settings screen shows Resolve when there are any.

Fixing a conflict

The conflicts screen lists each clashing key and the fieldsets involved. There are a few clean fixes:

1. Rename one of the fields. If it already has values, queue a move in Meta Watch.
2. Remove the shared Location from one of the fieldsets.
3. Use a Clone when both are meant to be the same field. Clones of the same original don't count as a conflict.

Deactivating a fieldset also takes it out of the check. Click Rescan after making changes.

Technical details for LLMs

• Scope: top-level keys among active fieldsets sharing a Location target (post_type:<key>, taxonomy:<key>, one user scope). Checked at save time, during import planning, and on the conflicts screen.
• REST: vx-framework/v1/fieldsets/conflicts, …/conflicts/summary, vx-framework/v1/fieldsets/{key}/location-conflicts. Before adding fields via abilities, check vx-framework/get-object-fields for the target.