## Summary The dev chat describes the page to the AI in two request parameters. `current_layout` gives the component tree — component name, UUID and nested slots — and a second parameter, `layout`, gives every component's prop values as a flat map keyed by UUID. Merge the two: each component in `current_layout` carries its own prop values, and `layout` is no longer sent. Also send `current_layout` on file-upload requests, which today send no layout at all. A single parameter that describes both the structure and the content of the page is what an agent needs in order to reason about it — it can read what a region already says before deciding what to add, or which component to change, without joining two payloads by UUID. It also removes the last reason for `layout` to exist: its only remaining readers are the live title-generation and metadata-generation agents, so both it and its `[canvas_ai:layout]` prompt token can be deleted outright once those agents are replaced. Roadmap item 5: https://git.drupalcode.org/project/canvas/-/work_items/3591777 ## Current behavior In `ui/src/components/aiExtension/AiWizardDev.tsx` (added in https://git.drupalcode.org/project/canvas/-/work_items/3591810): - `transformLayout()` (`:573`) builds `{ regions: { <region name>: { nodePathPrefix: [<region index>], components: [...] } } }`. - `processComponents()` (`:590`) builds one entry per component: `{ name, uuid, nodePath, slots? }`. No prop values. - The JSON request branch (`:792`) sends `current_layout`, `layout`, `active_component_uuid`, `page_title` and `page_description`. - The multipart branch, used when the message has an attachment (`:749`), sends `layout` and none of the other four. Tools that need a layout therefore fall back to the last one left in the user's private tempstore by an earlier, unrelated request. - Both helpers take the layout from `currentValuesRef`, a ref that a `useEffect` refreshes after each render — so it holds the layout as of the previous render, not the current store state. Which of these fields the backend reads, in `canvas_ai`: - **`nodePath`, on each component: nothing reads it.** `convertCurrentLayoutToTree()` reads `uuid` and `slots`; `getComponentsByUuid()` reads `uuid`, `name`, `props` and `slots`; `hasChildComponents()` only checks whether a region or slot has any components. The nodePaths that tools return to the UI are calculated by `getCalculatedNodepath()` from the layout the tool predicts, not copied from the request. - **`nodePathPrefix`, on each region: read**, by `CanvasAiPageBuilderHelper::getRegionIndex()` (`:1486`), which the `available_regions` prompt token (`CanvasBuilder.php:231`) and the live `set_template_data` tool depend on. - **`layout`: read** into the `[canvas_ai:layout]` prompt token (`Hook/CanvasAiHooks.php:110`), used by the live title-generation and metadata-generation agents. No other agent or tool reads it. - **`props`, on each component: read** by `getComponentsByUuid()`, which returns each component's id and props keyed by UUID. It returns empty props for every component today, because nothing sends any. ## Proposed Change what `AiWizardDev.tsx` sends to `/admin/api/canvas/ai-dev`: - Each component in `current_layout` carries its resolved prop values, alongside its existing `name`, `uuid` and `slots`. The values are the same ones `layout` carries today. - Drop the `layout` parameter. - Drop `nodePath` from each component. Nothing reads it, and producing it costs a tree walk per component (`layoutUtils.findNodePathByUuid()`, wrapped in a try/catch that logs a console warning when it fails). - Keep `nodePathPrefix` on each region. It looks equally redundant, but live code reads it — see above. - Send the same context fields on both request branches: `current_layout`, `active_component_uuid`, `page_title` and `page_description` are currently JSON-only. On the multipart branch, values that are not strings have to be JSON-encoded, as `derived_proptypes` already is. - Build the layout from the Redux store at the moment the request is sent. The wizard currently reads it from a ref that is one render behind, so a request can describe the page as it was before the most recent change. That gap is invisible today, because a user types for at least one render after editing the page, but the revamped flow will send follow-up requests programmatically (roadmap item 6: several requests per chat turn, each one built right after the previous response's changes have been applied to the page), and then it is the normal case. ## Tests There is no backend change. `AiWizardDev.tsx` has no unit or end-to-end coverage to extend, so verify the change by inspecting the request, per the steps below. ## Acceptance (manual, on a site with `canvas_dev_ai` installed) 1. Send any message from the dev chat and inspect the request body in the browser's network panel: every component in `current_layout` has its prop values, and there is no `layout` parameter and no `nodePath`. 2. Add a component to the page, then change an existing component's prop values. Without reloading, send another message: `current_layout` includes the new component and the changed values. 3. Send a message with a file attached: the multipart body carries `current_layout` with prop values, plus `active_component_uuid`, `page_title` and `page_description`. ## Explicitly out of scope - `AiWizard.tsx` and the `/ai` route, which keep sending `layout` because two live agents read it through the `[canvas_ai:layout]` token. - Removing `nodePathPrefix`, and the `getRegionIndex()` change that would require — live code reads it, and it is cheap to keep sending. - Backend handling of the payload. `CanvasDevAiBuilder` returns a mocked response and reads no request parameters today. - Changes to the tools that read `current_layout`. - Rebuilding the request body for follow-up requests within one chat turn (part of roadmap item 6). Roadmap: https://git.drupalcode.org/project/canvas/-/work_items/3591777 · POC MR: https://git.drupalcode.org/project/canvas/-/merge_requests/1214 _Issue generated with AI assistance._