@plitzi/sdk-mcp 0.37.2 → 0.37.3

package/dist/modules/mcp/helpers/guide.js

@@ -1,5 +1,8 @@
+import { BUILTIN_TRANSFORMERS, GLOBAL_SOURCES } from "@plitzi/sdk-authoring";
 //#region src/modules/mcp/helpers/guide.ts
-var serverInstructions = "Plitzi AI server: read-then-write editing of a Plitzi space. Reads follow a filesystem model — list cheap, read one item in detail on demand; never fetch a whole tree you do not need. Workflow: (1) read plitzi://primer/{env} once — it bundles the guide, types, css-properties and page/definition/variable summaries in a single call; (2) plitzi_search with include:\"detail\" to jump to elements — each hit then carries its uri, stateVersion AND full style/resolvedStyle, so an edit needs no per-element read; open a page skeleton or element only when you need its tree/detail (the skeleton already lists the style classes of each node, and plitzi_read fetches many uris at once); (3) plitzi_apply with dryRun to preview a batch; (4) plitzi_apply to persist, passing expectedResourceVersions to guard against concurrent edits — apply and search both hand back the versions you need for the next edit. Use patchElement / patchDefinition to change only some props / CSS (the upsert variants replace them all). An element read (and search include:\"detail\") inlines the CSS of the definitions it attaches under resolvedStyle, so you rarely need a separate definition read. Every element has ONE name and it IS its id ([A-Za-z0-9_-] starting with a letter, unique, chosen by you) — the same name is the runtime wiring key, so a provider source is `<type>_<name>.<field>`, visible to the provider’s DESCENDANTS only (bind inside its subtree). CSS is plain kebab-case — write shorthands freely (`border: 1px solid red`, `padding: 8px 16px`, `font: bold 16px/1.5 Arial`), they are expanded to longhands for you and STORED that way, so read-back shows the longhands; style vars are var(--name), schema vars are {{name}}. READERS — do not confuse them: MCP *resources* are the browsable catalog (list them, or open one by URI); plitzi_search FINDS elements by label/type/attribute and hands you the name to write ops against; plitzi_read BATCH-fetches URIs you already hold. Reach for search/read to work; browse resources to discover. CMS / API integrations (Strapi, WordPress, Contentful, any REST service) go through a CONNECTOR: a manifest you author declaring the base URL, endpoints and auth template, which the SERVER executes — read plitzi://connector-presets for working ones and plitzi://connectors/{env} for this space’s. You never see or create the credential; the space owner attaches it, and the connector saves without one. An apiContainer reads through it only with runtime:\"server\". Elements also carry applied style variants + visibility (initialState), data bindings and interaction flows: edit them with patchElement (initialState), upsertBinding/patchBinding/deleteBinding, and upsertInteractionFlow/patchInteractionNode/deleteInteraction. An element read shows all three plus availableVariants (which variant each of its classes offers). Separately, to SHOW the user a small self-contained widget (offline, no space or backend) instead of editing the space — a card, hero, pricing table, a visual answer — use plitzi_render; read plitzi://render/guide for it.";
+var GLOBALS = GLOBAL_SOURCES.map((source) => `\`${source}\``).join(", ");
+var OTHER_TRANSFORMERS = Object.keys(BUILTIN_TRANSFORMERS).filter((action) => action !== "twigTemplate").map((action) => `\`${action}\``).join(", ");
+var serverInstructions = "Plitzi AI server: read-then-write editing of a Plitzi space. Reads follow a filesystem model — list cheap, read one item in detail on demand; never fetch a whole tree you do not need. Workflow: (1) read plitzi://primer/{env} once — it bundles a quickstart of the guide, types, css-properties and page/definition/variable summaries in a single call; (2) plitzi_search with include:\"detail\" to jump to elements — each hit then carries its uri, stateVersion AND full style/resolvedStyle, so an edit needs no per-element read; open a page skeleton or element only when you need its tree/detail (the skeleton already lists the style classes of each node, and plitzi_read fetches many uris at once); (3) plitzi_apply with dryRun to preview a batch; (4) plitzi_apply to persist, passing expectedResourceVersions to guard against concurrent edits — apply and search both hand back the versions you need for the next edit. Use patchElement / patchDefinition to change only some props / CSS (the upsert variants replace them all). An element read (and search include:\"detail\") inlines the CSS of the definitions it attaches under resolvedStyle, so you rarely need a separate definition read. Every element has ONE name and it IS its id ([A-Za-z0-9_-] starting with a letter, unique, chosen by you) — the same name is the runtime wiring key, so a provider source is `<type>_<name>.<field>`, visible to the provider’s DESCENDANTS only (bind inside its subtree). CSS is plain kebab-case — write shorthands freely (`border: 1px solid red`, `padding: 8px 16px`, `font: bold 16px/1.5 Arial`), they are expanded to longhands for you and STORED that way, so read-back shows the longhands; style vars are var(--name), schema vars are {{name}}. READERS — do not confuse them: MCP *resources* are the browsable catalog (list them, or open one by URI); plitzi_search FINDS elements by label/type/attribute and hands you the name to write ops against; plitzi_read BATCH-fetches URIs you already hold. Reach for search/read to work; browse resources to discover. CMS / API integrations (Strapi, WordPress, Contentful, any REST service) go through a CONNECTOR: a manifest you author declaring the base URL, endpoints and auth template, which the SERVER executes — read plitzi://connector-presets for working ones and plitzi://connectors/{env} for this space’s. You never see or create the credential; the space owner attaches it, and the connector saves without one. An apiContainer reads through it only with runtime:\"server\". Elements also carry applied style variants + visibility (initialState), data bindings and interaction flows: edit them with patchElement (initialState), upsertBinding/patchBinding/deleteBinding, and upsertInteractionFlow/patchInteractionNode/deleteInteraction. An element read shows all three plus availableVariants (which variant each of its classes offers). Build pages people can use without sight: screen readers and browser agents (Claude in Chrome) work a page through its accessibility tree, so every control needs words and clicks go on buttons and links — see Accessibility in plitzi://guide, and plitzi_screenshot view:\"accessibility\" to check. Separately, to SHOW the user a small self-contained widget (offline, no space or backend) instead of editing the space — a card, hero, pricing table, a visual answer — use plitzi_render; read plitzi://render/guide for it.";
 var widgetsOnlyInstructions = "Plitzi widget server (widgets-only connection). This connection carries NO Plitzi space: nothing can be read or edited in one, and the space tools are not offered here — do not look for them. What it does do is build self-contained UI widgets fully offline, with no backend, account or setup: call plitzi_render to SHOW the user a real rendered layout (card, hero, pricing table, checklist, form, gallery) instead of describing one. Read plitzi://render/guide first — the element/prop table, the style model and a worked example; plitzi://render/types lists every element type you can author (plitzi_read fetches both). To change a widget you already rendered, call plitzi_render again with patch:true and its renderId. If the user wants to edit their real Plitzi space from here, that is a reconnection they make: the integration must be re-authorized and granted a space (the consent screen lists theirs) — you cannot do it from this connection, and no retry will change it.";
 var guideQuickstart = `# Plitzi AI MCP — quickstart
 This is the condensed guide; read \`plitzi://guide\` for the full reference (every resource, op and example).
@@ -35,7 +38,7 @@ still \`display: flex\` + \`flex-direction\`/\`align-items\`/…, not a \`flex\`
 
 **Data bindings** (\`upsertBinding\`, category attributes|style|initialState): connect a \`source\` to a \`to\` field.
 A source \`<type>_<name>\` is scoped to the provider's **DESCENDANTS only** — bind inside the provider's subtree
-(module sources state/space/navigation/auth/collection are global). \`apiContainer.mockData\` is builder-only; set a
+(the global sources ${GLOBALS} are bindable anywhere). \`apiContainer.mockData\` is builder-only; set a
 real \`query\` for production. \`transformers: [{action, params}]\` post-process the value — use exact action names
 from \`plitzi://data-sources\`; \`twigTemplate\` formats it (the value is \`{{source}}\`, not \`{{value}}\`). \`when\` is
 a QueryBuilder RuleGroup gating the binding.
@@ -46,6 +49,8 @@ computed for you). Node types: \`callback\` (an element's own callback — \`ele
 (category/key/value/revertOnFinish) ≠ global \`setState\` (source \`state\`, key/type/value). To turn a step off use
 \`patchInteractionNode {enabled:false}\` — \`deleteInteraction\` removes it (destructive; confirm first). Any param
 **value** can be a binding token \`{{ source }}\` (e.g. notification \`content: "{{ list_<name>.item.name }}"\`).
+Steps read the page as it is when they run; a refiring trigger is ignored unless \`whileRunning: "queue"\`; keyboard
+shortcuts are the \`onKey\` trigger (\`keys: "shift+f, escape"\`).
 
 **CMS / API integrations** (\`upsertConnector\`): a **connector** is a manifest declaring a provider's base URL,
 endpoints, auth template and filter operators, executed by the **server** — so integrating Strapi, WordPress,
@@ -62,11 +67,16 @@ slugs prepend the path). A \`:name\` segment (\`"posts/:postId"\`) is a route pa
 source \`navigation.routeParams.name\` → build dynamic pages this way. To move between pages **prefer the \`Link\`
 element** (a container: \`mode\` "page"/"internal"/"external") over a \`navigate\` interaction.
 
-**Touched resources must be malformation-free.** Editing an element/definition also checks its CURRENT stored content
-and BLOCKS the save on any \`Pre-existing malformation in <resource>\` error (a broken transformer, malformed node,
-invalid CSS) — even parts you did not touch. These are NOT from your change (the message says so); fix them in the
+**Accessible by default:** screen readers and browser agents (Claude in Chrome) read the accessibility tree, so every
+button/link needs words (an icon-only button a \`title\`), every field a \`label\` (\`hideLabel: true\` hides it), every
+image an \`alt\` or \`decorative: true\`; clicks go on a \`button\`/\`link\`, never a container; headings step down one
+level at a time. \`plitzi_screenshot view:"accessibility"\` shows the tree and what has no name.
+
+**Touched elements must be malformation-free.** Editing an element also checks its CURRENT stored content and BLOCKS
+the save on any \`Pre-existing malformation in element …\` error (a broken transformer, a malformed step, an attribute
+it never reads) — even parts you did not touch. These are NOT from your change (the message says so); fix them in the
 SAME batch and re-apply (the check runs on the result, so the fix unblocks it). \`Pre-existing issue\` warnings advise
-but do not block.
+but do not block. A broken tree your batch leaves ANYWHERE (an element orphaned by a delete) blocks it too.
 
 Read \`plitzi://guide\` before anything above is unclear.
 `;
