>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3610965. --> Reported by: [joshua1234511](https://www.drupal.org/user/3362218) Related to !17 >>> <h2>Summary</h2> <p>Add a scope plugin that includes a context item when the <strong>AI request carries one of the tags</strong> the item is scoped to. Tags here are the strings the <code>ai</code> module records on a provider call &mdash; set via <code>AiProviderInterface::setTag()</code> / the <code>$tags</code> argument to <code>chat()</code>, and surfaced on the provider request events as <code>AiProviderRequestBaseEvent::getTags()</code> (e.g. an operation type, <code>ai_ckeditor</code>, or a caller-defined tag like <code>ai_empathy_scenario:5</code>).</p> <h2>Problem / motivation</h2> <p><code>ai_context</code> today has a <code>tag</code> scope, but it keys on <strong>taxonomy term IDs</strong> (<code>ai_context_tags</code> vocabulary) matched via agent subscriptions. There is no way to scope a context item to the <strong>runtime AI request tags</strong> the <code>ai</code> module already tracks. Consumers that are not agents (ai_ckeditor, custom callers, ai_empathy evaluations) tag their provider calls but cannot use those tags to select context.</p> <p>Related: #3581955 (inject context into ai_ckeditor requests) matches on entity type/ID; request-tag matching is a complementary mechanism that would let CKEditor (and any consumer) also target context by the operation/tags on the call.</p> <h2>The one design constraint</h2> <p>Context is injected into the prompt <strong>before</strong> the provider request is sent, so a scope cannot wait for <code>ai.pre_generate_response</code> to learn the tags &mdash; by then the input (with context) is already built. The request's tags must be made available to context selection <em>up front</em>. This is the only genuinely new integration required; the rest is a standard scope plugin.</p> <h2>Proposed approach</h2> <ol> <li> <strong>New <code>request_tag</code> scope plugin:</strong> <ul> <li>Selectable tags are an admin-defined list on the scope's settings form (mirrors the <code>entity_bundle</code> scope), rendered as checkboxes on each context item. Values are plain tag strings, not taxonomy term IDs.</li> <li><code>supportsSubscriptions()</code> stays TRUE, so items are matched by intersecting the request's tags with the item's selected tags through the existing resolver scoring; <code>doGetCurrentValue()</code> returns NULL (no ambient page value).</li> </ul> </li> <li> <strong>A supported way for callers to declare the request's tags</strong> &mdash; pick one: <ul> <li><strong>(a) Recommended:</strong> add a <code>requestTags</code> field to <code>AiContextRequest</code> (and a param on <code>AiContextRequestFactory::fromParameters()</code> / <code>getRenderedContext()</code>) that callers populate. Simple and explicit; reuses the existing <code>scopeSubscriptions</code> machinery; no changes to the <code>ai</code> module.</li> <li><strong>(b) Alternative:</strong> a request-scoped "current AI request tags" collector, populated where callers call <code>$provider-&gt;setTag()</code> and, where the flow allows, from <code>ai.pre_generate_response</code>. More automatic but heavier.</li> </ul> </li> </ol> <h2>Working prototype</h2> <p>A functioning implementation already exists in the <code>ai_empathy_ccc</code> submodule of the <code>ai_empathy</code> project and can be lifted into ai_context:</p> <ul> <li><code>AiContextScopeRequestTag</code> &mdash; the scope plugin (admin-defined tag list + checkboxes; subscription matching; <code>ai_context.scope_settings.request_tag</code> config).</li> <li>The empathy evaluator surfaces its request tags (<code>ai_empathy</code>, <code>ai_empathy_scenario:&lt;id&gt;</code>, <code>ai_empathy_run:&lt;n&gt;</code>) on its prompt-alter event, and the subscriber passes them via <code>getRenderedContext(scopes: ['request_tag' =&gt; $tags])</code>.</li> <li>A kernel test proves that with <code>SELECTION_MODE_MATCH_ALL</code> (as <code>getRenderedContext()</code> uses), a <code>request_tag</code> subscription <strong>restricts</strong> inclusion to matching items (plus globals) &mdash; it does not merely reorder &mdash; confirming the resolver already supports this end-to-end.</li> </ul> <p>Moving it upstream mainly requires deciding mechanism (a) vs (b) so any consumer &mdash; agents, ai_ckeditor &mdash; can declare request tags, not just ai_empathy.</p> <h2>Proposed resolution</h2> <ul> <li>Add <code>AiContextScopeRequestTag</code> plugin + settings form + config/schema.</li> <li>Decide (a) vs (b) and expose request tags to selection.</li> <li>Kernel test for tag-restricted inclusion; update docs (custom scopes).</li> </ul> <h2>Related issues</h2> <ul> <li><a href="https://git.drupalcode.org/project/ai_context/-/work_items/3586319">https://git.drupalcode.org/project/ai_context/-/work_items/3586319</a></li> <li><a href="https://git.drupalcode.org/project/ai_context/-/work_items/3581955">https://git.drupalcode.org/project/ai_context/-/work_items/3581955</a></li> <li><a href="https://git.drupalcode.org/project/ai_context/-/work_items/3586237">https://git.drupalcode.org/project/ai_context/-/work_items/3586237</a></li> </ul>