@salsita-ai/sdk 0.50.0-develop.b335a15889 → 0.50.0-develop.bc08a38ffe

package/dist/docs/phoenix/configurator-interface.mdx

@@ -25,8 +25,9 @@ The configurator interface is generated in `.phoenix/configurator-interface.ts`:
 
 ```typescript
 // .phoenix/configurator-interface.ts (AUTO-GENERATED - DO NOT EDIT)
-import {'{'} createConfiguratorInterface {'}'} from '@salsita-ai/sdk/configurator'
-import {'{'} configuratorBuilder {'}'} from './domain.js'
+import { createConfiguratorInterface } from '@salsita-ai/sdk/configurator'
+
+import { configuratorBuilder } from './domain.js'
 
 export const configuratorInterface = createConfiguratorInterface(configuratorBuilder)
 
@@ -64,9 +65,9 @@ type CustomMaterial = Phx['AdminModel']['CustomMaterial']
 Access the configurator interface via `phx.frontend`:
 
 ```typescript
-export const CustomComponent = () => {'{'}
+export const CustomComponent = () => {
   // Access domain systems
-  const {'{'} navigationSystem, storeSystem {'}'} = phx.frontend.useDomain()
+  const { navigationSystem, storeSystem } = phx.frontend.useDomain()
 
   // Entity state hooks
   const rootEntity = phx.frontend.useRootEntityState()
@@ -76,11 +77,11 @@ export const CustomComponent = () => {'{'}
   const selectEntity = phx.frontend.useSelectEntity()
 
   // Type-safe entity access
-  if (selectedEntity && Cabinet.is(selectedEntity)) {'{'}
+  if (selectedEntity && Cabinet.is(selectedEntity)) {
     // selectedEntity is now typed as $Cabinet
     console.log(selectedEntity.width, selectedEntity.$area)
-  {'}'}
-{'}'}
+  }
+}
 ```
 
 ## Core Hooks
@@ -90,16 +91,16 @@ The configurator interface provides 100+ hooks organized by category. Use TypeSc
 ### Domain & Application Context
 
 ```typescript
-const ExampleComponent = () => {'{'}
+const ExampleComponent = () => {
   // Core domain systems
-  const {'{'} navigationSystem, storeSystem, entitySystem {'}'} = phx.frontend.useDomain()
+  const { navigationSystem, storeSystem, entitySystem } = phx.frontend.useDomain()
 
   // Domain application context
-  const {'{'} configurationPersistSystem {'}'} = phx.frontend.useDomainApplication()
+  const { configurationPersistSystem } = phx.frontend.useDomainApplication()
 
   // Full configurator context
-  const {'{'} imageRenderingSystem {'}'} = phx.frontend.useConfigurator()
-{'}'}
+  const { imageRenderingSystem } = phx.frontend.useConfigurator()
+}
 ```
 
 ### State Subscriptions
@@ -157,26 +158,31 @@ const viewState = phx.frontend.useActiveViewState()
 const toolState = phx.frontend.useActiveToolState()
 
 // Navigation actions
-const navigate = phx.frontend.useNavigate()
-const pushNavigate = phx.frontend.usePushNavigate()
-const popNavigate = phx.frontend.usePopNavigate()
+const navigate = phx.frontend.useNavigate() // navigate(state) replaces the active state and clears the history
+const pushNavigate = phx.frontend.usePushNavigate() // pushNavigate(state) remembers the active state for popNavigate
+const popNavigate = phx.frontend.usePopNavigate() // popNavigate() returns to the remembered state, if there is one
+
+// Fullscreen: a flag in the configurator's state that the layout honours; it does not put the browser into fullscreen
+const isFullscreen = phx.frontend.useIsFullscreenActive()
+const setFullscreen = phx.frontend.useSetFullscreen() // setFullscreen(true) or setFullscreen(false)
 ```
 
 ### Controls
 
 ```typescript
-// Control hooks for UI inputs
-const swatchSelection = phx.frontend.useSwatchSelection(entityId, controlId)
-const textValue = phx.frontend.useTextValue(entityId, controlId)
-const attributeSelection = phx.frontend.useAttributeSelection(entityId, controlId)
-const attributeSwitch = phx.frontend.useAttributeSwitch(entityId, controlId)
-const distanceDimension = phx.frontend.useDistanceDimension(entityId, controlId)
-const angleDimension = phx.frontend.useAngleDimension(entityId, controlId)
-const genericDimension = phx.frontend.useGenericDimension(entityId, controlId)
+// Control hooks for UI inputs: the entity id and the instance name of the control component on it
+// useSwatchSelection requires its third argument, the fixable violation types
+const swatchSelection = phx.frontend.useSwatchSelection(entityId, instanceName, [])
+const textValue = phx.frontend.useTextValue(entityId, instanceName)
+const attributeSelection = phx.frontend.useAttributeSelection(entityId, instanceName)
+const attributeSwitch = phx.frontend.useAttributeSwitch(entityId, instanceName)
+const distanceDimension = phx.frontend.useDistanceDimension(entityId, instanceName)
+const angleDimension = phx.frontend.useAngleDimension(entityId, instanceName)
+const genericDimension = phx.frontend.useGenericDimension(entityId, instanceName)
 
 // Update control
 const updateControl = phx.frontend.useUpdateControl()
-const updatedControl = phx.frontend.useUpdatedControl(entityId, controlId)
+const updatedControl = phx.frontend.useUpdatedControl(updates)
 ```
 
 ### Recipes & Entity Creation
