CCC's automator consumer (ai_context#3586451+s) matches on the generic PreGenerateResponse path from ai_context#3586346+s. It cannot reconstruct the instance from entity type + bundle + field. Multiple automators on one field is a supported automator setup (Field Widget Actions: Default / Short summary / Bullet outline on the same body field). Those three clicks emit the same field/bundle/entity tags today, so CCC cannot tell them apart. Automator chat calls already emit `ai_automator` plus type / entity / bundle / field tags (#3515518+s). The config entity ID is in scope (`$field->id()`) and then dropped. `entity_context` is not attached to the ChatInput. Until this lands, CCC may use a temporary subscriber. That workaround is reliable only when there is **one automator per field**. It will not add a field/bundle fallback. CCC matches only on `ai_automator:id:{id}`. This is not #3586638+s (tag registry). This issue is emission at request time. ## What the tags look like today Clicking any of three automators on `node.blog.field_content` sends the same list, for example: ``` ai_automator ai_automator:type:llm_textarea ai_automator:entity_type:node ai_automator:entity:123 ai_automator:bundle:blog ai_automator:field_name:field_content ``` Missing: which automator ran. On an unsaved entity, `ai_automator:entity:` is empty / NULL. Certain CCC scope plugins like Entity Types, Taxonomy, and Specific Entities still have nothing structured to read because `entity_context` is not on the ChatInput. ## What it should look like after this issue Click on "Bullet outline" (`node.blog.field_content.bullet_outline`) must also include: ``` ai_automator:id:node.blog.field_content.bullet_outline ``` "Default" and "Short summary" on that same field must emit their own config IDs. The rest of the existing tags can stay. And `RuleBase::runRawChatMessage()` must attach `entity_context` on the ChatInput, using the accepted aliases (`entity_type` + `entity_id`). Presave entities often have a NULL id; the `:entity:` tag is not enough for CCC scopes. ## Tasks - [ ] `AiAutomatorEntityModifier::entityHasConfig()` must put `'id' => $field->id()` on `$automatorConfig`. - [ ] `RuleBase::getTags()` must emit `ai_automator:id:{id}`. - [ ] `RuleBase::runRawChatMessage()` must attach `entity_context` on the `ChatInput`. - [ ] Kernel or unit test: two automators on one field emit different ID tags for the same entity/bundle/field tags. - [ ] Kernel or unit test: `entity_context` is present on the ChatInput, including presave (NULL id) using entity_type + the available id/uuid. ## How to test 1. On one field (e.g. blog Content), create three automators: Default, Short summary, Bullet outline. Confirm three FWA buttons render and each button still runs the right automator (already true after #3571915+s). 2. Trigger each button (or the same chat path in a kernel test) and inspect `$event->getTags()` / provider tags. - Today: all three lists match except nothing identifies the instance. - After: each list includes a distinct `ai_automator:id:{that automator id}`. 3. Inspect the ChatInput: `entity_context` is set. For a saved node, type + id are populated. For a new unsaved node, type is set and id may be empty; do not rely on `ai_automator:entity:` alone. 4. Optional with CCC ai_context#3586451+s: give each automator its own Always include fingerprint. Click each button. Only that automator's fingerprint is pushed. This is the consumer-side proof; the automator tests above are enough to close this issue. ## Out of scope - Tag normalization for untagged chat call sites (Boolean, Chart, VideoToText, `LlmVideo*`, FWA refine, image / speech / embeddings) - `RuleBase` structured-schema call-site bug (no in-tree rule uses it) - The CCC `automator` plugin itself (ai_context#3586451+s) - Tag registry / discoverability (#3586638+s) ## Related issues - ai_context#3586451+s - ai_context#3586346+s - #3515518+s - #3571915+s - #3586638+s ## AI usage - [x] AI assisted issue