### Problem/Motivation Every serious bug found this release cycle — the `getOutputValue()` throw on optional outputs (#3582954), the multi-value validation early-return, the configuration-source fatal, the coercion regressions — lived in `TypedInputsTrait`/`TypedOutputsTrait`, in paths with no test coverage. These traits are the API being frozen at RC1; untested frozen behavior is behavior we cannot safely refactor later. **Scope note:** the RC1 fix issues each carry their own tests — config-source precedence (config-value issue), multi-value item validation (validation issue), access-on-invalid-input (access issue), signature-batch behaviors, cacheability. This issue covers only the remaining untested paths, so nothing is double-booked. ### Untested paths to cover **TypedInputsTrait — configuration/locked half:** - Locked inputs: `setInputValue()` on a locked input throws `InputException`; locked value always wins in `getExecutableValue()`. - `setConfigurationValue()` with an invalid value throws; `defaultConfiguration()` shape. - `setInputDefinitions()` value migration (existing set values surviving a definitions swap). **Input-definition refiner flow (most complex untested logic in the module):** - A fixture implementing `InputDefinitionRefinerInterface` (e.g. an `entity_type` input refining a `bundle` input's Choice constraint); assert `setInputValue()` triggers refinement, and the revert-on-violation branch. **InputDefinition factory pipeline:** - `fromConfigSchema()`: mapping → `MapInputDefinition`, sequence → `ListInputDefinition`, wrapped/scalar types, required flags, defaults. - `fromDataDefinition()` equivalents. **TypedOutputsTrait remainder:** - `validateOutputs()` (currently invoked by nothing in tests): violations from an invalid set output; clean pass. - `setOutputValue()` against a mismatched definition. **Adapters (stretch goal, or split if large):** the `src/Plugin/tool/TypedData/Adapter/*` classes (\~1,300 lines) are exercised only indirectly; a form-layer kernel test driving `ExecuteToolPluginForm` through `buildConfigurationForm()`/`extractFormValues()` for each adapter would cover both at once — coordinate with the tool_explorer functional test (explorer cleanup issue) to avoid overlap. ### Proposed resolution One MR of kernel tests + the small `tool_test` fixtures they need (refiner fixture, config-schema fixture). No production code changes expected; anything a new test flushes out gets its own bug issue. ### Remaining tasks - [ ] Locked/configuration tests - [ ] Refiner flow fixture + tests - [ ] fromConfigSchema/fromDataDefinition tests - [ ] validateOutputs tests - [ ] Adapter coverage decision (here, or split, or via the explorer functional test) ### 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. - [ ] **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.