### Problem/Motivation `field_storage_update` returns a failure as soon as `$field_storage->hasData()` is TRUE (`FieldStorageUpdate.php:128-135`), before it looks at what the caller wants to change. The input descriptions repeat the rule: "Can only be changed if field has no data" for `cardinality` (`FieldStorageUpdate.php:54`) and `translatable` (`FieldStorageUpdate.php:60`). Core is much less strict. With data present: * The SQL storage forbids only changes to the column schema (`SqlContentEntityStorageSchema::updateDedicatedTableSchema()`, `core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorageSchema.php:1767-1770`, using `hasColumnChanges()`). Otherwise it updates indexes and carries on. * Cardinality is not part of the column schema of the dedicated field tables, so increasing it, or setting it to unlimited, is allowed. Field UI allows a decrease too, as long as no entity has more values than the new limit (`core/modules/field_ui/src/Form/FieldStorageConfigEditForm.php:228-250`). * `translatable` does not change the columns of dedicated tables either. * For list fields, adding allowed values is allowed; removing a value that is in use is blocked by `OptionsHooks::fieldStorageConfigUpdateForbid()` (`core/modules/options/src/Hook/OptionsHooks.php:74-86`). * Changes that do alter columns, such as a smaller `max_length`, are rejected by core with `FieldStorageDefinitionUpdateForbiddenException`, which the tool already catches and returns (`FieldStorageUpdate.php:187-191`). So the blanket check blocks the most common real-world changes, such as allowing more values on a field that is in use or adding an option to a list, and the message tells the agent to "Delete all content using this field first, or create a new field instead", which on a live site means data loss. ### Steps to reproduce Fresh run, all calls over MCP as user 1: 1. `tool_belt_entity_bundle_add` `{"entity_type_id": "node", "bundle": "bgb_bundle", "label": "BGB bundle"}` 2. `tool_belt_field_storage_add` `{"entity_type_id": "node", "field_name": "field_bgb_data", "field_type": "string", "cardinality": 1}`, then `tool_belt_field_add` it to `bgb_bundle`. 3. `tool_belt_entity_create` `{"entity_type_id": "node", "bundle": "bgb_bundle", "base_fields": {"title": {"value": "bgb data node"}}, "fields": {"field_bgb_data": [{"value": "one"}]}}` 4. `tool_belt_field_storage_update` `{"entity_type_id": "node", "field_name": "field_bgb_data", "cardinality": 3}` Observed: "Cannot update field storage field_bgb_data for entity type node because field data already exists. Delete all content using this field first, or create a new field instead." 5. `tool_belt_field_storage_update` `{"entity_type_id": "node", "field_name": "field_bgb_data", "translatable": true}` Observed: the same message. 6. `tool_belt_field_storage_update` `{"entity_type_id": "node", "field_name": "field_bgb_data", "settings": {"max_length": 100}}` Observed: the same message. Expected: * Step 4 succeeds (cardinality 3 is above the one value in use). * Step 5 succeeds. * Step 6 fails with core's message that the SQL storage cannot change the schema of a field with data. * A cardinality decrease below the highest number of values in use fails with a message that names the limit, as Field UI does. ### Proposed resolution 1. Remove the blanket `hasData()` check at `FieldStorageUpdate.php:128-135` and let core decide. Core already throws for column changes and for removing list values in use, and the existing `catch` returns those messages. 2. When the new cardinality is limited and lower than the current one, and the field has data, run the same entity query as Field UI (`->condition($field_name . '.%delta', $cardinality)`) and fail with a clear message if any entity has more values. 3. Update the `cardinality`, `translatable` and `settings` descriptions to describe what is allowed with data, instead of "Can only be changed if field has no data". 4. Optionally replace raw core exception text with a short message that says the change needs a schema change and cannot be made while the field has data. ### Remaining tasks * Remove the check and add the cardinality decrease check. * Update the input descriptions. * Add `FieldStorageUpdateTest` kernel cases with data present: cardinality increase and unlimited succeed; decrease below the highest delta fails; `translatable` toggle succeeds; adding an allowed value succeeds; removing an allowed value in use fails; `max_length` change fails with a clear message. ### AI usage (if applicable) * [ ] AI Assisted Issue: This issue was generated with AI assistance, but was reviewed and refined by the creator. * [ ] AI Assisted Code: This code was mainly generated by a human, with AI autocompleting or parts AI generated, but under full human supervision. * [ ] AI Generated Code: This code was mainly generated by an AI with human guidance, and reviewed, tested, and refined by a human. * [ ] Vibe Coded: This code was generated by an AI and has only been functionally tested.