_Category: plan. No MR of its own; closes when the last child lands._ ### Problem/Motivation `InputDefinition` extends core `ContextDefinition`, and after [#3583015](https://git.drupalcode.org/project/tool/-/work_items/3583015) the new `OutputDefinition` family does too. Of everything the context system offers, the tool stack uses exactly three things: the `isMultiple` flag, the `default_value` slot, and `getDataDefinition()` as a conversion bridge into typed data for validation. The features the class actually exists for — context matching, `isSatisfiedBy()`, sample values, assignment restrictions — have zero references across tool, tool_belt, tool_shop, and the connectors. What the parentage costs us: * A parallel `MapContextDefinition`/`ListContextDefinition` hierarchy that shadows typed data's own map/list definitions and converts between the two on every validation. * The TypedDataManager prototype-cache reflection workaround in `validateInputValue()` and `validateOutputs()` (core bug [#3616328](https://www.drupal.org/project/drupal/issues/3616328)), triggered by rebuilding fresh data definitions from context definitions each call. * `EntityInputDefinition` forked onto `EntityContextDefinition` because core's `create()` branches by class (#3582962). * The multiple-flag/list duality that needed its own refinement carve-out (#3583002). ### Proposed resolution Re-parent both families onto typed data in three sequenced issues, one MR each, with roughly a week of overlap and all of it before 1.0. #3583015 lands first: its retyping of the output API onto `OutputDefinitionInterface` is what makes the sequence safe, since all public surfaces then type against our interfaces and the parentage becomes an implementation detail. 1. **\[#3583017\] Re-parent the definition families onto typed data** behind a temporary `ContextDefinitionInterface` bridge. Mechanical; constructors unchanged; schema emission provably unchanged via the matrix snapshots. 2. **\[#3583018\] Store input and output values as typed data** instead of core `Context` objects; retarget the normalizer; move context adaptation into `tool_ai_connector`; attempt removal of the prototype-cache workaround. 3. **\[#3583019\] Remove `ContextDefinitionInterface` from the definition interfaces** — the one coordinated break, about a week after step 1. **What stays: the attribute acceptance shim.** `addInputDefinition()`/ `addOutputDefinition()` accepting a bare core `ContextDefinitionInterface` and converting it (from #3583015) is parentage-independent — it reads the core object's getters and constructs our class — so it is untouched by every step above. Its lifespan is decided in #3583015, not here. **Out of scope, deliberately:** * Redefining `multiple: TRUE` as sugar for a `ListInputDefinition`. The detach makes that future change smaller; the #3583002 refinement rule stays as-is. * Adopting `DataDefinition`'s default-constraint merging in schema emission (`getConstraints()` differs between the parents; see #3583017 ). That is a follow-up where the schema diff gets its own review. ### Remaining tasks * [ ] Land #3583015 (retype + acceptance shim). * [ ] #3583017 , #3583018 , #3583019 in order. * [ ] Follow-up issue: evaluate adopting default-constraint merging in schema emission. * [ ] Coordinate the `ai_automators` conversion in the `ai` queue so it lands within the window. ### AI usage (if applicable) * [x] 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.