@salsita-ai/sdk 0.50.0-develop.da8d27f5d7 → 0.50.0-develop.dbf0122072

package/dist/docs/other-features/domain-actions.mdx

@@ -0,0 +1,418 @@
+# Domain Actions
+
+- [Use case](#use-case)
+- [Declare the action](#declare-the-action)
+- [Implement it](#implement-it)
+- [Run it from the UI](#run-it-from-the-ui)
+- [Expose it to the assistant](#expose-it-to-the-assistant)
+- [Known gaps](#known-gaps)
+- [Example](#example)
+
+## Use case
+
+A plate carries holes, and a hole can be nudged by an offset as long as it stays on the plate. The arrow buttons of a selected hole and the AI assistant both make this change, so the rule ("stay on the plate") has to live in one place.
+
+An **action** is that place: a named domain operation you declare once under `actions:`, implement in `src/actions/` with generated parameter and result types, and run from any control through `actionSystem.prepareAction()`. The same action is exposed to the assistant as a custom mutation by naming it under `assistant.actions`. Use an action whenever a change is more than writing one field: a swap, a move among siblings, a change that touches several entities at once.
+
+## Declare the action
+
+`params` and `result` are maps of named JSON schemas, with the same `phx:` refs, `references`, `tsType` and `import` as entity shapes. A param whose schema allows `null` is optional; every other param is required. A result member typed `phx:$DomainEntity` is the enhanced entity after the change.
+
+```yaml
+actions:
+  nudgeHole:
+    description: Moves a hole by an offset on the plate; the move fails when the hole would leave the plate
+    params:
+      holeId:
+        $ref: phx:DomainEntityId
+        references: Hole
+        description: The hole to move
+      dx:
+        type: integer
+        description: Offset along the x axis, in plate units
+      dy:
+        type: integer
+        description: Offset along the y axis, in plate units
+    result:
+      hole:
+        $ref: phx:$DomainEntity
+        references: Hole
+        description: The hole at its new position
+      plate:
+        $ref: phx:$DomainEntity
+        references: Plate
+        description: The plate after the move
+```
+
+Generation derives the types `ActionTypes`, `ActionName`, `ActionParams<'nudgeHole'>` and `ActionResult<'nudgeHole'>` from it: here `ActionParams<'nudgeHole'>` is `{ holeId: Hole['id']; dx: number; dy: number }` and `ActionResult<'nudgeHole'>` is `{ hole: $Hole; plate: $Plate }`. The `description` of the action, of a param and of a result member becomes the doc comment of its generated property, so it shows in the editor wherever the action is implemented or called.
+
+## Implement it
+
+A file in `src/actions/` default-exports `phx.domain.implementActions({...})` with any subset of the declared actions. The implementation receives the validated parameters, the state the action runs on, and a context with the `expressionContext`, the domain `systems`, `getIdSequence()` for entities it creates and the typed `updates` factory. It returns the updates it wants applied and `readResult`, which reads the result from the state those updates produced, including whatever the transformers added. It never stages or commits anything.
+
+```ts
+// src/actions/nudge-hole.ts
+export default phx.domain.implementActions({
+  nudgeHole: ({ holeId, dx, dy }, state, { systems: { domain }, updates }) => {
+    // `references: Hole` types the id, but any entity id passes the runtime check, so the entity is verified here.
+    const hole = state.entities.find(entity => entity.id === holeId)
+
+    if (hole?.type !== 'Hole') {
+      throw new Error(
+        `"${holeId}" is not a hole of the plate, so it cannot be nudged. Query the plate's holes and use an id they return.`
+      )
+    }
+
+    const x = hole.x + dx
+    const y = hole.y + dy
+
+    if (Math.abs(x) > 150 || Math.abs(y) > 150) {
+      throw new Error(
+        `Nudging "${holeId}" by (${dx}, ${dy}) would put it at (${x}, ${y}), outside the plate. Keep both coordinates between -150 and 150.`
+      )
+    }
+
+    return {
+      updates: [updates.DomainEntityModification({ entityId: hole.id, stateDelta: { x, y }, updateTag: 'nudgeHole' })],
+      readResult: ({ state: nudged }) => ({
+        hole: domain.get$Entity(holeId, nudged),
+        plate: domain.getRoot$Entity(nudged),
+      }),
+    }
+  },
+})
+```
+
+Throw to reject a call: the message reaches the user through the control's hint and the assistant through the failed mutation, so say what went wrong and what to send instead. An action declared without an implementation, or an implementation of a name the spec does not declare, is a type error. A declared action without an implementation also stops the domain from initializing, and under `phoenix dev` the editor reports it as a `MISSING_ACTION_IMPLEMENTATIONS` diagnostic and does not apply the change; an implementation of an undeclared name is logged.
+
+## Run it from the UI
+
+`phx.frontend.useDomain().actionSystem.prepareAction(name, args, state)` validates `args` against the declared params and returns `{ updates, readResult }`. Hand the updates to `useUpdateControl()` like any other change: it dry-runs them for hints and commits them on click.
+
+```tsx
+export default phx.frontend.createCustomPhoenixEntityElement('NudgeControl', ({ entityId }) => {
+  const { actionSystem } = phx.frontend.useDomain()
+  const state = phx.frontend.useCommittedState()
+  const prepare = phx.frontend.useUpdateControl()
+
+  const left = prepare(actionSystem.prepareAction('nudgeHole', { holeId: entityId, dx: -20, dy: 0 }, state).updates)
+
+  return (
+    <Button disabled={left.disabled} title={left.hints} onClick={left.update}>
+      ←
+    </Button>
+  )
+})
+```
+
+`prepareAction` throws for arguments that do not fit the params, for an unknown action and for whatever the implementation rejects, so a control that may ask for an impossible move catches the error and shows its message, as the example's control does.
+
+## Expose it to the assistant
+
+Naming the action under `assistant.actions` adds a `Mutation` field with one argument per param and a `<Name>Result` type whose entity members are traversable edges. `as` renames the field, `description` replaces the action's.
+
+```yaml
+assistant:
+  actions:
+    nudgeHole:
+```
+
+```graphql
+type Mutation {
+  nudgeHole(holeId: ID!, dx: Int!, dy: Int!): NudgeHoleResult!
+}
+
+type NudgeHoleResult {
+  hole: Hole!
+  plate: Plate!
+}
+```
+
+The field runs the same `prepareAction`, applies the updates through the same validation as every other mutation, and fails with the action's message when the call is rejected.
+
+## Known gaps
+
+- `references` on a `phx:DomainEntityId` param types the parameter and the GraphQL argument, but at runtime any entity id passes the params check: the implementation verifies that the id names an entity of the expected type, as the example does.
+- Actions exist in the configurator domain only; the admin domain declares none.
+- The result of `readResult` is not validated at runtime: the generated TypeScript type and the GraphQL coercion are the checks.
+- The assistant cannot dry-run a custom mutation the way it dry-runs recipes and field options.
+- `useDomain()` types `prepareAction` with the generic action map, so the name and the arguments are not checked against your `ActionTypes` at that call site; the implementation side is fully typed.
+
+## Example
+
+Select a hole and nudge it with the arrows. A move that would leave the plate is disabled with the action's message.
+
+## Complete Implementation
+
+{/* AUTO-GENERATED SECTION: This section is automatically updated by 'phoenix story build' */}
+
+<details>
+<summary>Click to view the complete implementation files</summary>
+
+### ./spec/domain.yaml
+
+```yaml
+model:
+  latest:
+    entityTypes:
+      - Plate
+      - Hole
+    aliases:
+      RootEntity:
+        - Plate
+    shapes:
+      Hole:
+        x:
+          type: number
+        y:
+          type: number
+
+relations:
+  Plate:
+    $holes:
+      kind: allOfType
+      target: Hole
+      cardinality: 0-N
+      composedOf: true
+  Hole:
+    $plate:
+      kind: allOfType
+      target: Plate
+      cardinality: 1-1
+      composedOf: false
+
+expressions:
+  Hole:
+    $radius:
+      type: number
+
+# A named domain operation: declared once, implemented in src/actions/, run by the NudgeControl
+# element and by the assistant alike.
+actions:
+  nudgeHole:
+    description: Moves a hole by an offset on the plate; the move fails when the hole would leave the plate
+    params:
+      holeId:
+        $ref: phx:DomainEntityId
+        references: Hole
+        description: The hole to move
+      dx:
+        type: integer
+        description: Offset along the x axis, in plate units
+      dy:
+        type: integer
+        description: Offset along the y axis, in plate units
+    result:
+      hole:
+        $ref: phx:$DomainEntity
+        references: Hole
+        description: The hole at its new position
+      plate:
+        $ref: phx:$DomainEntity
+        references: Plate
+        description: The plate after the move
+
+assistant:
+  ai:
+    provider: openai
+    model: balanced
+    reasoning: low
+  entities:
+    Plate:
+      $holes:
+        description: The holes of the plate
+    Hole:
+      x:
+      y:
+  actions:
+    nudgeHole:
+
+presets:
+  - rootEntityType: 'Plate'
+    initialDomainEntities:
+      - id: 'Plate-1'
+        type: 'Plate'
+      - id: 'Hole-1'
+        type: 'Hole'
+        x: -60
+        y: 40
+      - id: 'Hole-2'
+        type: 'Hole'
+        x: 70
+        y: -50
+
+components:
+  Plate:
+    applicationConfig:
+      main:
+        layout: 'universal'
+    staticPerspectiveCamera:
+      main:
+        distance: 400
+        priority: 1
+        polarAngle: 1.2
+        azimuthAngle: -0.2
+    sceneEntityProperties:
+      main:
+        offsetX: -100
+        offsetY: -100
+        offsetZ: -10
+    sceneEntityObject:
+      Plate:
+        object:
+          $read: $render
+    detail:
+      main:
+        title: 'Plate'
+        subtitle: 'A plate with holes'
+        description: 'Select a hole to nudge it.'
+  Hole:
+    sceneEntityProperties:
+      main:
+        offsetX:
+          $read: x
+        offsetY:
+          $read: y
+    sceneEntitySelectHotspot:
+      main:
+        offsetX: 15
+        offsetY: 15
+        offsetZ: 30
+    detail:
+      main:
+        title: 'Hole'
+        subtitle: 'A hole in the plate'
+        description: 'Nudge it with the arrows; a hole cannot leave the plate.'
+    propertyPage:
+      main:
+        children:
+          - kind: propertyContainerGroup
+            props:
+              spacing: large
+            children:
+              - kind: customElement
+                props:
+                  name: NudgeControl
+```
+
+### ./src/actions/nudge-hole.ts
+
+```ts
+import { phx } from '../../.phoenix/phx.js'
+
+/** How far a hole may sit from the plate's center on either axis, in plate units. */
+const REACH = 150
+
+export default phx.domain.implementActions({
+  nudgeHole: ({ holeId, dx, dy }, state, { systems: { domain }, updates }) => {
+    // `references: Hole` types the id, but any entity id passes the runtime check, so the entity is verified here.
+    const hole = state.entities.find(entity => entity.id === holeId)
+
+    if (hole?.type !== 'Hole') {
+      throw new Error(
+        `"${holeId}" is not a hole of the plate, so it cannot be nudged. Query the plate's holes and use an id they return.`
+      )
+    }
+
+    const x = hole.x + dx
+    const y = hole.y + dy
+
+    if (Math.abs(x) > REACH || Math.abs(y) > REACH) {
+      throw new Error(
+        `Nudging "${holeId}" by (${dx}, ${dy}) would put it at (${x}, ${y}), outside the plate. Keep both coordinates between ${-REACH} and ${REACH}.`
+      )
+    }
+
+    return {
+      updates: [updates.DomainEntityModification({ entityId: hole.id, stateDelta: { x, y }, updateTag: 'nudgeHole' })],
+      readResult: ({ state: nudged }) => ({
+        hole: domain.get$Entity(holeId, nudged),
+        plate: domain.getRoot$Entity(nudged),
+      }),
+    }
+  },
+})
+```
+
+### ./src/elements/NudgeControl.tsx
+
+```tsx
+import { Button, Stack } from '@mui/material'
+
+import { PropertyContainer } from '@salsita-ai/sdk/ui'
+
+import { phx } from '../../.phoenix/phx.js'
+
+const STEP = 20
+
+/** Nudges the selected hole with the same `nudgeHole` action the assistant calls, one step at a time. */
+export default phx.frontend.createCustomPhoenixEntityElement('NudgeControl', ({ entityId }) => {
+  const { actionSystem } = phx.frontend.useDomain()
+  const state = phx.frontend.useCommittedState()
+  const prepare = phx.frontend.useUpdateControl()
+  const hole = state.entities.find(entity => entity.id === entityId)
+
+  if (hole?.type !== 'Hole') {
+    return <></>
+  }
+
+  // An action throws when the move leaves the plate; the button for that direction is then disabled with the message.
+  const nudge = (dx: number, dy: number) => {
+    try {
+      return prepare(actionSystem.prepareAction('nudgeHole', { holeId: hole.id, dx, dy }, state).updates)
+    } catch (error) {
+      return { disabled: true, hints: error instanceof Error ? error.message : String(error), update: () => {} }
+    }
+  }
+
+  const directions = [
+    { label: '←', dx: -STEP, dy: 0 },
+    { label: '→', dx: STEP, dy: 0 },
+    { label: '↑', dx: 0, dy: STEP },
+    { label: '↓', dx: 0, dy: -STEP },
+  ]
+
+  return (
+    <PropertyContainer.Item title="Nudge" description={`Moves the hole by ${STEP} units.`}>
+      <Stack direction="row" spacing={1}>
+        {directions.map(({ label, dx, dy }) => {
+          const control = nudge(dx, dy)
+
+          return (
+            <Button
+              key={label}
+              variant="outlined"
+              disabled={control.disabled}
+              title={control.hints ?? undefined}
+              onClick={event => {
+                event.stopPropagation()
+                control.update()
+              }}
+            >
+              {label}
+            </Button>
+          )
+        })}
+      </Stack>
+    </PropertyContainer.Item>
+  )
+})
+```
+
+### ./src/expressions/plate.ts
+
+```ts
+import { createPlate } from '../../../../common/plate-rendering.js'
+import { phx } from '../../.phoenix/phx.js'
+
+export default phx.domain.implementCustomExpressions({
+  Hole: {
+    $radius: () => 10,
+  },
+  Plate: {
+    $render: plate => createPlate({ features: plate.$holes }),
+  },
+})
+```
+
+</details>

package/dist/docs/other-features/side-effects.mdx

@@ -102,6 +102,32 @@ configuratorBuilder
   .buildConfig()
 ```
 
+### Hints and the AI assistant
+
+In a configurator with the AI assistant, the assistant is told the same hints: they arrive as
+`sideEffects` with the result of its changes and in the dry-runs of recipes and options, so it can
+tell the user what else happened. The hints also explain what the user changed between two messages:
+every message carries a change record of the configuration, and each of its lines ends with the hint
+of the last update that touched it, or with the `updateTag` when the update has none. Set `agentHint`
+beside `hint` when the assistant needs different wording, for example with ids or values a snackbar
+would not show:
+
+```ts
+phx.frontend.updates.DomainEntityModification({
+  entityId: oldPlate.id,
+  stateDelta: { finish: validMaterial.finish },
+  updateTag: 'fix.finish',
+  hint: msg`Material finish was adjusted`,
+  agentHint: `The finish of ${oldPlate.id} was changed to ${validMaterial.finish}, the only one this material comes in.`,
+})
+```
+
+- `agentHint` is a plain string, never shown to the user and not localized.
+- `agentHint: null` keeps the wording from the assistant while the user still gets the `hint`: the
+  update is left out of `sideEffects`, and the change record explains its line by the `updateTag`. It
+  does not hide the change itself, which the assistant can always read from the configuration.
+- `agentHint` without a `hint` tells only the assistant.
+
 ## Example
 
 Here you can see the live example!

package/dist/docs/phoenix/admin.mdx

@@ -421,7 +421,7 @@ export const handler = webhookBuilder
 
 The publishing workflow validates admin state, transforms entities, and stores JSON to S3. Configurators access published data via `ctx.publishedData` in expressions.
 
-For implementation examples, see `packages/demos/demo-finalize/src/handlers/map-published-revision-data.ts`.
+For implementation examples, see `packages/demos/demo-catalog-builder/src/handlers/map-published-chunked-data.ts`.
 
 For technical details about data transformation and storage, see [Data Sources - Published Data](?path=/docs/phoenix-data-sources--docs#published-data).
 
@@ -515,4 +515,4 @@ Ready to implement admin functionality in your Phoenix project? Here's what to e
 - **[Sessions and Access](?path=/docs/phoenix-sessions-and-access--docs)** - Understand admin authentication and permissions
 - **[Connected Data Sources](?path=/docs/phoenix-connected-data-sources--docs)** - Wire `$data` entries to Google Sheets or Excel; requires the embedded admin mode
 
-For hands-on examples, check out the finalize demo (`packages/demos/demo-finalize/`) which shows spec-driven admin using `createAdminPages` for presets and recipes. This demo demonstrates the YAML-based admin approach with publishing workflows rather than custom admin UI components.
+For hands-on examples, check out the Catalog Builder demo (`packages/demos/demo-catalog-builder/`), which shows spec-driven admin pages over connected and generated data, custom catalog pages beside them, admin model migrations, and the publishing workflow.

package/dist/docs/phoenix/best-practices.mdx

@@ -5,6 +5,7 @@
 1. **YAML is king** - 99% of configuration should be in spec/\*.yaml files
 2. **Custom code locations** (in order of preference):
    - `src/expressions/` - Computed/derived properties
+   - `src/actions/` - Named domain operations declared under `actions:`
    - `src/invariants/` - Business rule constraints
    - `src/transformers/` - Automatic state fixers
    - `src/handlers/` - Event & lifecycle handlers

package/dist/docs/phoenix/finalization.mdx

@@ -355,4 +355,4 @@ Now that you understand finalization workflows, explore these related topics:
 - **[Admin](?path=/docs/phoenix-admin--docs)** - Learn about admin finalization and published data generation
 - **[Best Practices](?path=/docs/phoenix-best-practices--docs)** - Follow proven patterns for finalization implementation
 
-For hands-on practice, explore the finalize demo in the **[Quickstart](?path=/docs/phoenix-quickstart--docs)** guide.
+For hands-on practice, explore the Precision demo (`packages/demos/demo-precision/`) for finalization resources — PDF, CSV, images, email attachments and callbacks — and the Catalog Builder demo (`packages/demos/demo-catalog-builder/`) for the finalization data lifecycle and access links.

package/dist/docs/phoenix/integration/headless-mode-external.mdx

@@ -51,11 +51,11 @@ For details on the server-side token exchange, see [Authentication](?path=/docs/
 
 The `power` attribute controls the configurator's state:
 
-| Value       | Behavior                                                                                                                                                 |
-| ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `"off"`     | Completely inactive. No rendering, no session, no network requests beyond loading the bundle.                                                            |
-| `"standby"` | Session initialized, assets preloaded (3D models, textures), but not rendered. Faster power-on, but consumes bandwidth and counts toward session quotas. |
-| `"on"`      | Fully active and visible.                                                                                                                                |
+| Value       | Behavior                                                                                                                                                                                                                 |
+| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `"off"`     | Completely inactive. No rendering, no session, no network requests beyond loading the bundle.                                                                                                                            |
+| `"standby"` | Session initialized and any textures listed in `resourcesConfig.prefetchTextureUrls` prefetched; nothing is rendered and no models are loaded. Faster power-on, but consumes bandwidth and counts toward session quotas. |
+| `"on"`      | Fully active and visible.                                                                                                                                                                                                |
 
 A typical flow: power on at login (`"standby"`), then toggle between `"on"` and `"standby"` as the user opens and closes the configurator. Use `"off"` only before the user has authenticated.
 

package/dist/docs/phoenix/integration/widget-mode-external.mdx

@@ -28,11 +28,11 @@ The configurator fills its parent container. Set a height on the element or a wr
 
 The `power` attribute controls whether the configurator is active. It accepts three values:
 
-| Value       | Behavior                                                                                                                                                                                             |
-| ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `"off"`     | Configurator is completely inactive. No rendering, no session initialization, no network requests beyond loading the bundle. Lowest resource usage.                                                  |
-| `"standby"` | Configurator initializes its session and preloads assets (3D models, textures), but does not render. Subsequent power-on is faster, but consumes bandwidth and counts toward monthly session quotas. |
-| `"on"`      | Configurator is fully active and visible.                                                                                                                                                            |
+| Value       | Behavior                                                                                                                                                                                                                                              |
+| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `"off"`     | Configurator is completely inactive. No rendering, no session initialization, no network requests beyond loading the bundle. Lowest resource usage.                                                                                                   |
+| `"standby"` | Configurator initializes its session and prefetches any textures listed in `resourcesConfig.prefetchTextureUrls`, but does not render or load models. Subsequent power-on is faster, but consumes bandwidth and counts toward monthly session quotas. |
+| `"on"`      | Configurator is fully active and visible.                                                                                                                                                                                                             |
 
 ### Choosing the Initial Power
 

package/dist/docs/phoenix/migrations.mdx

@@ -18,6 +18,8 @@ Each version defines its own:
 
 This versioning allows you to track changes over time and ensure proper migration paths.
 
+The version number is not written anywhere: `latest` is the highest numbered version plus one, so a model with only `latest` is version 1. Once a version has been deployed it cannot change, because saved configurations depend on it. `phoenix deploy` refuses a model that differs from the one deployed under the same version, before anything is uploaded. To change a deployed model, keep it unchanged as `v<N>`, make the change in `latest` and add the migration to version N+1. Development environments replace the deployed model instead, so `phoenix dev` accepts every change.
+
 ## Model File Structure
 
 It's recommended to split your model versions into separate files for better maintainability:
@@ -39,9 +41,11 @@ The CLI generates separate TypeScript types for each version, which helps ensure
 
 ```typescript
 // The Migration type ensures you handle all entity types
-type Migration<FromEntity, ToEntity> = (state: FromEntity[]) => ToEntity[]
+type Migration<FromEntity, ToEntity> = (state: readonly FromEntity[]) => readonly ToEntity[]
 ```
 
+The types of each version are generated as global namespaces: `ModelV1`, `ModelV2`, and so on. `ModelV1.AnyDomainEntity` is the union of all entities of version 1, and `ModelV1.<EntityType>` is one of them. The admin model has its own namespaces, `AdminV1`, `AdminV2`, and so on. A migration needs no import for them.
+
 ## Migration File Location
 
 Migration files are organized in the `src/migrations/` directory with a specific naming convention:
@@ -63,11 +67,16 @@ Each migration file should export a function named `migrateToVN` where N is the
 
 ```typescript
 // src/migrations/v2.ts
-export const migrateToV2: Migration<V1Entity, V2Entity> = state => {
+import type { Migration } from '@salsita-ai/sdk/domain'
+
+export const migrateToV2: Migration<ModelV1.AnyDomainEntity, ModelV2.AnyDomainEntity> = state => {
   // Transform entities from v1 to v2
+  return state
 }
 ```
 
+Keep the `Migration<...>` type on the export, with its `readonly` arrays: the generated domain file passes each migration to the migration builder, and a function typed with mutable arrays does not type-check there.
+
 **Note:** Migrations start from version 2. There is no migration TO v1 since v1 is the initial version. The first migration you write will be `migrateToV2`.
 
 The `ts-pattern` library is recommended for implementing migrations as it provides type-safe pattern matching.
@@ -77,11 +86,15 @@ The `ts-pattern` library is recommended for implementing migrations as it provid
 Migrations are implemented as functions that transform entities from one version to another. Each migration handles the transition between consecutive versions:
 
 ```typescript
-export const migrateToV4: Migration<V3Entity, V4Entity> = state => {
+import { match } from 'ts-pattern'
+
+import type { Migration } from '@salsita-ai/sdk/domain'
+
+export const migrateToV4: Migration<ModelV3.AnyDomainEntity, ModelV4.AnyDomainEntity> = state => {
   return state.map(entity => {
     return (
       match(entity)
-        .returnType<V4Entity>()
+        .returnType<ModelV4.AnyDomainEntity>()
         .with({ type: 'Burner' }, value => ({ ...value, y: 0 }))
         .with({ type: 'Cabinet' }, value => ({ ...value, y: 0 }))
         // ... handle other entities
@@ -91,6 +104,33 @@ export const migrateToV4: Migration<V3Entity, V4Entity> = state => {
 }
 ```
 
+### Renaming an Entity Type
+
+An entity id starts with its entity type, such as `Box-1`, and is typed per entity type (`DomainEntityId<'Box'>`). The runtime validates that an entity's id matches its type, so an entity that keeps its data under a new type name needs a new id, and every relation that points at it must be rewritten to that id. The id is built from a string, which TypeScript cannot check, so this is one place where a cast is needed:
+
+```typescript
+import { parseDomainEntityId } from '@salsita-ai/sdk/domain'
+
+const toTableId = (id: ModelV1.Box['id']) =>
+  // The id is rebuilt for the new type name; nothing narrower than a cast can type a template string as an id
+  `Table-${parseDomainEntityId(id).sequenceNumber}` as ModelV2.Table['id']
+```
+
+### Replacing the Model Entirely
+
+When the new model has nothing in common with the deployed one, there is nothing to convert. This is the case when a project that was first deployed as the starter gets its real model: the starter's `Box` model is version 1 in production, and a deployed version cannot change. Keep the deployed model as `v1`, define the real model in `latest`, and let the migration return the starting state of the new model, the `initialDomainEntities` of its preset:
+
+```typescript
+// src/migrations/v2.ts
+import type { Migration } from '@salsita-ai/sdk/domain'
+
+export const migrateToV2: Migration<ModelV1.AnyDomainEntity, ModelV2.AnyDomainEntity> = () => [
+  // the entities of the new model's preset
+]
+```
+
+No entity of a type that the new version no longer has may stay in the returned state: the migrated state is validated against the latest model, and an unknown entity type fails the load.
+
 ## Migration Runtime
 
 Migrations are executed automatically every time the domain is loaded, both in the client application and in webhooks. During this process:
@@ -114,7 +154,7 @@ When implementing migrations:
 
 4. **Testing**: Thoroughly test migrations with real-world data to ensure they handle all edge cases, use existing configurations from previous versions.
 
-5. **Version Bumping**: Consider bumping the model version for both breaking changes (removing fields, changing types) and additive changes where existing data needs proper defaults. If you add a new required field, existing configurations need a migration to set that field's default value.
+5. **Version Bumping**: Every change to a model that has been deployed needs a new version, whether it is breaking (removing fields, changing types) or additive. If you add a new required field, existing configurations need a migration to set that field's default value; a change that needs no conversion still needs a migration that returns the state unchanged.
 
 ## Admin Model Migrations