@@ -202,14 +208,18 @@ const deletedEntity = phx.frontend.useDeletedEntity()
 ### Validation & Violations
 
 ```typescript
-// State validity
+// Validity of the last committed state; a rejected change never becomes committed, so it is not seen here
 const validity = phx.frontend.useStateValidity()
 
-// Control violations
-const controlViolations = phx.frontend.useControlViolations(entityId, controlId)
+// Control violations: takes the violation types to ignore and returns a function that maps a prepared
+// state emission to { disabled, hints, violations }
+const controlViolations = phx.frontend.useControlViolations([])
 
 // Finalize violations
-const {'{'} disabled, hints {'}'} = phx.frontend.useFinalizeViolations()
+const { disabled, hints } = phx.frontend.useFinalizeViolations()
+
+// Messages for the user: violations of a rejected change, side-effect hints and errors, one call each
+phx.frontend.useConfiguratorMessages(message => showToast(message.text))
 
 // Map violations to hints
 const mapViolationHints = phx.frontend.useMapViolationHints()
@@ -284,89 +294,89 @@ The interface provides factory functions for creating handlers and providers:
 
 ```typescript
 // Runs early in app startup, before session auth
-const OnApplicationStart = phx.frontend.createOnApplicationStartProvider(({'{'} children {'}'}) => {'{'}
-  return <YourProvider>{'{'}children{'}'}</YourProvider>
-{'}'})
+const OnApplicationStart = phx.frontend.createOnApplicationStartProvider(({ children }) => {
+  return <YourProvider>{children}</YourProvider>
+})
 
 // Runs after session auth, before domain data loading
-const OnSessionReady = phx.frontend.createOnSessionReadyProvider(({'{'} children {'}'}) => {'{'}
-  return <YourProvider>{'{'}children{'}'}</YourProvider>
-{'}'})
+const OnSessionReady = phx.frontend.createOnSessionReadyProvider(({ children }) => {
+  return <YourProvider>{children}</YourProvider>
+})
 
 // Runs after published data is parsed, before frontend/backend loading
-const OnPublishedDataReady = phx.frontend.createOnPublishedDataReadyProvider(({'{'} children {'}'}) => {'{'}
-  return <YourProvider>{'{'}children{'}'}</YourProvider>
-{'}'})
+const OnPublishedDataReady = phx.frontend.createOnPublishedDataReadyProvider(({ children }) => {
+  return <YourProvider>{children}</YourProvider>
+})
 
 // Runs after frontend collection and parsing, before backend loading
-const OnFrontendDataReady = phx.frontend.createOnFrontendDataReadyProvider(({'{'} children {'}'}) => {'{'}
-  return <YourProvider>{'{'}children{'}'}</YourProvider>
-{'}'})
+const OnFrontendDataReady = phx.frontend.createOnFrontendDataReadyProvider(({ children }) => {
+  return <YourProvider>{children}</YourProvider>
+})
 
 // Runs after backend loading, before preset selection and configurator initialization
-const OnBackendDataReady = phx.frontend.createOnBackendDataReadyProvider(({'{'} children {'}'}) => {'{'}
-  return <YourProvider>{'{'}children{'}'}</YourProvider>
-{'}'})
+const OnBackendDataReady = phx.frontend.createOnBackendDataReadyProvider(({ children }) => {
+  return <YourProvider>{children}</YourProvider>
+})
 
 // Runs after routing and preset selection are ready
-const OnRoutingReady = phx.frontend.createOnRoutingReadyProvider(({'{'} children {'}'}) => {'{'}
-  return <YourProvider>{'{'}children{'}'}</YourProvider>
-{'}'})
+const OnRoutingReady = phx.frontend.createOnRoutingReadyProvider(({ children }) => {
+  return <YourProvider>{children}</YourProvider>
+})
 
 // Wraps OwnerUi and ReadUi pages
