## Problem/motivation The module has renamed "current" out of the service layer twice, most recently in #3586442: `ai_context.entity_target_resolver` → `ai_context.current_entity_resolver` → `ai_context.request_info_resolver` The reason: the context that scopes match against is no longer necessarily "current". `AiContextRequestInfoResolver` accepts a caller-supplied page path (`setPath()`) and a programmatically set entity (`setEntity()` / `applyRequestInfo()`), documented as untrusted caller input. A chatbot can deliver context for the page the user is viewing, not the route the request hits. The scope plugin API still says "current", and its implementations already read the request info resolver: - Site Sections' `doGetCurrentValue()` reads `$this->requestInfoResolver->getPath()` — caller-suppliable. - Entity Types' reads `$this->requestInfoResolver->getEntityType()` — caller-suppliable. - Taxonomy Terms' reads the request entity's term IDs. So `matchesCurrentContext()` matches the **request context**, which may not be current at all. The service was renamed for exactly this; the plugin API method names were not, and #3586419's capability methods (`supportsExactMatch()`, `supportsSituationalMatch()`) now reference them prominently in their docblocks. These are public plugin API (`docs/developers/api-stability.md`), so the rename must land **before 1.0.0** or it costs a deprecation cycle. ## Proposed resolution Pure rename, no behavior change, following the #3586276 terminology-sweep pattern (dedicated issue, one commit, a "Beta upgrade" table in `api-stability.md`, no backward-compatibility wrappers). | Old | New | |-----|-----| | `AiContextScopeInterface::matchesCurrentContext()` (+ base, all plugins) | `matchesRequestContext()` | | `AiContextScopeInterface::getCurrentValue()` | `getDetectedValue()` | | `AiContextScopeBase::doGetCurrentValue()` (protected hook, all plugins) | `doGetDetectedValue()` | | `AiContextScopeResolverInterface::filterByCurrentContext()` | `filterByRequestContext()` | | `AiContextScopeResolverInterface::matchesCurrentContext()` | `matchesRequestContext()` | | `AiContextScopeManager::getCurrentContextValues()` | `getRequestContextValues()` | | Request factory parameter `currentEntity` on `getRenderedContext()` / `getResult()` | `requestEntity` | | `AiContextSelector::addCurrentEntityItemCacheability()` (private) | `addRequestEntityItemCacheability()` | Naming rationale: - `matchesRequestContext()` aligns with `AiContextRequestInfoResolver` and `applyRequestInfo()`. - `getDetectedValue()` / `doGetDetectedValue()` use vocabulary the module already owns: the `ai_context.detected_language` cache context (`AiContextDetectedLanguageCacheContext`) and the docs' "contextual detection" language. It also avoids baking "request" into a method whose Language implementation detects from the language manager rather than request info. - `requestEntity` is a **named parameter** in public API examples (`currentEntity: $node`), so this breaks named-argument callers. We are in beta with no production users; break it now rather than carry the inconsistency into 1.0. The change record must call out the named-arguments break explicitly. Explicitly **kept** — "current" is accurate in these: - `AiContextScopeBase::isCurrentManageRoute()` — checks the literal current admin route so the manage link is not shown on its own page. - `$currentUser` everywhere — Drupal core idiom (`current_user` service), and it genuinely is the acting session user. Approximate blast radius (src / tests / docs+api.php occurrences): `matchesCurrentContext` 27/66/13, `doGetCurrentValue` 15/10/3, `getCurrentValue` 3/23/3, `filterByCurrentContext` 6/12/1, `getCurrentContextValues` 2/2/0, `currentEntity` 14/1/6 — roughly 190 lines total, almost all mechanical. ## Remaining tasks - Rename the interface and base-class methods and every implementation (all built-in plugins plus the test-scope modules under `tests/modules/`). - Rename the internal resolver and manager methods and their callers (selector, budget calculator). - Rename the `currentEntity` factory parameter, its interface declaration, and every docs example using `currentEntity:` named arguments. - Sweep docblocks and comments that describe "the current context" where they mean the request context; leave "current" wording that is genuinely about the current route or acting user. - Sweep docs: `scope_api.md`, `custom_scopes.md`, `services.md`, `events.md`, `debugging.md`, `features/scopes.md`, `features/context_selection.md`, and any other `grep -ril matchesCurrentContext docs/` hits. - Add a "Beta upgrade: request-context terminology" section to `api-stability.md` in the established table format, including the named-arguments warning for `requestEntity` and the note that direct interface implementations must rename their overrides. - Update tests mechanically; test method names that embed the old method names (for example `AiContextScopePluginTest` current-value tests) are renamed with them. - Publish a change record. ## UI changes None. ## API changes Public plugin API methods renamed (`matchesCurrentContext()`, `getCurrentValue()`) plus the protected `doGetCurrentValue()` hook and the public `currentEntity` named parameter. No signatures, return types, or semantics change. No backward-compatibility wrappers — beta policy, same as #3586276 and #3586419. Internal resolver/manager renames need no notice. ## Data model changes None. No config, schema, update hook, or stored data is affected; nothing persists these method names. ## Sequencing - After #3586419 (capability split) merges — its docblocks reference `matchesCurrentContext()` and are swept here like everything else. - Coordinate with the other pre-1.0 scope-contract issues (#3586438 weight split, the situational gate alignment follow-up, and the custom-storage Minimal index follow-up) so the plugin interface changes land as a group while the API is still cheap to change. - Must land before 1.0.0; after stable this becomes a deprecation-cycle rename. ## AI usage - [x] AI assisted issue