### Problem/Motivation Three related contract problems that freeze at RC1: 1. **`ExecutableResultInterface` is misnamed.** It is implemented by the _tool plugin_ (`ToolInterface extends ExecutableResultInterface`) — it describes "a thing that carries an execution result" (`getResult()`, `getResultMessage()`, `getResultStatus()`, now `hasResult()`), not the result itself. Meanwhile `ExecutableResult` — the actual result — is a `final readonly` class implementing no interface. 2. **Concrete final classes are hard-typed into the frozen interface.** `getResult(): ExecutableResult` and (new since beta2) `getFormattedResult(): FormattedExecutableResult` both bind the plugin contract to final concrete classes, so neither result object can ever be swapped, decorated, or mocked through the interface. 3. **Core's `ExecutableInterface` has a scheduled signature break we cannot absorb.** `ToolInterface` transitively extends `Drupal\Core\Executable\ExecutableInterface`, whose method is now declared `execute(/* ?object $object = NULL */)` — core's convention for a parameter that becomes real in the next major. `ToolBase::execute(): static` takes no parameter; when core actualizes the argument, every tool plugin fatals (an implementation cannot omit an interface parameter). The parameter is also semantically wrong for tools: core's interface means "executed against a subject object" (conditions, actions); tools take typed inputs. A code search confirms nothing in the ecosystem relies on tools being core-Executable — no instanceof checks, no ExecutableManager usage, no type hints; invokers call `$tool->execute()` directly. The inheritance is ornamental with a time bomb attached. ### Proposed resolution Decide one of: - **(a) Rename + interface**: rename `ExecutableResultInterface` → `ExecutableResultAwareInterface` (or fold its methods into `ToolInterface`), introduce a small value-object interface implemented by `ExecutableResult`/`FormattedExecutableResult`, and type the getters against it. - **(b) Deliberate coupling**: keep the concrete final types, rename only the misnamed interface, and document that result objects are final value objects by design (record in the API docs). Either is defensible; (b) is the smaller change and final value objects are a legitimate pattern — but the interface _name_ should be fixed regardless, and the decision recorded before the freeze. Independent of that choice, **drop `extends ExecutableInterface` and declare `execute(): static` on the tool's own contract**. Recommended shape: fold both `execute(): static` and the result accessors directly into `ToolInterface` and delete `ExecutableResultInterface` (nothing external implements it), rather than introducing a `Drupal\tool\ExecutableInterface` that shadows the core interface's name with different semantics. This also gains a real return type (`static`) that the core interface could never declare. ### API changes Interface rename/removal and detachment from core's ExecutableInterface (class_alias for the transition is unnecessary pre-RC since nothing external implements or type-hints these — verified by code search). `ToolInterface` no longer satisfies `instanceof \Drupal\Core\Executable\ExecutableInterface`; no known consumer depends on that. ### AI usage (if applicable) - [x] **AI Assisted Issue:** This issue was generated with AI assistance, but was reviewed and refined by the creator. - [x] **AI Assisted Code:** This code was mainly generated by a human, with AI autocompleting or parts AI generated, but under full human supervision. - [x] **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.