## Summary Follow-up to #3586617+s (review item 2, [MR !376 note 4390718](https://git.drupalcode.org/project/ai_context/-/merge_requests/376#note_4390718)). `AiContextRequestInfoResolver::getPath()` returns the caller-supplied path before the URL: the `ai_context_path` request attribute, then a posted `path` parameter, then a `path` key in a JSON body, then the referer, and only after those the request URI. `AiContextScopeSiteSection::matchesRequestContext()` hard-filters on that value, for top-level items and, since #3586617+s, for own-scope children too. `AiContextSelector` declares the selection's cache contexts as `ai_context.detected_language`, `user.permissions`, `user.roles`, `url.path`, `route` and `ai_context.entity_item`. Only `ai_context.detected_language` reads the supplied path, and only for its language prefix. Two requests to the same endpoint with different body paths in the same language therefore select different items under identical cache contexts. Nothing in this module stores an `AiContextSelectionResult` keyed by its cacheability today: the prompt subscribers select and use the text in the same request. The gap matters for a consumer that caches a selection or a render array built from it (a block, a cached API response, a decoupled front end that posts the page path to one chat endpoint), and it is the same class of gap the module already closes for the supplied entity with the `ai_context.entity_item` cache context. ## Steps to reproduce 1. Enable subcontext and Site Sections. Create a published item S with Site Sections `custom:/review-section*` and no other scope. 2. As a user who can view it, POST twice to one chat endpoint that pushes context, first with body `path=/review-section/page`, then with `path=/elsewhere/page`. 3. Compare the selected items and the cache contexts of the two `AiContextSelectionResult`s (the cache tags differ per selected item; the contexts are the point). Observed on #3586617+s at `f46f57b` with `drush php:script` cells: request 1 selects S, request 2 drops it; both results carry exactly `languages:language_interface, ai_context.detected_language, user.permissions, user.roles, url.path, route, ai_context.entity_item`. ## Expected result The cacheability of a selection varies by every request input the hard filter reads, so a cached selection or a render array built from it cannot serve the wrong site section. ## Actual result The supplied path changes the selection but not its cache contexts. ## Proposed resolution 1. [x] Add a cache context `ai_context.request_path` (`cache_context.ai_context.request_path`, next to `ai_context.entity_item` in `ai_context.services.yml`) whose `getContext()` returns `AiContextRequestInfoResolver::getPath()` or `none`. 2. [x] Add it to the selector's context list. Keep `url.path` and `route`: the resolver falls back to the URL, and other scopes still vary by route. 3. [x] Kernel test: two requests to one route with different body paths produce different cache context values and, with a Site Sections item, different selections. 4. [x] Document the new context next to `ai_context.entity_item` in the consumer and api-stability docs. Done in the new "Caching a selection result" section of `api-stability.md`; `services.md` and `multilingual.md` also name it. 5. [x] The consumer budget summary also declares `ai_context.request_path`, because its totals fingerprint already reads the resolver's path (found in the opus check of !378). 6. [x] `AiContextDetectedLanguageCacheContext::getCacheableMetadata()` also declares `ai_context.request_path`, because `AiContextLanguageService::detect()` reads the same path for a language prefix (added in !378 and kept after review). ## Questions 1. Should `ai_context.request_path` replace `url.path` instead of joining it? Keeping both is safer: a consumer that caches by the selection's metadata already varies by `url.path`, and dropping it would change existing cache keys. **Decision:** keep both (!378). 2. Does the referer fallback belong in the context value? It is part of what the hard filter reads, so yes unless the fallback is removed. **Decision:** yes. `getPath()` already includes it, so the context covers it (!378). ## Release note Context selection results now vary by a new `ai_context.request_path` cache context, which holds the path that the **Site Sections** scope filters on. That path can come from an `ai_context_path` request attribute, a posted `path` parameter, a `path` key in a JSON body, or a same-site `Referer` on an asynchronous request, and not only from the URL. Before this change, two requests to one endpoint with different supplied paths could select different items but get the same cache keys, so custom code that cached a selection, or a render array built from one, could serve items from the wrong site section. Run `drush cr` after the update so that Drupal registers the new cache context, and make sure that custom code that caches a selection uses all of the selection's cache metadata.