While developing the TypeSafe AI provider, I began to create "Decision" operation types. First ai_decision was part of ai_provider_typesafe_ai, then I split into its own project, now we are working to integrate the functionality into AI core without a separate submodule. Initially in the evolution of that development decision based ai_automaters were included via a contrib module and then a submodule. It seems prudent to keep the fix for this in https://git.drupalcode.org/project/ai/-/merge_requests/2046 among updates for other issues. This is 3 of a set of issues that will be solved with this MR. ## Problem/motivation `AiAutomator::calculateDependencies()` records the destination field and any guardrail set. It does not record the module that provides the selected rule (`AiAutomatorType` plugin). Drupal relies on config dependencies for removal and for import validation, so: - **Uninstall.** Uninstalling a module that provides Automator rules leaves its automators behind. Every later save of an entity in that bundle logs "A rule was not found" from the direct worker. The configuration points at a plugin that no longer exists. - **Deployment.** Config import cannot tell that an automator needs the module, so it imports and then fails at run time. Any module can supply rules, so this affects contrib and custom rule plugins generally. The Decision integration originally worked around it with a presave hook listing its own plugin IDs. ### Steps to reproduce 1. Enable a module that provides an `#[AiAutomatorType]` plugin other than `ai_automators` (the MR adds the test module `modules/ai_automators/tests/modules/ai_automators_rule_test` for this). 2. Create an automator on a field using that rule. 3. Uninstall the module. The automator config remains, its `dependencies` do not mention the module, and saving an entity in the bundle logs a missing rule. ## Proposed resolution **`AiAutomator::calculateDependencies()`** - Look up the rule definition with `getDefinition($this->rule, FALSE)` and add a `module` dependency on its `provider`. - `ai_automators` and `core` are implicit dependencies, so `addDependency()` ignores them. - An unknown rule adds nothing and throws nothing. - The method now ends with `return $this;`. It already returned the entity, previously through a variable named `$dependencies`. **`ai_automators_update_15002()`** backfills existing `ai_automators.ai_automator.*` config: - It adds the rule provider to `dependencies.module` (sorted) only when the rule resolves and the provider is neither `ai_automators` nor `core`. - Unresolved rules keep their existing data, so they can still be repaired. - It edits stored config directly (`save(TRUE)`), with no entity side effects. - Running it again changes nothing. **Test.** `modules/ai_automators/tests/src/Kernel/AiAutomatorRuleDependencyTest.php` checks that: - an automator using a rule from `ai_automators_rule_test` depends on that module, and a built-in `llm_boolean` automator does not; - `calculateDependencies()` returns the entity; - uninstalling the test module deletes only its automator, and keeps the other automator and the field; - the update restores only the missing dependency, leaves built-in and unknown rules untouched, and is idempotent. ## Remaining tasks - Review. - Renumber the update hook if another 1.x change claims 15002 first. ## User interface changes The uninstall confirmation now lists the dependent automators under configuration to be deleted. ## API changes None. The return value of `calculateDependencies()` is unchanged; it is still the entity. ## Data model changes **Dependencies.** Automator config whose rule comes from another module gains a `dependencies.module` entry. Existing sites get it from `ai_automators_update_15002`, then see a one-time diff on `drush cex`. **Behaviour after the update** - Uninstalling a rule's module now deletes its automators, and `ai_automators_entity_predelete()` cleans up their field widget action buttons. - Config import fails dependency validation for an automator whose rule module is not enabled. - Automator YAML in `config/optional` waits until the rule module is present. - Module and recipe authors shipping automator config should declare the rule's module.