@@ -101,6 +111,8 @@ Never download a whole tree you do not need.
   \`link\` navigates between pages, \`list\` repeats a template over a data array. \`plugin\` types are custom elements.
 - \`plitzi://css-properties\` — valid kebab-case CSS property keys.
 - \`plitzi://schema/{env}/pages\` — page **summaries** (ref, label, elementCount, folder). No element trees.
+- \`plitzi://schema/{env}/layouts\` — the shared **layout shells** (header/sidebar/footer) and the pages rendered
+  inside each. Read one like a page. See *Shared layouts* below.
 - \`plitzi://folders/{env}\` — page **folders** (the sidebar tree): ref, name, slug, parentId. \`/{ref}\` for one.
 - \`plitzi://schema/{env}/pages/{ref}\` — one page as a **skeleton tree**: each node is \`ref/type/label\` **plus the
   style classes it attaches** (\`base\`, and \`slots\` for non-base slots) — names only, no CSS. So you can map every
@@ -119,6 +131,7 @@ Never download a whole tree you do not need.
 - \`plitzi://global-styles/{env}\` — element **types** that have a site-wide global style. \`/{componentType}\` for one.
 - \`plitzi://id-styles/{env}\` — DOM **ids** that have an id rule (\`#id\`) targeting a single element. \`/{targetId}\` for one.
 - \`plitzi://style-variables/{env}\` — design tokens by category. \`/{category}\` for one.
+- \`plitzi://fonts/{env}\` — the font **families the space loads**, with their source and fallback. \`/{family}\` for one.
 - \`plitzi://schema-variables/{env}\` — space-level values referenced in props as \`{{name}}\`.
 - \`plitzi://settings/{env}\` — space-level settings: the global \`customCss\` and the state/auth (user-provider) config.
 - \`plitzi://interactions/{env}\` — interaction **actions** observed in this space (grouped by node type): the
@@ -132,6 +145,16 @@ Never download a whole tree you do not need.
   filter operators and its published fields. \`/{ref}\` opens one manifest in full. See *Connectors* below.
 - \`plitzi://actions/{env}\` — the **server actions this space has**: what starts each one, who may run it, and the
   input/output contract a caller is held to. \`/{ref}\` opens one flow in full. See *Server actions* below.
+- \`plitzi://actions/{env}/tasks\` — the **server tasks this deployment can run**, each with its params: the steps an
+  action may be built from.
+- \`plitzi://functions/{env}\` — the space's **functions**, its own server code: which files, and the tasks, routes and
+  hosts they declare. \`plitzi://functions/{env}/{+path}\` reads one file whole. See *Functions* below.
+- \`plitzi://changes/{env}\` — the space's **change history**, read-only and newest first: who made each change (a
+  person in the builder, an agent, the autofix), when, and every element, class, token or font it touched, whole, before
+  and after. \`/{id}\` for the history of one of them — how you find what changed an element you are asked about, or
+  review what you or another agent just did.
+- \`plitzi://render/guide\`, \`plitzi://render/types\` — the manual and the type table for \`plitzi_render\` (offline
+  widgets, not this space).
 
 The style resources also answer under the \`plitzi://schema/{env}/…\` root as aliases — \`plitzi://schema/{env}/definitions/{ref}\`, \`plitzi://schema/{env}/style-variables/{category}\`, \`plitzi://schema/{env}/schema-variables\` — but prefer the ready-made \`uri\` from search / a write response over hand-building either form.
 
@@ -161,7 +184,7 @@ element read is the exception. Search also matches **pages** by name/slug (retur
 stateVersion) and returns any **style definitions** whose name matches the query, with full CSS, under \`definitions\`.
 When you do hold several refs to open (e.g. from a skeleton), read them together with \`plitzi_read\` rather than one at a time.
 
-## Tools (write)
+## Tools
 - \`plitzi_validate\` — check a batch, returns teachable errors/warnings. Writes nothing. Also reports **pre-existing
   malformations** in any resource the batch touches (see below).
 - \`plitzi_apply\` — validate → apply → persist atomically. Rejects the whole batch on any error or conflict. Pass
@@ -171,6 +194,13 @@ When you do hold several refs to open (e.g. from a skeleton), read them together
 - \`plitzi_read\` — read many resource **uris in one batch** (pages, elements, definitions, variables). Pass the
   ready-made uris from search / a write response; each result is \`{ uri, stateVersion, data }\` or a teachable error,
   so one bad uri never fails the batch. Use it instead of N single reads whenever you already hold several refs.
+- \`plitzi_preview\` — render a page to HTML, optionally with unsaved \`operations\` applied, to check structure.
+- \`plitzi_screenshot\` — render a page to a PNG (desktop, mobile or \`both\`), optionally with unsaved \`operations\`:
+  the way to SEE overflow, misalignment and broken layout before you commit. \`view: "accessibility"\` reads the same
+  page as a screen reader and a browser agent (Claude in Chrome) do — its accessibility tree as an outline of roles and
+  names, with every control and picture that has no name listed in \`unnamed\` — as text, far cheaper than an image
+  (\`"both"\` returns both). Both need the SSR render service; where it is missing they answer \`PREVIEW_UNAVAILABLE\`.
+- \`plitzi_render\` — a different job: show the user a self-contained widget built offline. It never touches the space.
 
 ## Readers: resources vs plitzi_search vs plitzi_read (do not confuse them)
 Three ways to read, each for a different moment — pick by what you have in hand:
@@ -215,6 +245,15 @@ reports it only when it is set.
 every interaction target across the space that named the old one is repointed with it, so nothing comes unwired.
 You do not have to rewrite them.
 
+## Elements — create, move, delete
+- \`upsertElement\` creates an element (or replaces one by name) under \`parentRef\` — the page root when omitted — and
+  builds a whole subtree in one op through nested \`children\`. \`patchElement\` changes an existing one in place.
+- \`moveElement { pageRef, ref, toParentRef, position }\` moves or reorders one: \`position\` \`"inside"\` (the default)
+  nests it in \`toParentRef\`; \`"before"\`/\`"after"\` make it that element's sibling. Its subtree moves with it.
+- \`deleteElement { pageRef, ref }\` removes an element **and everything under it**. A binding or an interaction
+  elsewhere that named one of them is left pointing at nothing, and the save reports it — delete them in the same
+  batch. Destructive: confirm first.
+
 ## Styling (crosses both schemas)
 - **Mind the type's intrinsic default style.** A type renders with a base CSS *before* any class is attached — read
   it from \`defaultStyle\` on the type in \`plitzi://types\` (the primer includes it). Do not assume \`display: block\`:
@@ -290,6 +329,8 @@ An element read reports \`availableVariants\` (which variant each attached class
 \`initialState\`, so you can see a button **has** a \`primary\` variant and whether it uses it. If the user asks for a
 variant that does not exist yet, **create it (upsertDefinition variants) and apply it in the same batch**.
 - \`initialState.visibility\` (boolean) sets whether the element starts shown or hidden.
+- The \`hidden\` state of a class is how it looks while hidden — where it goes and where it comes from. With a
+  \`transition\` that includes \`display 200ms allow-discrete\`, it fades or slides in and out instead of blinking.
 
 **Ancestor conditions** — a class that changes inside an ANCESTOR (\`.toolbar .icon\`), or while that ancestor is
 hovered or in a variant (\`.card:hover .icon\`, a collapsed sidebar hiding its labels) is \`ancestors\` on that class,
@@ -297,23 +338,42 @@ keyed by a class the ancestor wears: \`ancestors: { "toolbar": { "desktop": {
 { "desktop": { … } } } }, "sidebar": { "variants": { "collapsed": … } } }\`.
 Any ancestor counts, not only the parent; the class's own states and variants win over these. Never customCss for it.
 
+## Variables, design tokens and fonts
+- **Schema variables** are space-wide values a prop reads as \`{{name}}\`: \`upsertVariable { name, variableType,
+  value, category?, subValues? }\` (\`variableType\` is the runtime type — \`text\`, \`number\`, … — not the op's
+  \`type\`), \`deleteVariable { name }\`.
+- **Design tokens** are CSS values a definition reads as \`var(--name)\`: \`upsertStyleVariable { category, name,
+  value }\` with \`category\` one of \`color\`, \`spacing\`, \`shadow\`, \`custom\` and \`name\` without the \`--\`. A
+  \`value\` may be one string or \`{ light, dark }\`, so a colour follows the theme. \`deleteStyleVariable\` removes one.
+  Reach for a token whenever a value repeats across classes — a hardcoded colour is a colour the theme cannot change.
+- **Fonts**: a \`font-family\` only renders in its face when the space loads that family. \`upsertFont { family,
+  source, fallback, weights? }\` declares one — \`source\` \`google\` needs nothing else, \`remote\` a \`stylesheet\` or
+  \`files\` URL, \`system\` loads nothing. \`deleteFont { family }\` stops loading it; rules that still name it render
+  in their fallback.
+
 ## Data bindings
 Connect a data **source** to an element field. A binding is \`{ to, source, transformers?, when?, enabled? }\` grouped
 by **category**: \`attributes\` (a prop), \`style\` (a style value), \`initialState\` (an initial-state key).
 - \`upsertBinding\` adds one, or replaces the binding already feeding the same \`to\` (or \`id\`).
 - \`patchBinding\` edits an existing one (matched by \`to\`/\`id\`); \`deleteBinding\` removes it.
-Discover valid source paths **and the transformer catalog** in \`plitzi://data-sources/{env}\`. Example — feed an API
-list into a list element:
+Discover valid source paths **and the transformer catalog** in \`plitzi://data-sources/{env}\`. Example — feed a
+provider's records into a list element:
 \`{ "type": "upsertBinding", "pageRef": "home", "ref": "myList", "category": "attributes",
-  "binding": { "to": "items", "source": "apiContainer_x.data" } }\`.
+  "binding": { "to": "items", "source": "apiContainer_products.records" } }\`.
+
+**What an \`apiContainer\` publishes** depends on where it reads. Through a connector (\`runtime: "server"\`) it is the
+fixed shape under *Connectors* — \`.records\` or \`.record\`, \`.pageInfo\`, … With a browser \`query\` it is the
+response: \`.data\` (the parsed body — an API answering \`{ "items": [...] }\` is read as
+\`apiContainer_<name>.data.items\`) and \`.status\` (the HTTP status). Both add \`.isLoading\`, \`.isEmpty\`,
+\`.hasError\` and \`.errorMessage\`.
 
 **Source scope — a source is visible to the provider's DESCENDANTS only.** An element source named
 \`<type>_<name>\` (e.g. \`apiContainer_products\`, \`list_food-list\`) is published by that element into the scope of
 its **subtree**, so **only elements INSIDE the provider can bind to it**. Binding a sibling or an unrelated element
-to it resolves to nothing at runtime. So to consume \`apiContainer_products.data\`, the bound element must live under
+to it resolves to nothing at runtime. So to consume \`apiContainer_products.records\`, the bound element must live under
 that apiContainer; inside a \`list\`, the repeated \`listItem\` and its children read the per-row source
-(\`list_<name>.item.<field>\`). Module sources (no \`<type>_<name>\` head — \`state\`, \`space\`, \`navigation\`,
-\`auth\`, \`collection\`) are global and bindable anywhere. Binding an element to an element source outside its
+(\`list_<name>.item.<field>\`). The global sources — ${GLOBALS} — have no \`<type>_<name>\` head and are
+bindable anywhere. Binding an element to an element source outside its
 provider's subtree is schema-valid but **broken at runtime** (the source is not in scope), so
 \`plitzi_validate\`/\`plitzi_apply\` treat it as an **error and reject the batch** — move the element under the
 provider, or bind a source that is in scope.
@@ -332,9 +392,8 @@ show a number with units:
 \`{ "type": "upsertBinding", "pageRef": "home", "ref": "food-item-time", "category": "attributes",
   "binding": { "to": "content", "source": "list_food-list.item.cookTimeMinutes",
     "transformers": [ { "action": "twigTemplate", "params": { "template": "{{source}} min de cocción" } } ] } }\`.
-Other transformers: \`dateConverter\` (format a date/timestamp), \`capitalize\`, \`stringToArray\` (split on a
-separator), \`arrayMap\` (remap the keys of each object in an array), \`staticValue\`. Transformer \`params\` values are
-strings. Each transformer also takes an optional \`enabled\` flag: set \`"enabled": false\` to keep it in the chain but
+The others: ${OTHER_TRANSFORMERS} — each one's purpose and params are in \`plitzi://data-sources/{env}\`.
+Transformer \`params\` values are strings. Each transformer also takes an optional \`enabled\` flag: set \`"enabled": false\` to keep it in the chain but
 skip it at runtime (defaults to true) — the value passes through untouched, and a disabled transformer is not
 validated.
 
@@ -349,6 +408,14 @@ An interaction **flow** is a **trigger** (an event like \`onClick\`, \`onPageLoa
 it runs, in order. You pass the steps **in order** and the stored beforeNode/afterNode/flowId links are computed for
 you — never wire them by hand. Each step also has an \`enabled\` flag (see disable vs delete below).
 
+**Each step reads the page as it is when it runs**: a \`when\` or a \`{{ state.x }}\` after a \`setState\` sees the new
+value, and one after a \`delay\` sees what changed meanwhile. To act on the value from BEFORE a write, put the reading
+step first. **A trigger fired again while its flow runs is ignored** (no double submit); set \`"whileRunning": "queue"\`
+on the trigger node for a stream of events that must each run in order (\`"parallel"\` runs them at once).
+**Keyboard shortcuts** are a trigger every element has: \`onKey\` with param \`keys\` — \`"f"\`, \`"shift+f"\`,
+\`"mod+k"\` (⌘ on a Mac, Ctrl elsewhere), \`"plus, ="\`, \`"escape"\`. Heard on the whole page while the element is
+mounted, ignored while someone types in a field; the flow reads the key pressed as \`{{ <trigger id>.key }}\`.
+
 **Node types & \`elementId\`** — a step names which element (or module) provides the callback it runs. Picking the
 **wrong node type for an action** makes the runtime resolve it against nothing, so the step **silently does nothing**:
 - \`trigger\` — the event; belongs to the host element. \`elementId\` defaults to the host.
@@ -363,15 +430,16 @@ you — never wire them by hand. Each step also has an \`enabled\` flag (see dis
   \`setState\` has **no** \`type\` param (that belongs to the global one below). Beside it every element registers
   **\`toggleState\`** — the same write with **no \`value\`**: it stores the OPPOSITE of what is there
   (\`category\`, \`key\`, \`revertOnFinish\`). That is how expand/collapse is authored — **one step on one trigger**,
-  never two \`setState\` branches under complementary \`when\` conditions, which read the state as it was when the
-  flow STARTED and so are always one step behind. An element type may also register its own extra callbacks.
+  never two \`setState\` branches under complementary \`when\` conditions: every step reads the page as it is when it
+  runs, so the second sees what the first wrote and flips it back. An element type may also register its own extra
+  callbacks.
 - \`globalCallback\` — a callback provided by a **source module**, NOT by any element: \`addNotification\` (source
   \`space\`), \`setState\`/\`toggleState\`/\`clearState\` (\`state\`), \`navigate\` (\`navigation\`), \`login\`/\`logout\`/
   \`refreshDetails\` (\`auth\`), \`runServerAction\`/\`cancelServerAction\` (\`actions\`). Its \`elementId\` is the
   **source module id**, never the host element — a node that stored the host element's name here would resolve to
   nothing at runtime. **Omit \`elementId\`**: the MCP sets the correct source and fills the
   builder's **param defaults** (e.g. \`addNotification\` gets \`autoDismiss:true\`, \`autoDismissTimeout:5000\`,
-  \`placement:"top-right"\`, \`appeareance:"success"\`) for any params you leave out. Use **only** the params each
+  \`placement:"top-right"\`, \`appearance:"success"\`) for any params you leave out. Use **only** the params each
   callback declares (exact spelling) — for \`addNotification\` the visible text goes in \`content\`; there is **no**
   \`title\`/\`message\`/\`type\` param, and any unknown key is dropped. See the full param schema for each callback under
   \`globalCallbacks\` in \`plitzi://interactions/{env}\`.
@@ -439,26 +507,6 @@ server-rendered ignores its connector entirely.
 - \`plitzi://connectors/{env}\` — the connectors **this space already has**, each with its read/write endpoint names,
   its filter operators and its published fields. \`plitzi://connectors/{env}/{ref}\` opens one manifest in full.
 
-### Server actions
-Work a page cannot do in the browser — charge a card, send mail, read a system only the server reaches. An action
-is a stored flow the SERVER runs; a page names it and never learns what it does. Write one with
-\`upsertAction\` / \`patchAction\`, then call it from a page flow with the \`runServerAction\` step (mode
-\`await\` to use the result, \`detached\` to fire and carry on).
-
-Four rules worth knowing before you write:
-
-- **Steps are server tasks.** \`plitzi://actions/{env}/tasks\` lists what this deployment can run — a browser step
-  (\`setState\`, \`navigate\`) has nothing to act on here, and the reverse is true too: a task cannot run in a page
-  flow.
-- **The contracts.** \`input\` is coerced and anything undeclared is DROPPED. The OUTPUT is whatever the final
-  \`flow.output\` step names — there is no separate list to keep in step with it — and that step must be LAST,
-  since only the last one that runs is answered. Everything else a step produced stays on the server.
-- **Whether it runs lives on its TRIGGERS.** Each trigger step carries \`enabled\`, and the action is on when any
-  way into it is — there is no switch beside the flow. So "pause this action" means disabling its trigger step(s),
-  never deleting them.
-- **A step names the credential it uses**, and sees no other. \`credentials\` on the document says which ones the
-  action may ask for at all; the secret itself is never yours to see, exactly as with a connector.
-
 ### Credentials are NOT yours to write
 You never create, see or transmit a secret. Author the manifest with the token in place
 (\`"value": "Bearer {{credential.token}}"\`) and **leave \`connection.credential\` unset** unless the user hands you an
@@ -514,7 +562,8 @@ The provider element is \`apiContainer\`, and it needs **both halves**:
    other than \`list\`), \`filters\`, \`limit\`, \`singleRecord\`, \`pagination\`, \`pageParam\`.
 
 It then publishes one source **to its descendants only** (like any provider — bind *inside* its subtree):
-\`apiContainer_<name>.records\` (an array), \`.pageInfo\` (\`page\`, \`pageCount\`, \`total\`, \`hasNextPage\`…),
+\`apiContainer_<name>.records\` (an array of \`{ id, values }\` — a record's fields are under \`values\`, so a row
+reads \`list_<name>.item.values.<field>\`), \`.pageInfo\` (\`page\`, \`pageCount\`, \`total\`, \`hasNextPage\`…),
 \`.isEmpty\`, \`.hasError\`, \`.errorMessage\`, \`.isLoading\`. With \`singleRecord: true\` it publishes \`.record\`
 instead of \`.records\` — that is what a **detail page** uses. Bind an empty-state block's visibility to \`.isEmpty\`
 and an error block's to \`.hasError\`; they are ordinary bindings, no special mechanism.
@@ -531,7 +580,7 @@ and an error block's to \`.hasError\`; they are ordinary bindings, no special me
   { "type": "upsertBinding", "pageRef": "blog", "ref": "posts", "category": "attributes",
     "binding": { "to": "items", "source": "apiContainer_posts-api.records" } },
   { "type": "upsertBinding", "pageRef": "blog", "ref": "post-title", "category": "attributes",
-    "binding": { "to": "content", "source": "list_posts.item.title" } } ] }
+    "binding": { "to": "content", "source": "list_posts.item.values.title" } } ] }
 \`\`\`
 
 **A detail page** is the same provider with \`singleRecord\` and a filter resolved from the URL. Create the page with a
@@ -542,7 +591,7 @@ route param (\`"slug": "blog/:postSlug"\`), then filter on it — the filter \`v
     "props": { "connector": "strapi-blog", "resource": "articles", "singleRecord": true,
       "filters": [ { "field": "slug", "operator": "eq", "value": "{{routeParams.postSlug}}" } ] } } }
 \`\`\`
-Its children then bind to \`apiContainer_post-api.record.<field>\`. A filter whose template resolves to nothing
+Its children then bind to \`apiContainer_post-api.record.values.<field>\`. A filter whose template resolves to nothing
 returns **no records** rather than the whole collection — a URL that addressed one post never renders a different one.
 
 **Paging** is the \`pagination\` prop: \`"none"\`, \`"url"\` (the page number rides the query string, so pages are
@@ -559,6 +608,73 @@ credential and refuses any action the manifest does not declare. Writes exist **
 builder and renders empty when published. If the user has no SSR deployment, say so rather than leaving them to
 discover it — the alternative is a browser-side \`query\`, which cannot keep a secret.
 
+## Server actions
+Work a page cannot do in the browser — charge a card, send mail, read a system only the server reaches. An action
+is a stored flow the SERVER runs; a page names it and never learns what it does. Write one with
+\`upsertAction\` / \`patchAction\`, then call it from a page flow with the \`runServerAction\` step (mode
+\`await\` to use the result, \`detached\` to fire and carry on).
+
+Four rules worth knowing before you write:
+
+- **Steps are server tasks.** \`plitzi://actions/{env}/tasks\` lists what this deployment can run — a browser step
+  (\`setState\`, \`navigate\`) has nothing to act on here, and the reverse is true too: a task cannot run in a page
+  flow.
+- **The contracts.** \`input\` is coerced and anything undeclared is DROPPED. The OUTPUT is whatever the final
+  \`flow.output\` step names — there is no separate list to keep in step with it — and that step must be LAST,
+  since only the last one that runs is answered. Everything else a step produced stays on the server.
+- **Whether it runs lives on its TRIGGERS.** Each trigger step carries \`enabled\`, and the action is on when any
+  way into it is — there is no switch beside the flow. So "pause this action" means disabling its trigger step(s),
+  never deleting them.
+- **A step names the credential it uses**, and sees no other. \`credentials\` on the document says which ones the
+  action may ask for at all; the secret itself is never yours to see, exactly as with a connector.
+
+\`deleteAction { ref }\` removes one; every \`runServerAction\` step that names it stops resolving, so confirm first.
+
+## Functions
+When no server task does what a flow needs — parse a feed, call an API with its own shape, compute something — the
+space can have its own: **functions**, TypeScript the platform builds and runs in a sandbox. Their tasks are steps like
+any other (\`<namespace>.<action>\`), listed in \`plitzi://actions/{env}/tasks\` once saved.
+
+- **Write** files with \`upsertFunctionFile { path, content }\` (whole files; \`deleteFunctionFile { path }\` removes
+  one). \`index.ts\` default-exports the definition:
+  \`export default defineFunctions({ allow: { hosts: ["api.example.com"] }, tasks: [{ namespace, action, title, params, run: async (params, ctx) => … }] })\`,
+  \`defineFunctions\` from \`@plitzi/sdk-server/functions\`. Files import each other by relative path — no package,
+  no Node built-in.
+- **\`ctx\` is all a function reaches:** \`ctx.kv\` (the space's store), \`ctx.fetch(url, init)\` to the hosts
+  \`allow.hosts\` names (\`*.example.com\` for subdomains), \`ctx.publish/grant/revoke\` (channels), \`ctx.log\`,
+  \`ctx.user\` (who asked, never their session). A secret is NAMED, never read: \`ctx.fetch(url, { credential: "stripe",
+  headers: { authorization: "Bearer {{ credential.apiKey }}" } })\`.
+- **Stateless:** nothing a function keeps in memory outlives the call — a module-level cache or counter starts empty
+  every time, on whichever instance runs it. What must last goes in \`ctx.kv\`. A call gets 100 ms of CPU and 10 s.
+- **Saving builds and checks** the files: the batch is refused with each problem where it is (file and line). A
+  namespace the platform uses (\`kv\`, \`http\`, \`flow\`…) is refused.
+- **Try it** with \`plitzi_try_function { task, params }\` before a page relies on it: the value, the logs, the error.
+  The live site runs what the space was last published with, never the draft. Running functions is part of the paid
+  plans: on another plan they save, and a run answers why it did not start — tell the user rather than work around it.
+
+## Realtime channels
+Pages that see each other — cursors, presence, a shared board, a game. Three parts, all needed:
+
+1. **Declare** the topic pattern with \`patchSettings { channels: { "board:{id}": { access: { mode: "public" }, publish: "server" } } }\`.
+   \`publish: "server"\` is for what must be validated and saved first; \`"clients"\` (the default) for what pages send
+   directly — add \`presence: true\` for who-is-here.
+2. **Subscribe** with a \`channel\` element whose \`topic\` a pattern matches (\`board:{{ id }}\`, a route param).
+   Its descendants bind \`channel_<id>\`: \`connected\`, \`members\`, \`messages\`, \`last\`; flows use its \`onMessage\`,
+   \`onJoin\`, \`onLeave\` triggers (\`from\`, \`user\` and the \`state\` the member announced — \`onJoin\` only for who
+   came after this page) and its \`publish\` / \`setPresence\` callbacks.
+3. **Announce from the server**: an action whose last step is the \`realtime.publish\` task — validate, save, then say so.
+
+A topic no pattern matches is refused by the server and reported by the linter (\`channel-topic\`).
+
+**Private topics** (a room behind a password, a customer's order): declare the pattern \`grant: true\`. The action that
+decides the visitor may be there ends with \`realtime.grant { topic }\` and answers its \`grant\`; the \`channel\`
+element binds \`grant\` to it. Without one the topic is refused however well its name is known (\`channel-grant\`).
+\`realtime.revoke { topic, grant }\` takes one back — or all, naming none — and lets go whoever is on it with it.
+
+**Two writers at once**: read-change-write with \`kv.setIf\` (written only if the value is still the one read — empty
+\`expected\` = only if nothing is there yet), ordered lists with \`list.put\` / \`list.range\`, and put
+\`flow.rateLimit\` first in any public action that writes.
+
 ## Shared layouts — the chrome a page does NOT contain
 A page's tree is usually **not the whole page**. The header, the sidebar and the footer normally live in a **layout
 container**: a shell several pages are rendered inside, so the navigation is authored once instead of once per page.
@@ -640,15 +756,62 @@ Space-level configuration lives in \`plitzi://settings/{env}\` and is edited wit
 (merge — only the fields you pass change):
 - \`customCss\` — **raw global CSS** injected for the whole space. Use it only for genuinely site-wide rules
   (\`@keyframes\`, \`@font-face\`, resets). To style an element, write a **definition** and attach it — never customCss.
-- \`keepState\` / \`stateStorage\` — persist element state across reloads (\`localStorage\`/\`sessionStorage\`).
+- \`keepState\` / \`stateStorage\` — keep the runtime state (\`state.<key>\`, what \`setState\` writes) across reloads,
+  in \`localStorage\`/\`sessionStorage\`, filed under whoever is signed in. It is the space's setting — pages do not
+  take one. \`transientState\` lists the top-level keys never kept (a filter, a demo, a panel left open); do not
+  reset kept state from \`onPageLoad\` instead — it is restored later than that and undoes half of the reset.
+  \`paintedState\` lists the kept keys the FIRST PAINT shows (the tool a toolbar shows, a name in an avatar): they go
+  in a cookie too, so the server draws with them instead of the page swapping them in after load. Small values only.
 - **User provider / auth**: \`userProvider\` — \`basic\` for any HTTP+JSON backend, the name of a provider registered
   in the page, or \`""\` to disable auth — plus \`tokenStorage\`, the \`loginUrl\`/\`userUrl\`/\`refreshUrl\`/\`logoutUrl\`
   endpoints and the \`detailsPath\`/\`tokenPath\`/\`refreshTokenPath\`/\`expirationTimePath\` mapping that says where the
   values sit in their responses. \`sessionHintCookie\` is worth setting whenever the backend can: it names a readable
   cookie carrying only expiries, which is what lets a page answer "nobody is signed in" without a request.
+  On the Plitzi platform, \`userProvider: "server"\` signs visitors in with their Plitzi account on the space's own
+  host: a \`link\` with \`mode: "external"\` to \`/auth/sign-in?return=/\` starts it, \`authLogout\` ends it.
+- \`visitorRoles\` — what each visitor role gives, \`{ "author": ["postPublish"] }\`: the permissions an action's
+  \`access: { mode: "role" }\` and a page's \`can()\` ask for. A visitor holds ONLY the permissions of their roles here,
+  never their account's. Who holds a role is given by email in the builder's Visitors panel — never in settings.
+- \`channels\` — the realtime channels, by topic pattern (see **Realtime channels**). Merged pattern by pattern;
+  \`null\` removes one.
   Example — inject a keyframe globally:
   \`{ "type": "patchSettings", "customCss": "@keyframes spin { to { transform: rotate(360deg); } }" }\`.
 
+## Accessibility — pages people, screen readers and browser agents can all use
+A page is read three ways: seen, heard through a screen reader, and worked by a **browser agent** (Claude in Chrome)
+— which finds the controls it can press in the same **accessibility tree** a screen reader walks. A control that
+tree names nothing is invisible to both, however it looks. So build every page to be operable without sight:
+- **Every control has words.** A \`button\` is named by its \`content\` and the words inside it; an icon-only one needs a
+  \`title\` (also its tooltip), and one whose words do not say what it does (a key hint, a count) a \`label\`. A \`link\` is named by what it holds, or \`label\` (set it on a link wrapping a whole card).
+  A \`formControl\` is named by its \`label\` — keep it and set \`hideLabel: true\` when the design shows what the field
+  is (a swatch, a search box); a \`placeholder\` names only a field typed into, and only until something is typed.
+- **Every picture says what it shows** (\`alt\`), or is marked \`decorative: true\` when the words beside it already say
+  it. A \`fontAwesome\` icon is decoration (hidden) unless its \`label\` gives it a meaning of its own.
+- **Only controls are clicked.** A click flow belongs on a \`button\` (it holds children — a whole card can be one) or
+  a \`link\` when it goes somewhere — never on a \`container\`, \`text\` or \`image\`: a keyboard cannot reach those and
+  no agent finds them. An empty backdrop that closes a panel is the exception (the panel's close button and Escape
+  are the ways everyone has).
+- **State is said, not only styled.** A toggle sets \`ariaPressed\`, a button that opens a panel \`ariaExpanded\`
+  (bind them like any attribute) — an "active" class alone is invisible to both readers.
+- **A dropdown opens from a \`button\`** among its children, outside the popup (an avatar, a "⋯": the button holds it and
+  has a \`title\`). The dropdown marks it and moves the focus in and out; a box or an icon alone opens nothing from a
+  keyboard.
+- **An illustration** built from elements (a mock of a page, art) is a \`container\` with \`decorative: true\`: both
+  readers skip it. Keep controls out of it.
+- **The page has an outline.** Headings go down one level at a time (h1 → h2 → h3; size them with their class, not
+  their level). Landmarks are containers with a tag — \`header\`, \`nav\`, \`main\`, \`aside\`, \`footer\` — and a
+  \`label\` when a page has two of one kind; a \`section\` with a \`label\` is a region an assistant can jump to.
+- **What comes built in:** modals and dialogs are \`dialog\`s named by their title, take the focus, keep Tab inside
+  and close on Escape; tabs are a tab list worked with the arrow keys; a field that breaks a rule is marked invalid and
+  described by its message; the pager marks the current page. Nothing to add for those.
+- **A canvas is a picture** to both readers. A plugin that draws (a chart, a board, a map) also renders what it shows
+  as real elements — a list, a table — with a button for every action; one hidden until focused cannot be clicked by an
+  agent that clicks by position, so offer a visible "list view".
+The linter warns about these (\`control-without-name\`, \`image-without-alt\`, \`click-on-static-element\`,
+\`dropdown-without-control\`, \`heading-level-skipped\`, \`label-ignored\`, \`control-in-decorative\`) on every element
+you touch; fix them in the same batch. Then look:
+\`plitzi_screenshot\` with \`view: "accessibility"\` shows the page as those readers get it, and lists what has no name.
+
 ## Semantics
 - **props are fully replaced** on \`upsertElement\`: send every prop you want to keep. To change only some props,
   use **\`patchElement\`** — it merges \`props\`/\`style\` onto the existing element (listed keys change, \`null\` unsets
@@ -660,15 +823,16 @@ Space-level configuration lives in \`plitzi://settings/{env}\` and is edited wit
   Example — recolor one definition without resending it: \`{ "type": "patchDefinition", "ref": "btn-x",
   "desktop": { "background-color": "#111" } }\`.
 - **Atomic batches**: if any operation fails, \`plitzi_apply\` persists nothing.
-- **Every resource you touch must be malformation-free — pre-existing errors block the save.** When your batch edits
-  an element (or a definition/global/id style), the validator also checks the resource's **current stored content**
-  for malformations — a broken transformer action, a malformed interaction node, invalid CSS — even in parts your
-  edit does not touch. Such a finding is reported as a \`Pre-existing malformation in <resource>: …\` **error**, and
+- **Every element you touch must be malformation-free — pre-existing errors block the save.** When your batch edits
+  an element, the result is read by the same linter every writer of a space is held to, and the element's **current
+  stored content** with it — a broken transformer action, a malformed step, an attribute it never reads — even in
+  parts your edit does not touch. Such a finding is reported as a \`Pre-existing malformation in element …\` **error**, and
   \`plitzi_apply\` rejects the batch until it is fixed. These are **not caused by your change** (the message says so)
   — do not be confused; fix them **in the same batch** and re-apply. Because the check runs on the resulting state,
   including the fix in your batch is exactly what unblocks the save. (Advisory issues — an unobserved source/action
   name that may still be a valid plugin, a binding target a plugin manifest does not list — come back as
-  \`Pre-existing issue …\` **warnings** and do not block.)
+  \`Pre-existing issue …\` **warnings** and do not block.) Elements you do not touch are not held against you — except
+  that a broken tree your batch leaves anywhere (an element orphaned by a delete) is refused.
 - **Optimistic concurrency — read before you write, and prove your read is current.** Editing a resource means you
   read it first, so you hold its \`stateVersion\`. **Always pass \`expectedResourceVersions\`** (URI → the stateVersion
   you read) for every resource your batch changes. If another agent edited it in the meantime, the live version no

package/dist/modules/mcp/helpers/interactions.d.ts

@@ -1,6 +1,6 @@
 import { AIBinding, AIBindings, AIInteractionFlow, AIInteractionNodeType } from '../types';
 import { RuleGroup } from '@plitzi/plitzi-ui/QueryBuilder';
-import { ElementBinding, ElementDefinition, ElementInteraction } from '@plitzi/sdk-shared';
+import { ElementBinding, ElementDefinition, ElementInteraction, WhileRunning } from '@plitzi/sdk-shared';
 /** The node shape agents supply on write: same as AIInteractionNode but `id` is optional (generated when
  *  omitted). Kept structural so the tool-layer zod type assigns to it without importing the tool layer here. */
 export interface FlowNodeInput {
@@ -11,6 +11,7 @@ export interface FlowNodeInput {
     params?: Record<string, unknown>;
     enabled?: boolean;
     when?: RuleGroup;
+    whileRunning?: WhileRunning;
     elementId?: string;
     preview?: Record<string, unknown>;
 }

package/dist/modules/mcp/helpers/interactions.js

@@ -21,6 +21,7 @@ var nodeToAI = (node) => {
 	if (isNonEmptyObject(node.params)) ai.params = node.params;
 	if (!node.enabled) ai.enabled = false;
 	if (node.when !== void 0) ai.when = node.when;
+	if (node.whileRunning !== void 0) ai.whileRunning = node.whileRunning;
 	if (node.elementId && node.elementId !== node.id) ai.elementId = node.elementId;
 	if (isNonEmptyObject(node.preview)) ai.preview = node.preview;
 	return ai;
@@ -101,6 +102,7 @@ var materializeFlow = (nodes, ownerId) => {
 			enabled: node.enabled ?? true
 		};
 		if (node.when !== void 0) interaction.when = node.when;
+		if (node.whileRunning !== void 0) interaction.whileRunning = node.whileRunning;
 		record[ids[i]] = interaction;
 	});
 	return {

package/dist/modules/mcp/helpers/space.d.ts

@@ -1,5 +1,5 @@
 import { AIElementDetail } from '../types';
-import { ActionEntry, ActionTaskDescriptor, ComponentCatalog, ConnectorEntry, Element, PageFolder, Schema, Style } from '@plitzi/sdk-shared';
+import { ActionEntry, ActionTaskDescriptor, ComponentCatalog, ConnectorEntry, Element, FunctionsDraft, PageFolder, Schema, Style } from '@plitzi/sdk-shared';
 /** The working view the tools read and mutate: the two Plitzi schemas (elements + style), which the platform
  *  stores and persists as separate documents (Space model / Style model), plus the space's `connectors` — a third
  *  store (one row per connector) that a provider element points into by identifier. `catalog` is read-only
@@ -13,6 +13,9 @@ export interface Space {
     /** The server tasks this deployment can run. Read-only reference data like `catalog`, not persisted: it is what
      *  the server has, not what the space owns, and an action authored against a task it lacks cannot run. */
     actionTasks?: ActionTaskDescriptor[];
+    /** The space's own functions — their source files, which copy of them this is, and what they declare. Absent when
+     *  the deployment offers no functions: then there is nothing to read and every function op is refused. */
+    functions?: FunctionsDraft;
     catalog?: ComponentCatalog;
 }
 export declare const cloneSpace: (space: Space) => Space;
@@ -69,8 +72,8 @@ export declare const indexRemoveElements: (schema: Schema, els: Element[]) => vo
 export declare const indexAddPage: (schema: Schema, page: Element) => void;
 /** A new layout shell was created. */
 export declare const indexAddLayout: (schema: Schema, layout: Element) => void;
-/** A layout shell and its `descendants` were deleted. */
-export declare const indexRemoveLayout: (schema: Schema, layout: Element, descendants: Element[]) => void;
+/** A layout shell and the elements under it (`removed`) were deleted. */
+export declare const indexRemoveLayout: (schema: Schema, layout: Element, removed: Element[]) => void;
 /** A page and its `descendants` (its non-page elements) were deleted. */
 export declare const indexRemovePage: (schema: Schema, page: Element, descendants: Element[]) => void;
 /** A move reparented an element within its page: the page map is unchanged, but the moved element's parent and
@@ -113,7 +116,6 @@ export declare const slugRouteParams: (slug: string) => string[];
 export declare const routeParamNames: (schema: Schema) => string[];
 /** Indexed lookup that reflects the runtime reality: a flat id may be dangling (rsc placeholders, stale items). */
 export declare const elementById: (schema: Schema, id: string) => Element | undefined;
-export declare const descendantIds: (schema: Schema, pageRootId: string) => string[];
 /** Resolve a name to a concrete element within a page subtree (or the page root itself). The name is the element's
  *  key in `flat`; what this adds is the check that it really belongs to this page. */
 export declare const resolveRef: (schema: Schema, page: Element, ref: string) => Element | undefined;

package/dist/modules/mcp/helpers/space.js

@@ -1,9 +1,11 @@
+import { descendants } from "@plitzi/sdk-schema/helpers/elementTree";
 //#region src/modules/mcp/helpers/space.ts
 var cloneSpace = (space) => ({
 	schema: structuredClone(space.schema),
 	style: structuredClone(space.style),
 	connectors: structuredClone(space.connectors),
 	actions: structuredClone(space.actions),
+	...space.functions ? { functions: structuredClone(space.functions) } : {},
 	...space.actionTasks ? { actionTasks: space.actionTasks } : {},
 	...space.catalog ? { catalog: space.catalog } : {}
 });
@@ -134,15 +136,15 @@ var indexAddLayout = (schema, layout) => {
 	index.pageOf.set(layout.id, layout.id);
 	index.detailCache.clear();
 };
-/** A layout shell and its `descendants` were deleted. */
-var indexRemoveLayout = (schema, layout, descendants) => {
+/** A layout shell and the elements under it (`removed`) were deleted. */
+var indexRemoveLayout = (schema, layout, removed) => {
 	const index = cachedIndex(schema);
 	if (!index) return;
 	index.layoutIds.delete(layout.id);
 	const at = index.layoutElements.findIndex((entry) => entry.id === layout.id);
 	if (at >= 0) index.layoutElements.splice(at, 1);
 	index.pageOf.delete(layout.id);
-	for (const el of descendants) index.pageOf.delete(el.id);
+	for (const el of removed) index.pageOf.delete(el.id);
 	index.detailCache.clear();
 };
 /** A page and its `descendants` (its non-page elements) were deleted. */
@@ -255,21 +257,6 @@ var routeParamNames = (schema) => {
 };
 /** Indexed lookup that reflects the runtime reality: a flat id may be dangling (rsc placeholders, stale items). */
 var elementById = (schema, id) => schema.flat[id];
-/** All element ids belonging to a page subtree (excluding the page root). */
-var collectDescendants = (schema, rootId, acc) => {
-	const el = elementById(schema, rootId);
-	if (!el) return;
-	const childIds = el.definition.items ?? [];
-	for (const childId of childIds) if (elementById(schema, childId)) {
-		acc.push(childId);
-		collectDescendants(schema, childId, acc);
-	}
-};
-var descendantIds = (schema, pageRootId) => {
-	const acc = [];
-	collectDescendants(schema, pageRootId, acc);
-	return acc;
-};
 /** Resolve a name to a concrete element within a page subtree (or the page root itself). The name is the element's
 *  key in `flat`; what this adds is the check that it really belongs to this page. */
 var resolveRef = (schema, page, ref) => {
@@ -285,7 +272,7 @@ var orderedChildren = (schema, el) => {
 /** The page ref an element belongs to. 'unknown' when it has no page ancestor. */
 var pageRefOfElement = (schema, el) => spaceIndex(schema).pageOf.get(el.id) ?? "unknown";
 /** Total number of descendant elements under a subtree (excluding the root). */
-var descendantCount = (schema, rootId) => descendantIds(schema, rootId).length;
+var descendantCount = (schema, rootId) => descendants(schema.flat, rootId).length;
 var emptySpaceMessage = "Space data not available";
 /** The code a space-dependent answer carries when the connection reaches no space, so both the agent and a host UI
 *  can tell "this connection cannot do that" from "the call failed". */
@@ -311,4 +298,4 @@ var ReadOnlyGrantError = class extends Error {
 	}
 };
 //#endregion
-export { NoSpaceError, ReadOnlyGrantError, cloneSpace, descendantCount, descendantIds, elementById, emptySpace, emptySpaceMessage, findActionEntry, findConnectorEntry, findElementByRef, findFolderByRef, findLayoutByRef, findPageByRef, findRootByRef, folderAncestorIds, getLayoutElements, getPageElements, indexAddElement, indexAddLayout, indexAddPage, indexInvalidateDetails, indexRemoveElements, indexRemoveLayout, indexRemovePage, invalidateIndex, isPageElement, nameOf, noSpaceErrorCode, orderedChildren, pageFoldersOf, pageRefOfElement, pagesUsingLayout, readOnlyGrantErrorCode, readOnlyGrantMessage, resolveRef, routeParamNames, slugRouteParams, slugify, sortFolders, spaceIndex, strOr, unauthorizedSpaceMessage };
+export { NoSpaceError, ReadOnlyGrantError, cloneSpace, descendantCount, elementById, emptySpace, emptySpaceMessage, findActionEntry, findConnectorEntry, findElementByRef, findFolderByRef, findLayoutByRef, findPageByRef, findRootByRef, folderAncestorIds, getLayoutElements, getPageElements, indexAddElement, indexAddLayout, indexAddPage, indexInvalidateDetails, indexRemoveElements, indexRemoveLayout, indexRemovePage, invalidateIndex, isPageElement, nameOf, noSpaceErrorCode, orderedChildren, pageFoldersOf, pageRefOfElement, pagesUsingLayout, readOnlyGrantErrorCode, readOnlyGrantMessage, resolveRef, routeParamNames, slugRouteParams, slugify, sortFolders, spaceIndex, strOr, unauthorizedSpaceMessage };