## Problem/motivation Follow-up to: #3586202 Review the post-1.0 items. Note that some of them already have issues created. ## Solution Review these and create follow-up issues as needed: ### Selection Pipeline Events The module consumes AI Agents events but does not dispatch its own selection pipeline events. Events such as pre-select, post-select, or post-render could be valuable later, but they also create a backwards-compatibility surface. Existing services, plugins, and hooks are enough for RC1. ### REST or JSON:API Exposure Headless consumers and external agent systems may eventually benefit from REST/JSON:API access to context items or rendered context. This can wait until post-1.0 unless external API access is part of the initial product scope. ### Drush or CLI Tooling Commands for rebuilding scope indexes, auditing context selection, showing candidate matches, or debugging agent context would be useful operational DX. These should wait until the selection and storage APIs settle. ### Broader Service Interfaces Only `AiContextSelectorInterface` is clearly established as a public replacement point. Additional interfaces for resolver, renderer, usage tracking, or request factory could be added later where real substitution needs appear. Avoid freezing speculative abstraction before 1.0. ### Admin List Builder Optimizations `AiContextItemListBuilder::buildRow()` creates scope plugin instances per row and can load parent entities for child rows. This is worth improving for large admin tables, but it is not on the agent prompt path and can be deferred unless large admin lists are an RC1 target. ### Renderer Micro-Optimizations `AiContextRenderer::render()` has token fitting and truncation loops that may be worth profiling later. Current risk is bounded by the selected item set and token limits, so this is post-1.0 unless profiling shows it is a real hotspot. ## Tasks - Review for accuracy - Check existing issues - Create child issues as needed