## Summary Follow-up to #3586481 (the *Re-queue on each save* checkbox for the Queue/Cron worker). In **2.x**, where we are free to move structure and make API changes, let `AiAutomatorFieldProcessInterface` (the field-process / "Automator Worker" plugin interface) expose its **own configuration subform**, so worker-type-specific settings live with the processor plugin instead of being hardcoded into the field configuration form. Target branch: **2.x**. ## Problem #3586481 adds a per-field *Re-queue on each save* checkbox that should only appear when the **Queue/Cron** worker type is selected. Today there is no clean place for that option to live: - The "Automator Worker" is chosen by the `worker_type` select in `AiAutomatorEditForm` (`modules/ai_automators/src/Form/AiAutomatorEditForm.php`, ~line 82), built from `AiAutomatorFieldProcessManager::getDefinitions()` and filtered by each plugin's `processorIsAllowed()`. - The field-process plugins themselves — `DirectSaveProcessing`, `BatchProcessing`, `QueueWorkerProcessor`, `ActionProcessing`, `FieldWidgetProcessing` (all in `src/Plugin/AiAutomatorProcess/`) — implement `AiAutomatorFieldProcessInterface`, which only declares `modify()`, `preProcessing()`, `postProcessing()` and `processorIsAllowed()`. **There is no form/settings hook.** - The `#[AiAutomatorProcessRule]` attribute carries only `id`, `title`, `description`, `deriver` — no settings schema either. As a result, any worker-specific option (like the Queue/Cron re-queue checkbox) has to be hardcoded into `AiAutomatorEditForm` with manual `#states` visibility tied to `worker_type`. That does not scale: every new worker-specific setting bloats the shared field form, and contrib worker types cannot add their own configuration at all. ## Proposed solution Since 2.x is a structural/major branch, extend the field-process plugin contract so each worker type can own its configuration as a subform: * Add configuration-form methods to `AiAutomatorFieldProcessInterface` (or via a `PluginFormInterface`-style contract / a base class) — e.g. `buildConfigurationForm()`, `validateConfigurationForm()`, `submitConfigurationForm()`, plus `defaultConfiguration()` — operating on a `SubformStateInterface`. * In `AiAutomatorEditForm`, render the selected worker type's subform in a container that swaps (AJAX) when `worker_type` changes, so only the active worker's settings show. Persist the values under a per-worker settings key on the automator entity (with config schema + update path). * Migrate the #3586481 *Re-queue on each save* option into `QueueWorkerProcessor`'s subform as the first consumer of the new mechanism, removing any hardcoded worker-specific handling from the shared form. * Provide a sensible default (empty subform) so existing worker plugins and contrib implementations keep working without immediately implementing the new methods. Document the new contract for contrib worker authors. ## Workaround Worker-specific options can be hardcoded into `AiAutomatorEditForm` with `#states` visibility on `worker_type` (the approach #3586481 takes), but that does not let processor plugins own their own settings and does not extend to contrib worker types. ## Affected modules / components `ai_automators` — `src/PluginInterfaces/AiAutomatorFieldProcessInterface.php`, `src/Plugin/AiAutomatorProcess/*`, `src/Attribute/AiAutomatorProcessRule.php`, `src/PluginManager/AiAutomatorFieldProcessManager.php`, `src/Form/AiAutomatorEditForm.php`, config schema + update path. ## Related issues * Follows up #3586481 (Re-queue on each save — Queue/Cron worker).