@salsita-ai/sdk 0.50.0-develop.a4dde5f252 → 0.50.0-develop.a8cf9ffd01

package/dist/docs/phoenix/data-sources.mdx

@@ -31,7 +31,7 @@ sessionData:
       type: string
     userRole:
       type: string
-      enum: ['admin', 'user', 'guest']
+      enum: ['anonymous', 'user', 'admin']
   required: []
   additionalProperties: false
 ```
@@ -43,18 +43,28 @@ Session data properties must be optional because admin and preset sessions can c
 ```typescript
 // src/webhooks/handlers/auth-handler.ts
 export const authHandler = phx.webhooks.authHandlerBuilder
-  .withCodeHandler(async payload => {
-    const userInfo = await fetchUserInfo(payload.accessToken)
+  .withCodeHandler(async ({ accessToken }, { logger }) => {
+    // USER_API_URL is declared under `env.webhook` in a spec file
+    const response = await fetch(`${phx.webhooksEnv.USER_API_URL}/me`, {
+      headers: { authorization: `Bearer ${accessToken}` },
+    })
+
+    if (!response.ok) {
+      logger.warn(`The user API refused the access token with status ${response.status}.`)
+
+      return { success: false }
+    }
+
+    const userInfo: { readonly id: string; readonly role: 'user' | 'admin' } = await response.json()
 
     return {
       success: true,
       data: {
-        accessToken: payload.accessToken,
+        accessToken,
         userRole: userInfo.role,
       },
       role: userInfo.role,
-      refreshToken: generatedRefreshToken,
-      expirationTime,
+      userId: userInfo.id,
     }
   })
   .build()
@@ -441,7 +451,7 @@ backendData:
 
 The SDK provides comprehensive error handling for backend data:
 
-**Missing Backend Data Schema**: If no `backendData` schema is defined in domain.yaml, backend data fetching is skipped entirely. The context will have `backendData: undefined`.
+**Missing Backend Data Schema**: If no `backendData` schema is declared in a spec file (for example `spec/application.yaml`), backend data fetching is skipped entirely. The context will have `backendData: undefined`.
 
 **Fetch Errors**: If the backend API call fails (network issues, server errors, timeouts), backend data falls back to `undefined`. The error is logged but doesn't break configurator initialization.
 
@@ -449,52 +459,66 @@ The SDK provides comprehensive error handling for backend data:
 
 **API Availability**: Backend data is optional by design. Expressions should always handle the case where `ctx.backendData` is `undefined`.
 
+**Finalization**: The webhook runs the handler again before every configurator finalization, and a failure there fails the finalization; in the browser, a failure only leaves `backendData` `undefined`. Catch what may fail in the handler and return a safe value when one exists.
+
 ### Webhook Implementation
 
-Backend data is fetched using webhook handlers that you implement. This keeps sensitive operations on the server:
+Backend data is fetched using webhook handlers that you implement. This keeps sensitive operations on the server.
+
+The handler reads its credentials as `phx.webhooksEnv.NAME`, never from `process.env`. Declare each variable under `env.webhook` in a spec file; its value is inlined when the webhook is built, from the environment variables a workspace super admin sets in Studio for a deployed build, and from `.env` under `phoenix dev`:
+
+```yaml
+# spec/application.yaml
+env:
+  webhook:
+    PRICING_API_URL:
+      type: url
+      required: true
+    PRICING_API_KEY:
+      type: str
+      required: true
+```
+
+The handler receives `{ deploymentId, frontendUrl, frontendData?, sessionRole, sessionPayload, publishedAdminRevisionPath?, publishedChunkUrls? }` and a context with the `logger`, and returns `{ backendData }`. The SDK exports no type for it: register it inline with `phx.webhooks.webhookBuilder.withFetchBackendData(async (payload, { logger }) => ({ backendData }))`, or type a separate constant from the builder method as below:
 
 ```typescript
 // src/webhooks/handlers/backend-data-handler.ts
-import type { FetchBackendDataHandler } from '@salsita-ai/sdk/webhook'
+type FetchBackendData = Parameters<typeof phx.webhooks.webhookBuilder.withFetchBackendData>[0]
 
-export const backendDataHandler: FetchBackendDataHandler<Phx['SessionData'], Phx['FrontendData']> = async (
-  data,
-  ctx,
-  e
-) => {
-  try {
-    const userRegion = data.frontendData.currency === 'EUR' ? 'EU' : 'US'
+export const backendDataHandler: FetchBackendData = async ({ frontendData }, { logger }) => {
+  const region = frontendData?.currency === 'EUR' ? 'EU' : 'US'
 
-    const pricingApiKey = process.env.PRICING_API_KEY
-    const inventoryApiKey = process.env.INVENTORY_API_KEY
+  const response = await fetch(`${phx.webhooksEnv.PRICING_API_URL}/regions/${region}/prices`, {
+    headers: { authorization: `Bearer ${phx.webhooksEnv.PRICING_API_KEY}` },
+  })
 
-    if (!pricingApiKey) {
-      throw new Error('Missing pricing API configuration')
-    }
+  if (!response.ok) {
+    // There is no safe fallback for prices, so fail: the configurator then has no backend data,
+    // and a finalization fails rather than quoting wrong prices
+    logger.error(`The pricing API answered with status ${response.status}.`)
+    throw new Error('Prices are unavailable')
+  }
 
-    const [exchangeRate, pricing] = await Promise.all([
-      fetchExchangeRate(userRegion, pricingApiKey),
-      fetchPricing(userRegion, inventoryApiKey),
-    ])
+  const prices: { readonly exchangeRate: number; readonly materials: Record<string, number> } = await response.json()
 
-    return {
-      backendData: {
-        exchangeRate,
-        pricing: pricing.materials,
-      },
-    }
-  } catch (error) {
-    ctx.logger.error('Failed to fetch backend data:', error)
-    throw error
+  return {
+    backendData: {
+      exchangeRate: prices.exchangeRate,
+      pricing: prices.materials,
+    },
   }
 }
 ```
 
-**Webhook Integration**:
+**Webhook Integration**: register the handler in the webhook entry, the default export of `src/webhooks/index.ts`:
 
 ```typescript
 // src/webhooks/index.ts
-export const handler = phx.webhooks.webhookBuilder
+import { authHandler } from './handlers/auth-handler.js'
+import { backendDataHandler } from './handlers/backend-data-handler.js'
+import { configuratorFinalizeHandler } from './handlers/configurator-finalize-handler.js'
+
+export default phx.webhooks.webhookBuilder
   .withAuthHook(authHandler)
   .withFetchBackendData(backendDataHandler)
   .withConfiguratorFinalize(configuratorFinalizeHandler)
@@ -633,7 +657,7 @@ export default phx.domain.implementCustomExpressions({
     $userContext: (cabinet, state, ctx) => {
       // Safe access to multiple data sources
       return {
-        userRole: ctx.sessionData.userRole || 'guest',
+        userRole: ctx.sessionData.userRole || 'anonymous',
         theme: ctx.frontendData.theme || 'light',
         hasBackendPricing: ctx.backendData?.pricing !== undefined,
       }

package/dist/docs/phoenix/deployments.mdx

@@ -281,9 +281,7 @@ Phoenix provides two helper functions for reading environment variables with val
 **`createEnvReader`** - General purpose environment reader used in frontend and deployment contexts:
 
 ```typescript
-import { bool, str } from 'envalid'
-
-import { createEnvReader } from '@salsita-ai/sdk/common/env'
+import { bool, createEnvReader, str } from '@salsita-ai/sdk/common/env'
 
 // Create a reader function
 const readEnv = createEnvReader({
@@ -301,9 +299,7 @@ console.log(env.SERVER_URL) // Typed and validated
 
 ```typescript
 // webhooks/webhooks.config.ts
-import { str } from 'envalid'
-
-import { createEnvReader } from '@salsita-ai/sdk/common/env'
+import { createEnvReader, str } from '@salsita-ai/sdk/common/env'
 
 export const readRuntimeConfig = createEnvReader({
   AWS_S3_PUBLIC_RESOURCES_BUCKET: str(),
@@ -333,7 +329,17 @@ export type RuntimeConfig = ReturnType<typeof readRuntimeConfig>
 2. **`.env.generated`** file (created by deployment process)
 3. **`.env`** file (lowest priority)
 
-This means you can override any environment variable by setting it directly in your shell, while still having defaults in `.env` files.
+Set a variable in your shell to override either file tier. In a pnpm workspace, a value in the current package wins over the workspace-root value within the same tier; a workspace generated value still wins over a package `.env` value. Each folder uses `.env.generated` when it exists, otherwise `.phoenix/.env.generated`; the two generated files are never merged.
+
+Only values from `.env` expand references such as `${API_HOST}` against the winning values. Process and generated values stay literal, including when a `.env` value references them. For a literal dollar sign in `.env`, escape it as `\$`:
+
+```dotenv
+API_HOST=https://api.example.com
+API_URL=${API_HOST}/v1
+PASSWORD=cost-\$5
+```
+
+Here `API_URL` becomes `https://api.example.com/v1` and `PASSWORD` becomes `cost-$5`. Generated values need no interpolation escaping. Reading the configuration does not modify `process.env`.
 
 ## Step-by-Step Deployment Guide
 

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

@@ -327,7 +327,9 @@ components:
           $read: $description # This will auto-generate $description expression
 ```
 
-The code generator will automatically create an expression with the same name and infer the return type based on usage context.
+The code generator creates an expression with the same name and infers its type from where it is read. The inferred expression is a custom expression like any declared one: implement it in `src/expressions/`, otherwise the application reports `MISSING_IMPLEMENTATION` when it loads.
+
+The type of an expression must share values with the type every component expects where it is read, and with its declared type. An expression declared as a number and read into a `title`, or one read both into a `title` and into `offsetX`, has no value its implementation could return, so the build reports `EXPRESSION_READ_TYPE_CONFLICT` at the expression and names each place it is read. A type given only as `tsType` is not checked here.
 
 ## Constants
 
@@ -467,11 +469,9 @@ export default phx.domain.implementCustomExpressions({
 })
 ```
 
-> **Removed:** `$codeRef` with an inline `code:` block was previously documented for this purpose.
-> It was never evaluated — the parser carried it through as plain data — so specs using it silently
-> shipped an object where a number was expected. It now reports
-> `ENHANCED_JSON_VALUE_CODE_REF_NOT_SUPPORTED`. Replace `$codeRef: { code: 4 * 25.4 }` with
-> `$eval: '4 * 25.4'`.
+> `$codeRef` with an inline `code:` block is not supported and reports
+> `ENHANCED_JSON_VALUE_CODE_REF_NOT_SUPPORTED`. Write `$eval: '4 * 25.4'` instead of
+> `$codeRef: { code: 4 * 25.4 }`.
 
 ## Aliases
 
@@ -528,19 +528,21 @@ invariants:
   ChairParts: # Applied to all chair parts
     materialRequired:
       type: 'materialMissing'
-      severity: 'error'
+      severity: 'warning'
       message: 'Material must be selected for all chair parts'
 
 components:
   ChairParts: # Applied to all chair parts
-    materialSelector:
+    price:
       main:
-        value:
-          $bind: materialId
+        price:
+          $read: $price
 ```
 
 This approach reduces duplication and ensures consistent behavior across related entities.
 
+The invariant is a `warning` because a chair part without a material is a configuration in progress, not an impossible one: the user can keep configuring, and only finalizing is blocked until every part has a material. A `fatal` severity would reject every change while a part has no material, including the change that adds the part. See [Violation Severity](#violation-severity).
+
 ## Relations
 
 Relations connect your entities into a tree that represents both structure and ownership. This tree drives what appears under what in the scene, how selection and navigation move up and down, and which items get deleted together when you remove a parent. It must be a proper tree (no cycles) and every entity needs to belong to it.
@@ -565,9 +567,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
@@ -641,10 +647,12 @@ invariants:
         - 'aspectRatioInvalid'
 ```
 
-Implementation returns an array of violations. Each violation object requires `type`, `severity`, and `message`. Optionally, you can add `controlViolationPriority` (same as in static YAML) and `formatControlViolationMessage` — a function that receives the current `stateEmission` and an `{ i18n }` context, enabling runtime-computed, translatable messages:
+Implementation returns an array of violations. Each violation object requires `type` and `severity`; `message` is optional and is the text users see for the violation. Optionally, you can add `controlViolationPriority` (same as in static YAML) and `formatControlViolationMessage` — a function that receives the current `stateEmission` and an `{ i18n }` context, enabling runtime-computed, translatable messages:
 
 ```typescript
 // src/invariants/cabinet.ts
+import { msg } from '@lingui/core/macro'
+
 export default phx.domain.implementCustomInvariants({
   Cabinet: {
     materialConstraints: self => {
@@ -712,11 +720,14 @@ For a full working example of priority-based filtering and runtime message forma
 
 ### Violation Severity
 
-Different severities have different behaviors:
+The severity decides what a violation blocks. An invariant takes one of four severities:
+
+- **`fatal`**: the change that causes the violation is never committed. It does not reach the scene, the undo stack or the saved configuration, and controls disable the options that would cause it, with the violation message as the hint.
+- **`fixable`**: rejected the same way as `fatal`. Use it for a situation your project repairs: a [transformer](?path=/docs/other-features-transformers--docs) that reacts to the violation returns the updates that fix it, so the change commits without the violation. Phoenix repairs nothing on its own; without such a transformer, `fixable` behaves exactly like `fatal`.
+- **`warning`**: the change is committed and saved, but the configuration cannot be finalized while the violation lasts. Its message shows on the finalize action.
+- **`notice`**: the change is committed and saved, and nothing is blocked. Its message shows on the finalize action as information.
 
-- **Warning**: Shows a warning but allows the configuration to continue
-- **Error**: Prevents certain actions but doesn't block finalization
-- **Fatal**: Prevents finalizing the configuration
+If the initial state already has a `fatal` or `fixable` violation, the transformers run once on it; when the violation remains, the configurator does not start. See the [Violation Severity example](?path=/docs/other-features-violation-severity--docs) to try each level.
 
 ### Common types
 
@@ -836,7 +847,10 @@ Phoenix automatically:
 During `phoenix dev`, schema-compatible configurator changes can refresh the mounted application in
 place. Changes to the domain model itself are rejected from live application and require a restart;
 this preserves the last valid runtime and loaded configuration until migration and deployment can be
-coordinated atomically.
+coordinated atomically. With server persistence, restart `phoenix dev` itself: it logs an error that
+asks for the restart, and registers the changed model with its development deployment when it starts
+again. Then open the preview address it prints rather than a tab whose address has `?cid=`, which
+loads a configuration saved with the earlier model.
 
 ### The phx Global Namespace
 

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

@@ -66,7 +66,7 @@ The `mode` property indicates the current operational context of the configurato
 
 Projections are SDK-defined expressions that provide reusable functionality across projects. They expose complex calculations and relationships that would otherwise require custom implementation.
 
-The Phoenix SDK includes projection systems for common tasks. Each projection system handles a specific domain like geometry, pricing, or layout. Projects can use these projections without implementing the underlying logic.
+The Phoenix SDK includes projection systems for common tasks. Each projection system handles one domain: positions, sketching, collisions, spatial constraints, snapping and projected entities, the `*Projections` members of the context listed above. Projects can use these projections without implementing the underlying logic.
 
 **Sketching Projections Example**:
 
@@ -82,7 +82,6 @@ export default phx.domain.implementCustomExpressions({
       const sketchingKey = 'floorplan'
       try {
         const shape = ctx.sketchingProjections.getEntityLine(line.id, state, sketchingKey)
-        const connections = ctx.sketchingProjections.getConnections(state, sketchingKey)
         return {
           isTerminal: shape.isTerminal,
           hasStartConnection: shape.start.connection !== null,
@@ -96,34 +95,9 @@ export default phx.domain.implementCustomExpressions({
 })
 ```
 
-This example shows different types of calculations with sketching projections. Connection checking tells you how shapes connect to each other. The traverse method lets you walk through connected shapes. Area calculations use coordinate data to compute geometric properties.
+This example reads how a line connects to the rest of the sketch: `getEntityLine` returns the line's shape with its start and end connections. `getSketching(state, key)` returns all shapes and connections of a sketch, and `getEntityShape` and `getEntityRectangle` return the shape of one entity.
 
-Each projection method handles error cases when entities aren't part of the sketching system. This makes expressions safe to use across different entity types.
-
-**Future Projection Systems (Hypothetical)**:
-
-> **Note**: The following projection systems are hypothetical and not yet implemented. They illustrate how the projection pattern could extend to other domains.
-
-Phoenix can extend projections to other domains. Future projection systems might handle pricing, layout, or other complex calculations:
-
-```typescript
-// HYPOTHETICAL: These projection systems do not exist yet
-export default phx.domain.implementCustomExpressions({
-  Product: {
-    // Pricing projections - calculate complex pricing across projects
-    $finalPrice: (product, state, ctx) => {
-      return ctx.pricingProjections?.calculatePrice(product.id, state)
-    },
-
-    // Layout projections - spatial arrangement calculations
-    $spatialRelations: (product, state, ctx) => {
-      return ctx.layoutProjections?.getNeighbors(product.id, state)
-    },
-  },
-})
-```
-
-These examples show how projections could work in other areas. A pricing projection might calculate discounts, taxes, and complex pricing rules. A layout projection might determine spatial arrangements and object relationships.
+A projection method throws when the entity has no shape of that kind in the sketching, so the expression catches the error and returns a default.
 
 Projections provide tested, optimized solutions for common problems that many configurators need to solve. They let you leverage sophisticated SDK functionality without reimplementing complex logic in each project.
 

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. A project layout (`ConfiguratorLayout`) offers the same actions with its own buttons through `phx.frontend.useFinalizeActions`, which lists them with the primary one picked as the footer picks it, each with its own `run`, pending state, error and disabled state, or through `phx.frontend.useFinalizeAction`, which runs one known action's handler and returns the same state with hints; see the Finalize paragraph of [Configurator Interface → Hooks for a Project Layout](?path=/docs/phoenix-configurator-interface--docs#hooks-for-a-project-layout).
 
 ## How Finalization Works
 
@@ -292,9 +292,10 @@ export const callbackTask = phx.webhooks.callbackBuilder
     // Custom workflows: third-party API calls, external system integration
     try {
       // Example: Submit order to external ERP system
+      // ERP_API_KEY is declared under `env.webhook` in a spec file and inlined when the webhook is built
       await fetch('https://api.external-erp.com/orders', {
         method: 'POST',
-        headers: { Authorization: `Bearer ${process.env.ERP_API_KEY}` },
+        headers: { Authorization: `Bearer ${phx.webhooksEnv.ERP_API_KEY}` },
         body: JSON.stringify({
           customerEmail: data.replayData.emailAddress,
           configurationPdf: baseResult.pdfLink,

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

@@ -22,10 +22,11 @@ The frontend SDK provides the core libraries and components for building configu
 
 The Phoenix CLI (`phoenix` command) is the unified tool for all configurator development. It combines domain code generation, webhook building, deployment management, and development workflows into a single interface:
 
-- `phoenix init` - Start a new project with a working starter spec
+- `phoenix init` - Start a new project: a working starter spec and a `package.json` with the SDK, the packages it requires next to it, ESLint and Prettier
 - `phoenix dev` - Start the development server with hot reload
 - `phoenix build` - Build the configurator for production
-- `phoenix sync` - Synchronize dependencies and generated code
+- `phoenix sync` - Regenerate the generated code and project files
+- `phoenix deps` - Add the SDK's missing peer dependencies to `package.json` and move out-of-range ones into range
 - `phoenix check` - Validate domain configuration and code
 - `phoenix fix` - Auto-fix common issues in domain files
 
@@ -57,12 +58,14 @@ This section provides practical guidance for developers who are new to Phoenix P
 
 Before diving into Phoenix Platform development, ensure you have:
 
-- **Node.js** and **pnpm** - Required versions are set automatically in the project
+- **Node.js 22.13 or newer** and **a package manager** - The SDK and the Phoenix CLI run on Node.js 22.13 or newer (see [Starting a New Project](?path=/docs/phoenix-phoenix-cli--docs#starting-a-new-project)). A project installs with any package manager; with pnpm 11 it needs the settings in [Package manager](?path=/docs/phoenix-project-structure--docs#package-manager)
 - **JavaScript/TypeScript** - Phoenix generates TypeScript code and uses modern JavaScript patterns
 - **React** - The platform builds on React components, hooks, and modern React patterns
 - **Three.js** - Basic knowledge of 3D graphics, scenes, cameras, and rendering concepts
 - **React Three Fiber** - Understanding of declarative 3D development and R3F component patterns
 
+The commands in this documentation use pnpm, as in `pnpm phoenix sync`. They work the same through any other package manager: `npx phoenix sync` with npm, `yarn phoenix sync` with Yarn, `bunx phoenix sync` with Bun.
+
 We assume you have working knowledge of these technologies before starting with Phoenix Platform. If you're new to any of these areas, we recommend familiarizing yourself with them first, as Phoenix Platform builds directly on these foundations.
 
 ### Your First Steps
@@ -86,8 +89,6 @@ 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 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.
 
 **Repository Search Strategy**:

package/dist/docs/phoenix/integration/authentication-internal.mdx

@@ -109,7 +109,7 @@ export const authHandler = phx.webhooks.authHandlerBuilder
       }
     } catch (error) {
       ctx.logger.error('Error verifying access token', {}, error)
-      return { success: false, error: 'Invalid access token' }
+      return { success: false }
     }
   })
   .withRefreshHandler(async (payload, ctx) => {
@@ -126,7 +126,7 @@ export const authHandler = phx.webhooks.authHandlerBuilder
       }
     } catch (error) {
       ctx.logger.error('Error verifying refresh token', {}, error)
-      return { success: false, error: 'Invalid refresh token' }
+      return { success: false }
     }
   })
   .build()

package/dist/docs/phoenix/integration/finalization-internal.mdx

@@ -116,7 +116,7 @@ export const configuratorFinalizeHandler = phx.webhooks.finalizeHandlerBuilder.w
         frontendUrl,
         configurationId,
         revisionId,
-        expiration: 30 * 24 * 60 * 60,
+        expiration: 30 * 24, // in hours: 30 days
         access: 'rr',
       },
       {