## Summary Add an AI CKEditor CCC context consumer type on top of the generic consumer plugin API from ai_context#3586346+s. Everything that receives context is a consumer; agents are one type. CKEditor tools are the first non-agent production type owned by an external project. ai_context#3586346+s is on `1.0.x`. The Automator type (ai_context#3586451+s) already proved the as-built contract. This issue is the CKEditor type on that same generic path. The public API is not expected to change. Use as-built names from ai_context#3586346+s. ## Why this lives in AI CKEditor Non-agent types belong in the consuming project. Automators were the documented exception (AI core will not take a Composer or module dependency on CCC). CKEditor is the normal case: - Plugin lives in this project - AI Context discovers it; no AI Context code change is required for the type itself - `ai_ckeditor` does not take a hard dependency on `ai_context` ## Solution approach Either: 1. A small integration submodule (e.g. `ai_ckeditor_context` or `ai_ckeditor_ccc`). Its `info.yml` constrains the AI Context version and `config/install` ships `ai_context.consumer_type_settings.ckeditor`. 2. A lighter alternative — put the plugin in the main `ai_ckeditor` module. There is then no version enforcement and no install-time settings default. `isAvailable()` must be `moduleExists('ai_context')`. Sites that do not use CCC, or do not want this integration, already have off switches: do not enable the submodule or `isAvailable()` is false, the type-wide **Enable this consumer type** flag, and per-instance `push_enabled` (default off). Two different strings: | String | Role | |--------|------| | `ckeditor:{plugin_id}` | CCC consumer ID (config row), e.g. `ckeditor:ai_ckeditor_completion` | | `ai_ckeditor` | Coarse request tag (already emitted today) | | `ai_ckeditor:{plugin_id}` | Instance request tag this MR adds, e.g. `ai_ckeditor:ai_ckeditor_completion` | ## Decisions 1. **The tool is the consumer.** One instance per `AiCKEditor` plugin. Canonical ID `ckeditor:{plugin_id}` (IDs look like `ai_ckeditor_completion`, `ai_ckeditor_tone`, `ai_ckeditor_translate`). Type plugin ID is `ckeditor` (no colon). 2. **No single `ckeditor:default` instance.** Generate, Tone, Translate, and Spell fix must not share one subscription set. Brand voice belongs on Generate / Tone; a glossary belongs on Translate; Spell fix may want almost nothing. 3. **Do not reconstruct the instance from the text format.** Several tools share one editor. The consumer router fails closed on ambiguity. Matching requires the `ai_ckeditor:{plugin_id}` request tag from this module. Do not add a format-only fallback in the plugin. 4. **Instances come from the plugin manager**, not a hardcoded list. Contrib / custom `AiCKEditor` plugins become instances automatically. Skip plugins that never call the provider (`ai_ckeditor_help`). 5. **Push is opt-in.** `getInstanceDefaults()` sets `push_enabled: FALSE`. A row-less tool gets no injection. 6. **First save writes Minimal.** That is the shared non-agent consumer-editor default from ai_context#3586346+s. An unset stored mode still inherits the site default (`relevant`) at runtime. Automatic injection never widens the stored mode. 7. **Chat only.** Image, speech, embeddings, and other `llmType` values never hit the generic subscriber. Streaming chat still does (ProviderProxy). 8. **No agent-only features.** Loop-aware and Debug / Explore stay on `AiContextConsumerTypeAgent`. CKEditor tools do not get Context Tools. 9. **Format-level instances are out of scope.** Tone on Content and Tone on Email share one subscription set in 1.0. A later issue can add `ckeditor:{format}.{plugin}` if sites need it. ## What this ships - `AiContextConsumerType` plugin `ckeditor` (`AiContextConsumerTypeCkeditor`) in the integration submodule or main module - `getRoutingRequestTags()` returns `['ai_ckeditor']` - `resolveConsumerId()` claims a request only when tags include exactly one `ai_ckeditor:{plugin_id}`, that plugin exists and is a real chat tool, and the request is not tagged `ai_agents` or `ai_assistant_api`; otherwise `NULL` (decline). The returned consumer ID is `ckeditor:{plugin_id}` - `getInstances()` from `plugin.manager.ai_ckeditor`, with that manager’s discovery cache tags - `getLabelRoute()` returns `NULL` (tools are configured on each text format; there is no single edit form for a plugin) - Combined push gate already provided by AI Context: instance `push_enabled` AND type `isEnabled()` AND `isAvailable()` - Type settings install + schema (`ai_context.consumer_type_settings.ckeditor`) - Emit `ai_ckeditor:{plugin_id}` on the chat call in `AiRequest::doRequest()` (today the tags are only `['ai_ckeditor']`, so every tool looks identical to CCC) - Keep / attach `entity_context` on the `ChatInput` (`entity_type`, `bundle`, `id`) so Entity Types / Taxonomy / Specific Entities can match. ai#3581952+s landed this on 1.5.x; include it here if the target branch does not already have it. Source it from the existing form / `drupalSettings` path, not URL scraping in the consumer plugin - Docs: matching, Minimal default, `entity_context`, no format-only fallback, streaming, and how to enable the integration - Kernel coverage modeled on the Automator / test consumer types, plus functional coverage that the type appears when the integration is available, is unavailable without `ai_context` (if that gate is used), and push stays off until configured The generic subscriber, consumer listing, editor, invocation result (`AiContextInvocationResult`), and usage `consumer_id` / `consumer_type` fields already exist in AI Context. ## AI CKEditor call-site changes (this MR) `AiRequest::doRequest()` currently calls: `$ai_provider->chat($messages, $ai_model, ['ai_ckeditor'])` That is enough for the type to be *eligible* and not enough to *claim* an instance. Three Generate / Tone / Translate clicks emit the same tag. | # | Change | Why | |---|--------|-----| | 1 | Add `ai_ckeditor:{plugin_id}` to the chat tags | Per-instance matching. The plugin ID is already in scope on the controller. | | 2 | Attach `entity_context` on the `ChatInput` if the target branch does not already | Generic path never uses the route. Without this, Entity Types / Taxonomy / Specific Entities never match. New entities have a NULL id, so an `:entity:` tag is not enough. | Do not add a field / format reconstruction fallback in the consumer plugin. If `ai_ckeditor:{plugin_id}` is missing, decline. No temporary AI Context subscriber is required. This project owns the call site. ## Site-builder path 1. Enable AI Context and AI CKEditor (and the integration submodule if that is how this ships). 2. Enable the **CKEditor** consumer type (Consumer Types). 3. Open **Context consumers**. 4. Edit `ckeditor:{plugin_id}` (for example `ckeditor:ai_ckeditor_completion`). 5. Turn on **Push context automatically**. 6. Subscribe (for example Use Case = Working with Text, Entity Types = `node:article`) and optionally Always / Never include. Next tagged chat run of that tool → tag match → push → system prompt gets the CCC block. CKEditor already sets a system prompt; the subscriber appends and `ProviderProxy` re-applies it. Invocation result lands on event / input metadata (`PUSHED`, `NO_ITEMS`, `PUSH_DISABLED`, `TYPE_DISABLED`, `STALE`, `DECLINED`, `AMBIGUOUS`). CKEditor may surface that later; CCC does not. Pull via `getRenderedContext()` / `getResult()` still works for custom tools. This issue is the automatic push path. ## Limits that stay - **Chat only.** Non-chat operations never hit this subscriber - **Push is opt-in.** No saved row and no `push_enabled` means no injection - **Minimal on first save.** No subscriptions means almost no items, not “all published context” - **Not agent tools.** Loop-aware injection and Context Tools stay on the agent path - **No format-only matching.** Missing `ai_ckeditor:{plugin_id}` declines, even when the coarse `ai_ckeditor` tag is present - **Format-level subscriptions are out of scope.** One Tone row covers every text format - **Help is not a consumer.** It never calls the provider - **2.x off-ramp.** If a tool becomes an agent later, migrate `ckeditor:{plugin_id}` → `agent:{id}` and remove that instance ## Acceptance criteria - [x] `ckeditor` type plugin with the as-built contract (`getRoutingRequestTags()`, `resolveConsumerId()`, `getInstances()`, `getInstanceDefaults()`, `isAvailable()`, `getLabelRoute()`) - [x] Canonical IDs are `ckeditor:{plugin_id}`; type plugin ID has no colon - [x] Instances come from the CKEditor plugin manager, not a hardcoded list - [x] Help / non-chat plugins are not instances - [x] `isAvailable()` is false when the integration cannot work (missing `ai_context` if the plugin lives in the main module) - [x] `push_enabled` defaults false; type `enabled` kill switch works - [x] `resolveConsumerId()` returns `ckeditor:{plugin_id}` when tags include exactly one `ai_ckeditor:{plugin_id}`, or `NULL`; never claims `ai_agents` / `ai_assistant_api` requests - [x] No text-format reconstruction fallback - [x] Chat tags include `ai_ckeditor:{plugin_id}` - [x] `entity_context` is on the `ChatInput` (already from ai#3581952+s, or added here) - [x] No loop-aware or Debug / Explore UI on this type - [x] Type settings install + schema if using a submodule - [x] Docs cover matching, Minimal default, `entity_context`, and format-level out of scope - [x] Kernel + functional tests as above - [x] ai_context#3586452+s updated to point here and close when this lands ## Related issues - ai_context#3586346+s Implement plugin-based generic context consumers - ai_context#3586451+s Create automators context consumer plugin - ai_context#3586452+s Placeholder in the AI Context queue - ai_context#3586319+s Move from agent-specific to generic context consumer API - ai_context#3581955+s [Discuss] Inject context into ai_ckeditor requests - ai#3581952+s Add event hook to ai_ckeditor to allow context injection - ai_context#3586426+s Rotterdam demo step 4 (CKEditor consumer config) - ai_translate#3585523+s AI Translate converting to agents (uses `agent`, not a CKEditor type) ## AI usage - [x] AI assisted issue