**Follow-up to:** #3580910+s ## Problem General settings (`ai_context.settings`) and per-agent overrides (`ai_context.agents`) expose two related limits: - **Max global context items** (`max_global_items`, range 0–10) - **Max context items to inject** (`max_items`, range 1–20) Each field is validated independently (`Range` in schema; `#min`/`#max` on forms). Nothing enforces that `max_global_items <= max_items`. The general settings form already tells admins that global items count toward the total cap, but invalid combinations can still be saved—for example `max_global_items = 10` and `max_items = 5`. For agent overrides, the gap is similar: an agent can set only one cap and inherit the other from site defaults, producing an effective configuration where the global cap exceeds the total cap even though each stored value looks valid on its own. ## Current behavior Runtime selection copes: `AiContextSelector` caps globals during candidate loading, then `mergeByPriority()` slices the merged list to `max_items`. So a high global cap with a lower total cap does not break injection, but globals (and other lower-priority groups) may be dropped silently at merge time. That makes the configured global limit misleading and hard for site builders to reason about. ## Solution Add cross-field validation so the effective global cap cannot exceed the effective total cap. ### General settings (`ai_context.settings`) - Custom `AiContextLimits` schema constraint on the config object (with existing `FullyValidatable`). - Form validation via `ConfigFormBase` and `#config_target` on `AiContextSettingsForm`. ### Agent overrides (`ai_context.agents`) - Same `AiContextLimits` constraint on each agent mapping in config schema. - Validation in `AiContextAgentForm` via shared typed-config validation. - Effective limits resolved through `AiContextLimitResolver` (agent override → site settings → `AiContextRequest` defaults), so partial overrides are validated against inherited defaults—not only when both caps are explicitly set on the agent. - `Range` constraints added to agent `max_global_items`, `max_items`, and `max_tokens` to match site settings schema bounds. ### Configuration import - `AiContextConfigImportValidateSubscriber` validates both `ai_context.settings` and `ai_context.agents` during import. - Settings: typed schema validation. - Agents: typed schema validation plus effective-limits checks (including staged settings when both config objects are in the same import). ### Tests Kernel and unit tests cover: - Schema validation (settings and agents) - Settings form validation - Agent form validation (explicit caps, partial overrides, out-of-range values) - Config import validation (invalid combinations, partial overrides, range violations) ## Acceptance criteria - [ ] Saving general settings with `max_global_items > max_items` is rejected with a clear validation message. - [ ] Importing config with the same invalid combination fails validation. - [ ] Per-agent overrides reject `max_global_items > max_items` when both limits are set on the agent. - [ ] Per-agent overrides reject invalid effective combinations when only one cap is overridden and the inherited value would violate the rule. - [ ] Agent overrides reject out-of-range values for `max_global_items`, `max_items`, and `max_tokens` (schema `Range` parity with site settings). - [ ] Valid combinations (including `max_global_items = 0`) still save successfully. - [ ] Kernel tests cover valid/invalid cases for general settings, agent form, and config import. ## Out of scope **Direct programmatic config writes** (`$config->save()`, `drush config:set`) are not blocked. Drupal core does not run constraint validation on ordinary simple-config saves; validation is expected on supported paths (forms, import, config actions). Blocking direct saves would require a post-save subscriber with revert-on-failure logic, which is uncommon in contrib and adds edge cases around config import and `hook_update_N()`. Runtime clamping in `AiContextRequestFactory::resolveLimit()` remains the safety net for any invalid values that reach active storage through admin bypass. ## Notes - Pre-existing gap; intentionally deferred from the settings validation / `#config_target` MR (#3580910). - Runtime behavior in `AiContextSelector::mergeByPriority()` is unchanged; this issue is about admin UX and config integrity, not selection semantics. - Constants live in `AiContextRequest` (`MIN/MAX_MAX_GLOBAL_ITEMS`, `MIN/MAX_MAX_ITEMS`, etc.). ## AI usage - [x] AI assisted issue - [x] AI assisted code