-const OnConfiguratorReady = phx.frontend.createOnConfiguratorReadyProvider(({'{'} children {'}'}) => {'{'}
-  return <YourProvider>{'{'}children{'}'}</YourProvider>
-{'}'})
+const OnConfiguratorReady = phx.frontend.createOnConfiguratorReadyProvider(({ children }) => {
+  return <YourProvider>{children}</YourProvider>
+})
 ```
 
 ### Data Handlers
 
 ```typescript
 // Collect frontend data during initialization
-const collectFrontendData = phx.frontend.createCollectFrontendDataHandler(async (context) => {'{'}
-  return {'{'} customData: await fetchCustomData() {'}'}
-{'}'})
+const collectFrontendData = phx.frontend.createCollectFrontendDataHandler(async context => {
+  return { customData: await fetchCustomData() }
+})
 
 // Override which published chunks are fetched by the frontend.
 // See Publishing page for full documentation.
-const filterPublishedChunks = phx.frontend.createFilterPublishedChunksHandler(() => {'{'}
+const filterPublishedChunks = phx.frontend.createFilterPublishedChunksHandler(() => {
   const session = phx.frontend.useSession()
 
-  return useMemo(() => {'{'}
+  return useMemo(() => {
     if (session.sessionPayload?.role === 'admin') return ['styling', 'catalog-na']
     return ['styling']
-  {'}'}, [session.sessionPayload?.role])
-{'}'})
+  }, [session.sessionPayload?.role])
+})
 
 // Runs after preset data is loaded
-const onPresetLoaded = phx.frontend.createOnPresetLoadedHandler((entities, presetData) => {'{'}
+const onPresetLoaded = phx.frontend.createOnPresetLoadedHandler((entities, presetData) => {
   // Can modify preset entities before rendering
   return entities
-{'}'})
+})
 
 // Intercept navigation to index/presets page
-const onGoToIndex = phx.frontend.createOnGoToIndexHandler(() => {'{'}
+const onGoToIndex = phx.frontend.createOnGoToIndexHandler(() => {
   // Custom logic before navigating
-{'}'})
+})
 ```
 
 ### UI Components
 
 ```typescript
 // Custom Phoenix layout element
-const MyLayoutElement = phx.frontend.createCustomPhoenixLayoutElement(() => {'{'}
+const MyLayoutElement = phx.frontend.createCustomPhoenixLayoutElement('MyLayoutElement', () => {
   return <div>Custom Layout</div>
-{'}'})
+})
 
 // Custom Phoenix entity element
-const MyEntityElement = phx.frontend.createCustomPhoenixEntityElement(() => {'{'}
+const MyEntityElement = phx.frontend.createCustomPhoenixEntityElement('MyEntityElement', () => {
   return <mesh>...</mesh>
-{'}'})
+})
 
 // Custom page when auth fails
-const NotAuthenticatedPage = phx.frontend.createNotAuthenticatedPage(() => {'{'}
+const NotAuthenticatedPage = phx.frontend.createNotAuthenticatedPage(() => {
   return <div>Please log in</div>
-{'}'})
+})
 ```
 
 ### Preset UI
@@ -383,21 +393,115 @@ const PresetAction = phx.frontend.createPresetPageAction(PresetHelpAction)
 const PresetOverlay = phx.frontend.createPresetDeviceNotSupported(SmallScreenNotice)
 ```
 
