Architectural review with grok 4.6 after discussing this issue #3586405+s Option 2 fixes the Field API hole. These are the other production smells that can still bite — especially recipes, selection, and anything that does not go through the item form. Verified in `src/`, hooks, install, and shipped config. Docs and tests were skipped. ## Same class as the map (already in the new issue) - Core `map` on `scope` + Default Content subscriber - Denormalized `ai_context_item_scope_index` (keep it; it stores **effective** / inherited scope, not the raw field) - `entity_items` stays DER — recipes can set it, but it is a second store ## Will still bite after Option 2 **1. Empty scope means “match every subscription” (high)** In `AiContextScopeResolver::calculateScopeScore()`, an item with no values for a subscribed scope gets full weight as “generic context.” A published recipe item with no `scope` rows is not inert — it can be selected for every agent. The entity `preSave()` already knows this (it unpublishes detached inheriting children for that reason). Option 2 does not fix the rule. Recipes must set scope or stay unpublished. **2. Global cap is skipped on sync/import (high)** `AiContextItemStorage::doPreSave()` drops the cap violation when `isSyncing()` is true, so recipes and migrations can create more stored-global items than `max_global_items`. The selector then silently rank-limits. Fine for upgrades; surprising for a demo recipe on a site that already has globals (this Chicago/FinDrop site). **3. `inherit_parent_scope` has two defaults (medium)** Field default is `FALSE`. The item form defaults new subcontexts to `TRUE`. `inheritsParentScope()` still has a NULL heuristic for old rows. Recipe/API `create(['parent' => …])` does **not** inherit unless the flag is set. `preSave()` then **wipes** the child’s own scope and `entity_items` when inheriting. **4. Shipped form display is stale (medium)** `core.entity_form_display.ai_context_item.ai_context_item.default.yml` still has a `tags` autocomplete. There is no `tags` field. Tags live in the scope map. `scope`, `entity_items`, and `inherit_parent_scope` are omitted because the real UI is a custom `context_scope` tree in `AiContextItemForm`. REST, ECA, and “edit this field” UIs will not see scope. Recipes that set fields directly are fine; anything that trusts form display is not. **5. Agent subscriptions are not on the item (known, Step 2)** `ai_context.agents` config is a second copy of scope value IDs. Item recipes cannot wire consumers. Cleanup has to touch content and config. Not a field-type bug. ## Architectural smells (extenders and later releases) **6. `supportsSubscriptions()` is still overloaded (high)** The interface documents both meanings: hide on the agent form, **and** treat `FALSE` + `matchesCurrentContext()` as auto-include. Selector, resolver, and index all branch on it. #3586243 wanted to split this and deferred it. A custom scope that gets the flag wrong changes UI and runtime with no error. **7. Stored vs effective scope (medium)** `getScope()` is this item. `getScopeItem()` / `isGlobal()` follow the parent. Cap, edit form, and persistence use stored. Selection and the index use effective. Easy to “save” scope on a child and have `preSave()` clear it. **8. Usage `tools_used` / `routes` are JSON in `string_long` (medium, smaller blast)** Same blob instinct as `map`, on `AiContextUsage`. Views needs a custom JSON field plugin. Usage is runtime log data, not recipe content, so this is not a 1.0 blocker. Do not copy the pattern onto more content fields. **9. Selection cache may miss scope-settings config (medium)** Selector tags the item list and general settings. Changing `ai_context.scope_settings.*` (enable a scope, site-section patterns, tag vocabulary) may not bust selection cache until something else invalidates the item list. **10. Request body can set “current entity” (medium, security-adjacent)** `AiContextCurrentEntityResolver` accepts POST/JSON `entity_type` + `entity_id` after a type-exists check, not an entity access check. Items still need view access, but a client can steer **which** targeted context applies. Worth a dedicated follow-up, not this field issue. **11. Conditional subcontext is non-deterministic (medium)** `purpose` is a real field. Inclusion of conditional children is an AI call. Same recipe, different runs. Demo scripts should not depend on a specific child appearing. **12. `token_count` is denormalized (low–medium)** Recomputed on save and also written with raw SQL during backfill. Recipes should not author it. Drift until cron/backfill is expected. ## What I would not open another freeze-exception for - Static `\Drupal::` in the entity class (normal Drupal) - Index not storing revisions (by design) - Hidden candidate ceilings in the selector (tune later if catalogs get huge) - `getRenderedContext()` defaulting to `match_all` (documented consumer API) ## Practical takeaway Option 2 is the right Field API fix. It does **not** make recipes safe by itself. For #3586385 after this lands: every published item needs explicit `scope` deltas; do not rely on “no scope” as optional. Set `inherit_parent_scope` explicitly on any child. Do not apply a Global recipe on a site that already has three globals. Agent wiring stays a separate config recipe. Follow-ups I would file **after** the field swap, not inside it: split `supportsSubscriptions()` (#3586243 leftover), fix the stale `tags` form display, add cache tags for scope-settings config, and review the request-body entity hint.