+### Loaded Configuration UI
+
+A layout element registered under the name `ConfiguratorLayout` replaces the whole UI of a loaded configuration, in owner and in read mode, whatever `layout` the spec sets. Without it, Phoenix renders the layout the spec selects. [Custom Layout](?path=/docs/layouts-custom-layout--docs) is a worked example: a fully custom product page with its panel on the left, built from the scene, the safe-area hook and state hooks.
+
+```typescript
+// src/elements/ConfiguratorLayout.tsx
+import { LayoutSlots, useSceneSafeArea } from '@salsita-ai/sdk/configurator'
+
+const SIDEBAR_WIDTH = 320
+
+export default phx.frontend.createCustomPhoenixLayoutElement('ConfiguratorLayout', () => {
+  const { containerRef, safeAreaRef } = useSceneSafeArea()
+
+  return (
+    <div ref={containerRef} style={{ position: 'absolute', inset: 0 }}>
+      <LayoutSlots.Services />
+      <LayoutSlots.SharedCanvas />
+      <aside style={{ position: 'absolute', insetBlock: 0, insetInlineStart: 0, inlineSize: SIDEBAR_WIDTH }}>
+        Project sidebar
+      </aside>
+      <div
+        ref={safeAreaRef}
+        style={{ position: 'absolute', insetBlock: 0, insetInlineStart: SIDEBAR_WIDTH, insetInlineEnd: 0, pointerEvents: 'none' }}
+      />
+    </div>
+  )
+})
+```
+
+- `LayoutSlots.SharedCanvas` renders the scene. It is absolutely positioned and fills its nearest positioned ancestor, so the layout's root is positioned and covers the page. The layout positions its own UI above the canvas and after it in the markup, as the `aside` does; unpositioned content is painted under the canvas.
+- `useSceneSafeArea()`, called without arguments, tells the camera which part of the canvas the UI leaves free. Attach `containerRef` to the element that covers the whole canvas and `safeAreaRef` to the region the scene should stay visible in: the hook measures the gap between the two and the camera frames the scene inside the safe area. Without it the scene is framed in the whole canvas. The safe-area element lies over the canvas, so it sets `pointerEvents: 'none'` to leave orbiting and clicking to the scene. A `canvasPadding` component in the spec scales the measured gaps, see [Canvas Padding](?path=/docs/layouts-canvas-padding--docs).
+- The layout has to mount `LayoutSlots.SharedCanvas`, or the project sets `appLoader: legacy`. Otherwise the app loader stays on screen.
+- The layout composes the rest from what `@salsita-ai/sdk/configurator` exports: `LayoutSlots.Services` and the other members of `LayoutSlots`, which [Layout Slots](?path=/docs/phoenix-layout-slots--docs) lists with what each shows, what feeds it, what it renders when the spec configures nothing for it and what it does in read mode.
+- `LayoutSlots.DesktopSidebar` is the built-in desktop sidebar as one piece: the spec's tabs, back button, property pages and sidebar footer with their spacing, scrolling and empty states, and the assistant panel. Use it when the spec's property pages are what the customer should see and only their place changes, for example a sidebar on the left; build the controls yourself when they have to look like the brand's own. Without `width` it fills its container, so the layout positions and sizes that container; `miniSidebar` does not shrink it, so a layout that honours it reads `LayoutSlots.useSidebarContent().hasMiniSidebar` and lets the container take the sidebar's height. Its tabs sit outside it on the left; `side="start"` puts them on its right, for a sidebar on the left. In fullscreen it stays in place, transparent and inert, so a layout that wants the space back removes it while `phx.frontend.useIsFullscreenActive()` is set. See [Sidebar in a Custom Layout](?path=/docs/layouts-sidebar-in-a-custom-layout--docs).
+- Nothing of the built-in layouts is rendered for it. A project layout finalizes over the spec's `finalizeAction` components, see the finalize paragraph of [Hooks for a Project Layout](#hooks-for-a-project-layout). The `finalizePage` and `finalizeButton` components are legacy: they cannot be declared in YAML, only in TypeScript, and `Legacy.CommonFinalizePage`, which is deprecated, shows a `finalizePage` for projects that still have one. `LayoutDialog` renders only what the project registers with `createLayoutDialog` and is not part of the finalize flow. The preview start screen is `DesktopPreview` or `MobilePreview`, which the layout shows while `usePreview().isPreview` is set. Both previews frame the scene themselves, so the layout renders the component that calls `useSceneSafeArea()` only while `isPreview` is not set; it then measures when it mounts after the preview. The assistant panel is available to a project layout only inside `LayoutSlots.DesktopSidebar`.
+- The layout reads the state it has to react to from hooks, listed with what each returns in [Hooks for a Project Layout](#hooks-for-a-project-layout).
+- Messages for the user come one of two ways. `LayoutSlots.Services` shows violations of a rejected change, side-effect hints and errors as the built-in snackbars, which render into `LayoutSlots.DesktopSnackbarsRoot` or `LayoutSlots.MobileSnackbarsRoot` wherever the layout mounts it. `phx.frontend.useConfiguratorMessages(onMessage)` hands the same messages to the layout's own UI instead, with their text resolved, as the toast in [Custom Layout](?path=/docs/layouts-custom-layout--docs#show-messages) does; mount one of the two, not both, or every message is shown twice. Some messages stay snackbars either way: a failure to save the configuration and an error of the built-in finalize and other actions. They render into the snackbar root, so a layout that mounts none shows them outside the configurator, in the page's `body`. An error while a preset is applied appears on the preset screen, outside the layout.
+- Any project layout element named `ConfiguratorLayout` takes over the page.
+
+#### Hooks for a Project Layout
+
+A project layout reads the product and the configurator's state through hooks, and changes them through the functions the hooks return. Each row names where its hook comes from; the `phx.frontend` hooks in these tables are also exported from `@salsita-ai/sdk/react` under the same name. No hook looks at read mode: the control hooks and the navigation and fullscreen setters keep working while `accessInfo.viewMode` is `true`, so the layout decides what a viewer can change.
+
+**The product**
+
+| Hook                                                                            | Returns                                                                                                                                                                                                                                                                                                                         |
+| ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `phx.frontend.useRootEntityId()`                                                | The id of the root entity, which the control hooks take.                                                                                                                                                                                                                                                                        |
+| `phx.frontend.useSelectedDomainEntityId()`                                      | The id of the selected entity, or the root entity's id while nothing is selected.                                                                                                                                                                                                                                               |
+| `phx.frontend.useFirstRootComponent(componentType)`                             | The first component of that type on the root entity as `{ componentInstance, state }`, or `null` without one. It takes a component type such as `detailComponent` from `@salsita-ai/sdk/domain`, or an array of them. The `detail` component's `state` is `{ title, subtitle, description, thumbnailUrl? }`, all `Localizable`. |
+| `phx.frontend.useComponents({ componentTypes, entityIds?, instanceNames? })`    | Every matching component on any entity, as `{ componentInstance, state }[]`. Its type on `phx.frontend` includes `null`, but it returns an empty array when nothing matches.                                                                                                                                                    |
+| `phx.frontend.useRootEntityPrice()` and `phx.frontend.useEntityPrice(entityId)` | The value of the entity's `price` component formatted as currency for the current locale, in the component's `currency` or `USD`, or `null` without a `price` component.                                                                                                                                                        |
+
+**Controls**
+
+| Hook                                                         | Returns                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| ------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `phx.frontend.useAttributeSelection(entityId, instanceName)` | `{ value, options }`. Each option has `title` and `description` (`Localizable`, the spec's `label` and `description`), `value`, `imageSrc` (the spec's `img`), `disabled`, `error`, `hint` (a `string` saying why it is disabled, or `undefined`) and `onSelect()`, which writes the option; the selected option's `onSelect` does nothing. It throws when the entity has no `attributeSelection` component named `instanceName`. |
+| `phx.frontend.useAttributeSwitch(entityId, instanceName)`    | `{ state, onChange, disabled, error, hint }`: `state.value` is the boolean and `onChange()` writes its opposite. It throws without the component.                                                                                                                                                                                                                                                                                 |
+
+The other control hooks in [Controls](#controls) take the same two arguments, `useSwatchSelection` a required third. `useSwatchSelection` returns `{ value, options }`, where `value` is the selected swatch key and each option is `{ swatchName, onClick, swatchKey, selected, thumbnailUrl, disabled, color, hint?, trace? }`; `useTextValue` and the dimension hooks return `{ value, hints, hasErrors, update, resolve, trace }` instead, where `update(value)` stages a value the scene shows at once (`useTextValue`'s is an `onChange` handler, `update(event, value)`) and `resolve()` commits it, or rolls it back when it breaks an invariant. Their TypeScript types give the exact shapes, and [Custom Controls](?path=/docs/controls-custom--docs) lists them.
+
+**Texts**
+
+Texts from the spec, such as option titles and the `detail` fields, are `Localizable`, not `string`. `useResolveLocalizable()` from `@salsita-ai/sdk/react` returns a function that turns one into a string in the current language, which suits a list; `useLocalizable(text)` and `<LocalizableMessage>` resolve a single text, see [Localization](?path=/docs/phoenix-localization--docs).
+
+**Mode, fullscreen, preview and navigation**
+
+| Hook                                                                         | Returns                                                                                                                                                                                                                                                                  |
+| ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `phx.frontend.useAccessService()`                                            | `{ configurationId, accessInfo }`. `accessInfo.viewMode` is `true` while a configuration shared for viewing is open, and also while the host sets the `readonly` property.                                                                                               |
+| `phx.frontend.useIsFullscreenActive()` and `phx.frontend.useSetFullscreen()` | The fullscreen flag, a `boolean`, and a function `(enabled: boolean) => void` that sets it.                                                                                                                                                                              |
+| `usePreview()` from `@salsita-ai/sdk/configurator`                           | `{ isPreview, isExpanded, isPreviewEnabled, isHidden, enter, leave }`. The layout shows a preview start screen while `isPreview` is `true`.                                                                                                                              |
+| `phx.frontend.useActiveNavigationState()`                                    | The active navigation state, one of the spec's `navigationStates`.                                                                                                                                                                                                       |
+| `phx.frontend.usePushNavigate()` and `phx.frontend.usePopNavigate()`         | `(state) => void`, which enters a state and remembers the active one, and `() => void`, which returns to the remembered state and does nothing when there is none. `phx.frontend.useNavigate()` returns `(state) => void`, which enters a state and forgets the history. |
+| `phx.frontend.useActiveViewState()` and `phx.frontend.useActiveToolState()`  | The active view state and tool state.                                                                                                                                                                                                                                    |
+| `useActiveViewports()` from `@salsita-ai/sdk/react`                          | The responsive breakpoints the configurator's container satisfies, as `Viewport[]`, or `null` before it is measured. It follows the container, not the window, so it is the switch between a desktop and a phone layout.                                                 |
+
+**Violations**
+
+| Hook                                              | Returns                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
+| ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `phx.frontend.useStateValidity()`                 | The validity of the last committed state: `{ valid: true, severity: null }`, or `{ valid: true, severity: 'notice' \| 'warning', entityViolations }`. A change that leaves a `fixable` or `fatal` violation is rejected and never committed, and neither is a change during which an error was thrown, so neither is seen here.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| `phx.frontend.useFinalizeViolations()`            | `{ disabled, hints, violations }`. `disabled` is `true` while a `warning`, `fixable` or `fatal` violation holds or the configuration failed to save; `hints` is the violations' text, or `undefined`.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                     |
+| `phx.frontend.useConfiguratorMessages(onMessage)` | Nothing. It calls `onMessage(message)` once per message: `{ kind: 'violation', entityId, violation, text }` for each violation of the rejected state, including notices and warnings already present, so `violation.severity` tells the reason for the rejection (`fixable` or `fatal`) from them, `{ kind: 'sideEffect', text }` for each hint of a committed update, and `{ kind: 'error', error, text }` when an error is thrown while a change is validated, with `text` the generic "Oops, something went wrong". `text` is resolved to the current language; a violation's is its `message`, or its `type` without one, and the built-in snackbar prefixes it with `entityId`. Hints committed before the layout mounted are not delivered; when the most recent change was rejected or threw, its messages are delivered again when the hook mounts. `onMessage` may be a new function on every render. On `phx.frontend` the message is typed by the project, so `violation.type` narrows to its violation types; from `@salsita-ai/sdk/react` the type is `ConfiguratorMessage`. |
+
+`LayoutSlots.Services` shows the messages of `useConfiguratorMessages` as snackbars; see the messages paragraph of [Loaded Configuration UI](#loaded-configuration-ui) for choosing between the two and for the messages that stay snackbars.
+
+**Finalize**
+
+A project layout finalizes over the spec's `finalizeAction` components. `phx.frontend.useComponents({ componentTypes: [finalizeActionComponent] })`, with `finalizeActionComponent` from `@salsita-ai/sdk/domain`, lists them; each `state` is `{ variant, label, title, icon, handler }`, where `variant` is `'primary'` or `'secondary'` and `handler` names the project's handler registered with `phx.frontend.createPhoenixHandler`. The built-in footer offers the first `'primary'` action, or else the first action, as its button and the others in a menu, and disables them with `phx.frontend.useFinalizeViolations()`.
+
+To offer the same buttons, a project layout mounts `<FinalizeActions />` from `@salsita-ai/sdk/configurator`: the built-in footer's finalize buttons, the primary action plus a menu of the others, disabled with the hints of `useFinalizeViolations()`, with a spinner while the handler runs and a snackbar when it fails. It renders nothing without a `finalizeAction`, and it does not check read mode, so a layout hides it while `accessInfo.viewMode` is `true`.
+
+To build its own buttons, a layout runs an action with `usePhoenixHandler(action.state.handler).handler()` from `@salsita-ai/sdk/react`, which returns a promise. `usePhoenixHandler` runs the project's handler factory, which calls hooks, so each action gets its own component that calls it once, never in a loop, and that component is wrapped in `<PhoenixHandlerBoundary name={action.state.handler}>` from the same import, so an edited handler takes effect without a reload. The layout then shows the pending state, the error and the disabled state from `useFinalizeViolations()` itself.
+
 ## TransformerBuilder
 
 Use `transformerBuilder` to create entity transformers:
 
 ```typescript
 // Create a transformer that runs when specific conditions are met
-const cabinetTransformer = phx.frontend.transformerBuilder
-  .when(Cabinet.is)
-  .do((cabinet, context) => {'{'}
-    // Transform cabinet data
-    return {'{'}
-      ...cabinet,
-      $computedField: calculateSomething(cabinet)
-    {'}'}
-  {'}'})
+const cabinetTransformer = phx.frontend.transformerBuilder.when(Cabinet.is).do((cabinet, context) => {
+  // Transform cabinet data
+  return {
+    ...cabinet,
+    $computedField: calculateSomething(cabinet),
+  }
+})
 ```
 
 **Note**: The deprecated `createTransformer` function should not be used for new implementations.
@@ -407,19 +511,19 @@ const cabinetTransformer = phx.frontend.transformerBuilder
 The `updates` factory creates type-safe entity updates:
 
 ```typescript
-const {'{'} storeSystem {'}'} = phx.frontend.useDomain()
+const { storeSystem } = phx.frontend.useDomain()
 
 // Create new entity
-const createUpdates = phx.frontend.updates.create({'{'}
+const createUpdates = phx.frontend.updates.create({
   type: 'Cabinet',
   width: 800,
   height: 2000,
-{'}'})
+})
 
 // Modify existing entity
-const modifyUpdates = phx.frontend.updates.modify(cabinetId, {'{'}
+const modifyUpdates = phx.frontend.updates.modify(cabinetId, {
   width: 1000,
-{'}'})
+})
 
 // Delete entity
 const deleteUpdates = phx.frontend.updates.delete(cabinetId)

package/dist/docs/phoenix/deployments.mdx

@@ -464,7 +464,7 @@ Error: Failed to upload to S3
 
 - Run `deployment:prepare` again to get fresh presigned URLs
 - Check that `.upload-links.json` exists and is readable
-- Use `--skipUpload` / `-su` flag to test without uploading assets
+- Use `--skipUpload` / `--su` flag to test without uploading assets
 
 ### "Server URL is required"
 

package/dist/docs/phoenix/domain-model.mdx

@@ -565,9 +565,13 @@ A relation pair can have at most one composition owner. For an ownership relatio
 Relations are validated when the application spec is parsed:
 
 - **Every relation must be declared from both sides.** A relation on `A` targeting `B` needs a counterpart declared on `B` (or on an alias containing `B`) pointing back at `A` — with the opposite kind (`direct` ↔ `indirect`, `allOfType` ↔ `allOfType`) and the same `field`. A missing or mismatched counterpart fails parsing with `RELATION_MISSING_COUNTERPART`. Self‑referencing relations (target is the declaring type) act as their own counterpart and are exempt.
+- **The field of a relation must hold references to the entities the relation relates to.** A `direct` relation reads a field of the entity it is declared on, and the field must reference exactly the entity types of the target. An `indirect` relation reads a field of the target, and the field must reference exactly the entity types the relation is declared on. A field that is not a `DomainEntityId` with `references` fails parsing with `RELATION_FIELD_NOT_REFERENCE`, and one that references other entity types with `RELATION_FIELD_REFERENCES_OTHER_TYPES`.
+- **The field of a `direct` relation must hold its references the way the cardinality needs.** `1-1` needs one reference that is never `null`, `0-1` one reference or `null`, and `0-N` or `1-N` an array of references. Anything else fails parsing with `RELATION_FIELD_CARDINALITY_MISMATCH`. An `indirect` relation takes any of the three, because its cardinality counts the entities that point back.
 - **At most one side may carry `composedOf: true`.** A pair may have one owner or no owner. Two owning sides fail parsing with `RELATION_COUNTERPART_COMPOSED_OF_MISMATCH` because the pair would define ownership in both directions.
 - **Every entity type must be reachable from the root** through `composedOf` edges, otherwise parsing fails with `RELATION_ENTITY_NOT_IN_COMPOSITION_TREE`.
 
+**What the field checks leave out.** A field whose schema states its type as text (`tsType`) or combines schemas with `allOf` is not checked, because the parser cannot tell what it holds. With a wrong field of that kind a `direct` relation fails when it is read, and an `indirect` relation finds no related entities and fails only if its cardinality requires one. When an alias holds the field, the relation is accepted if the field fits in at least one entity type of the alias.
+
 **Why both sides?** The two declarations feed two different runtime systems. The `direct` side owns the id field and generates the reference bookkeeping: dangling ids are pruned when the referenced entity is deleted, and ids are written on create and replace. The `composedOf: true` side generates the composition edge: cascade deletes, the scene hierarchy, and the reachability check. Because these can be different entities — a parent may collect children by reverse lookup (`indirect` + `composedOf: true`) while each child stores the id — dropping either declaration silently disables one of the systems: without the parent side, deleting the parent leaves its children orphaned; without the child side, deleted entities leave dangling ids behind. The missing side also cannot be generated automatically, because the stored id field is compatible with many different relations: the reverse accessor's name is public API, and its cardinality (`0-N`, `1-N`, or a `0-1` slot) changes the generated types, state validation, and UI affordances without changing the stored data at all. Requiring both declarations turns these mistakes into parse errors instead of runtime surprises, and the redundancy lets the parser cross‑check the pair — a typo in `field` or a doubled owner is caught immediately.
 
 ### Picking a relation kind

package/dist/docs/phoenix/expression-context.mdx

@@ -35,15 +35,23 @@ interface ExpressionContext<
 
   // System services
   readonly domain: Domain // Access to domain model and other entities
-  readonly componentReader: ComponentReader // Read component states across all entities
   readonly migrate: MigrateFunction // Data migration utilities
-  readonly sketchingProjections: SketchingProjections // Sketching system projections
-  readonly collisionProjections: CollisionProjections // Collision detection projections
+  readonly componentReader: ComponentReader // Read component states across all entities
+
+  // Projections
+  readonly positionProjections: PositionProjections // World matrices of scene entities
+  readonly sketchingProjections: SketchingProjections // Shapes and connections of a sketch
+  readonly collisionProjections: CollisionProjections // Collision meshes and collisions between entities
+  readonly constraintProjections: ConstraintProjections // Spatial constraints an entity violates
+  readonly snappingProjections: SnappingProjections // Snap points, edges, planes and matches
+  readonly projectedEntitiesProjections: ProjectedEntitiesProjections // Data of projected entities
 }
 ```
 
 The context includes data sources (session, published, frontend, backend), system services (domain access, component reader, projections), and application state (mode, role). Each part serves a different purpose in expression calculations.
 
+The SDK declares the context in two parts. `CoreExpressionContext` holds the mode, the role, the data sources, `domain` and `migrate`. `RuntimeExpressionContext` holds the component reader and the projections. An editor hover or a type error therefore shows `ctx` as `OpenExpressionContext<..., RuntimeExpressionContext<AnyDomainEntity>>`, which has the members listed above. A helper of your own that takes the context declares its parameter as `ExpressionContext` with the five types of your project.
+
 ### Configurator Modes
 
 The `mode` property indicates the current operational context of the configurator. Different modes enable different functionality and access levels. Expressions can check the mode to change their behavior.

package/dist/docs/phoenix/finalization.mdx

@@ -15,7 +15,7 @@ Finalization is Phoenix's system for completing configurator sessions and proces
 
 > For integration-specific finalization flows — how host-specific data is passed in and how the host is notified on completion (event dispatch in `headless`, redirect in `handoff`) — see [Finalization (Internal)](?path=/docs/phoenix-integration-finalization-internal--docs) and [Finalization (External)](?path=/docs/phoenix-integration-finalization-external--docs).
 
-Phoenix selects one primary footer action and places additional finalization actions in its menu. A configured `finalizePage` opens in a dialog. Built-in finalization actions use configuration validity to disable the footer action and provide pending and generic error states, including for add-to-cart handlers. See [Universal Sidebar Footer](?path=/docs/layouts-sidebar-footer-universal--docs) for the layout behavior.
+The universal sidebar footer offers the spec's `finalizeAction` components: Phoenix selects one primary footer action and places additional finalization actions in its menu. It never opens a `finalizePage`; the `finalizePage` and `finalizeButton` components are legacy, declared only in TypeScript, and used by the basic sidebar footer and the legacy layouts. Built-in finalization actions use configuration validity to disable the footer action and provide pending and generic error states, including for add-to-cart handlers. See [Universal Sidebar Footer](?path=/docs/layouts-sidebar-footer-universal--docs) for the layout behavior.
 
 ## How Finalization Works
 

package/dist/docs/phoenix/getting-started.mdx

@@ -86,7 +86,7 @@ For inspiration and real-world implementation patterns, examine deployed Salsita
 
 When you encounter challenges or need to implement specific features, use these resources in order:
 
-**AI-Powered Assistance**: Every Phoenix project ships `AGENTS.md` and Phoenix agent skills, so coding agents in your project already know the SDK conventions and CLI. Start by using AI coding assistants in the `configurator-phoenix` project. While they may not solve complex problems directly, they can point you toward relevant examples or search terms that will help you find the right solution.
+**AI-Powered Assistance**: Every Phoenix project ships Phoenix agent skills, so coding agents in your project already know the SDK conventions and CLI. Start by using AI coding assistants in the `configurator-phoenix` project. While they may not solve complex problems directly, they can point you toward relevant examples or search terms that will help you find the right solution.
 
 **Storybook Documentation**: Search the Phoenix Storybook for functionality similar to what you need. When you find relevant examples, examine the corresponding code in the configurator-phoenix stories to understand the implementation details.