@salsita-ai/sdk 0.50.0-develop.bc4bdb2ffc → 0.50.0-develop.bd84173265

package/dist/application-spec/generate-application/code/templates/package-json.js

@@ -1 +1 @@
-let e=["@salsita-ai/platform-project-sdk","@salsita-ai/platform-common","@salsita-ai/platform-contracts","@salsita-ai/common","@salsita-ai/contracts"],t=(e,t)=>e>t?1:e<t?-1:0,r={private:!0,type:"module",packageManager:"pnpm@11.1.3",engines:{node:"24.14.1",pnpm:"11.1.3"}},i={"babel-plugin-macros":"3.1.0",vite:"6.4.3","@vitejs/plugin-react":"5.2.0","@swc/cli":"0.8.1","@swc/core":"1.15.40",typescript:"npm:@typescript/typescript6@6.0.2","@lingui/cli":"5.9.5","@types/lodash-es":"4.17.12","@lingui/macro":"5.9.5","@lingui/swc-plugin":"5.11.0","@types/node":"24.12.2","@types/react":"18.3.8","@types/react-dom":"18.3.0","@types/three":"0.160.0","@typescript/native":"npm:typescript@7.0.2",envalid:"8.1.1",eslint:"9.39.4",prettier:"3.8.3",vitest:"4.1.11"},n={build:"phoenix build",clean:"phoenix clean",dev:"phoenix dev","dev:local":"phoenix dev --persistence local-storage",sync:"phoenix sync",check:"phoenix check",fix:"phoenix fix","verify:fix":"phoenix build && phoenix fix && phoenix check --types",test:"vitest --passWithNoTests run","test:watch":"vitest","prepare:ci":"phoenix prepare:ci","deployment:prepare-local":"phoenix deployment:prepare-local"},s=["environment:create","environment:list","deployment:register","deployment:register:skip","lint:check","prettify:check","ts:check","lint:fix","prettify:fix"],c=e=>"object"==typeof e&&null!==e&&!Array.isArray(e),o=e=>{if(!c(e))return;let t=[];for(let[r,i]of Object.entries(e)){if("string"!=typeof i)return;t.push([r,i])}return Object.fromEntries(t)},a=e=>e.replace(/^[\^~]/,""),p=(r,i)=>{let n={};for(let[e,t]of Object.entries(r))n[e]=a(t);if(i)for(let[e,t]of Object.entries(i))e in n||(n[e]=a(t));return Object.fromEntries(Object.entries(n).filter(([t])=>!e.includes(t)).sort(([e],[r])=>t(e,r)))};export const generateApplicationSpecPackageJson=e=>{let{sdkVersion:a,useWorkspace:l,useClerk:f=!1,name:m,description:d,existingContent:u}=e,y=(e=>{if(!e)return{};try{let t=JSON.parse(e);if(c(t))return t}catch{}return{}})(u),h=p({...f?{"@clerk/clerk-react":"5.61.8"}:{},"camera-controls":"2.4.2","lodash-es":"4.18.1",react:"18.3.1","react-dom":"18.3.1","@emotion/react":"11.11.3","@emotion/styled":"11.11.0","@mui/material":"5.15.5","@mui/system":"5.16.7","@lingui/core":"5.9.5","@lingui/react":"5.9.5",three:"0.160.1","@react-three/fiber":"8.15.16","@react-three/drei":"9.97.6","@react-three/postprocessing":"2.16.3",motion:"12.34.0","@tanstack/react-query":"5.100.14",rxjs:"7.8.2",uuid:"14.0.0","ts-pattern":"5.9.0","@salsita-ai/sdk":l?"workspace:^":a,zod:"3.25.76"},o(y.dependencies)),g=p(i,o(y.devDependencies)),x=((e,r)=>{let i={};for(let[t,r]of Object.entries(e))i[t]=r;if(r)for(let[e,t]of Object.entries(r))e in i||(i[e]=t);return Object.fromEntries(Object.entries(i).filter(([e])=>!s.includes(e)).sort(([e],[r])=>t(e,r)))})({...n,...l?{dev:"phoenix dev --local"}:{}},o(y.scripts)),v=y.name,b=m?m.toLowerCase().replace(/[^a-z0-9-]/g,"-"):"string"==typeof v?v:"project-name",j={...y,name:b,...r,scripts:x,dependencies:h,devDependencies:g};return void 0!==d&&(j.description=d),JSON.stringify(j,null,2)+"\n"};
+let e=["@salsita-ai/platform-project-sdk","@salsita-ai/platform-common","@salsita-ai/platform-contracts","@salsita-ai/common","@salsita-ai/contracts"],t={private:!0,type:"module",packageManager:"pnpm@11.1.3",engines:{node:"24.14.1",pnpm:"11.1.3"}},r={"babel-plugin-macros":"3.1.0",vite:"6.4.3","@vitejs/plugin-react":"5.2.0","@swc/cli":"0.8.1","@swc/core":"1.15.40",typescript:"npm:@typescript/typescript6@6.0.2","@lingui/cli":"5.9.5","@types/lodash-es":"4.17.12","@lingui/macro":"5.9.5","@lingui/swc-plugin":"5.11.0","@types/node":"24.12.2","@types/react":"18.3.8","@types/react-dom":"18.3.0","@types/three":"0.160.0","@typescript/native":"npm:typescript@7.0.2",envalid:"8.1.1",eslint:"9.39.4",prettier:"3.8.3",vitest:"4.1.11"},i=e=>"object"==typeof e&&null!==e&&!Array.isArray(e),s=e=>{if(!i(e))return;let t=[];for(let[r,i]of Object.entries(e)){if("string"!=typeof i)return;t.push([r,i])}return Object.fromEntries(t)},a=e=>e.replace(/^[\^~]/,""),n=(t,r)=>{let i={};for(let[e,r]of Object.entries(t))i[e]=a(r);if(r)for(let[e,t]of Object.entries(r))e in i||(i[e]=a(t));return Object.fromEntries(Object.entries(i).filter(([t])=>!e.includes(t)).sort(([e],[t])=>e>t?1:e<t?-1:0))};export const generateApplicationSpecPackageJson=e=>{let{sdkVersion:a,useWorkspace:c,useClerk:o=!1,name:p,description:l,existingContent:m}=e,u=(e=>{if(!e)return{};try{let t=JSON.parse(e);if(i(t))return t}catch{}return{}})(m),f=n({...o?{"@clerk/clerk-react":"5.61.8"}:{},"camera-controls":"2.4.2","lodash-es":"4.18.1",react:"18.3.1","react-dom":"18.3.1","@emotion/react":"11.11.3","@emotion/styled":"11.11.0","@mui/material":"5.15.5","@mui/system":"5.16.7","@lingui/core":"5.9.5","@lingui/react":"5.9.5",three:"0.160.1","@react-three/fiber":"8.15.16","@react-three/drei":"9.97.6","@react-three/postprocessing":"2.16.3",postprocessing:"6.36.3",motion:"12.34.0","@tanstack/react-query":"5.100.14",rxjs:"7.8.2",uuid:"14.0.0","ts-pattern":"5.9.0","@salsita-ai/sdk":c?"workspace:^":a,zod:"3.25.76"},s(u.dependencies)),d=n(r,s(u.devDependencies)),y=u.name,g=p?p.toLowerCase().replace(/[^a-z0-9-]/g,"-"):"string"==typeof y?y:"project-name",j={...u,name:g,...t,dependencies:f,devDependencies:d};return void 0!==l&&(j.description=l),JSON.stringify(j,null,2)+"\n"};

package/dist/application-spec/generate-application/code/templates/prettier-config.d.ts

@@ -1 +1,6 @@
+/**
+ * The project's `prettier.config.js`, written once when the project has none. It re-exports the SDK's
+ * shared Prettier configuration so editors find it in the project root; the project may change it
+ * afterwards. `phoenix check` and `phoenix fix` use the SDK's configuration when the file is missing.
+ */
 export declare const generateApplicationSpecPrettierConfig: () => string;

package/dist/application-spec/generate-application/code/templates/prettier-config.js

@@ -1,8 +1,7 @@
-let e=`/**
- * Auto-generated file.
- * Do not modify this file manually.
- * Version: 1
- */`;export const generateApplicationSpecPrettierConfig=()=>`${e}
+export const generateApplicationSpecPrettierConfig=()=>`/**
+ * The project's Prettier configuration. It re-exports the shared configuration of the Phoenix SDK;
+ * change it to adjust the formatting of this project.
+ */
 import { prettierrc } from '@salsita-ai/sdk/common/prettier'
 
 export default prettierrc

package/dist/application-spec/generate-application/code/templates/root-tsconfig.d.ts

@@ -0,0 +1,6 @@
+/**
+ * The project's root `tsconfig.json`, written once when the project has none: it extends the
+ * generated settings in `.phoenix/tsconfig.json`, so editors and tools that look for a
+ * `tsconfig.json` in the project root find them. It is the project's afterwards, to add to.
+ */
+export declare const generateApplicationSpecRootTsconfig: () => string;

package/dist/application-spec/generate-application/code/templates/root-tsconfig.js

@@ -0,0 +1,2 @@
+export const generateApplicationSpecRootTsconfig=()=>`{ "extends": "./.phoenix/tsconfig.json" }
+`;

package/dist/application-spec/generate-application/code/templates/skills/phoenix-cli-skill.js

@@ -1 +1 @@
-import{renderAgentSkill as e}from"./agent-skill.js";import{sdkGuidanceSections as n}from"./sdk-content.js";export const generatePhoenixCliSkill=()=>e({name:"phoenix-cli",description:"Phoenix CLI tooling for building and inspecting this configurator, covering build, dev and sync commands, dev logs, glTF asset inspection, screenshots, runtime state, data and scene inspection, variant previews, and Playwright MCP setup. Use when building, debugging build or runtime errors, checking 3D assets, or inspecting the running configurator.",sections:[n.buildCommands,n.devLogs,n.assetInspection,n.screenshotCli,n.inspectState,n.inspectData,n.inspectScene,n.variantPreviews,n.playwrightMcpSetup]});
+import{renderAgentSkill as e}from"./agent-skill.js";import{sdkGuidanceSections as n}from"./sdk-content.js";export const generatePhoenixCliSkill=()=>e({name:"phoenix-cli",description:"Phoenix CLI tooling for building and inspecting this configurator, covering build, dev, sync and deps commands, dev logs, glTF asset inspection, screenshots, runtime state, data and scene inspection, variant previews, and Playwright MCP setup. Use when building, debugging build or runtime errors, checking 3D assets, or inspecting the running configurator.",sections:[n.buildCommands,n.devLogs,n.assetInspection,n.screenshotCli,n.inspectState,n.inspectData,n.inspectScene,n.variantPreviews,n.playwrightMcpSetup]});

package/dist/application-spec/generate-application/code/templates/skills/phoenix-create-configurator-skill.js

@@ -1,36 +1,6 @@
 import{renderAgentSkill as e}from"./agent-skill.js";import{sdkGuidanceSections as t}from"./sdk-content.js";let n=`Guide the client through five stages: a representative first slice, the overall configuration flow, iterative options and features, finalization, and a complete review. Make the client comfortable, informed, and in control while taking responsibility for platform research, implementation, and verification.
 
-“Client” means the person creating the configurator. “Configurator user” means its intended user, such as a buyer, salesperson, or designer. Tailor the experience to that audience; do not assume a purchasing journey.`,i=`## Foundations
-
-### Communicate the journey and expectations
-
-Explain all five stages at the start in plain language. Before each stage or increment, say what you will work on, what the client will be able to try, what remains for later, and when you will return for feedback. During longer work, give meaningful progress updates, including what is already usable.
-
-Read supplied information before asking questions. Treat an interview request as permission to gather necessary information throughout the work, not a requirement to ask about every decision before building. Use source-backed facts directly. Choose reversible design defaults yourself, state them briefly, and proceed; do not ask permission to use an illustrated starting configuration, follow supplied branding, or choose a standard Phoenix control.
-
-Before asking, decide whether the answer would materially change the work due now and whether a useful slice can proceed without it. Ask only for a blocking ambiguity, a consequential business decision needed now, or a material departure from the accepted design. Otherwise record the open issue for the relevant stage. When a question is necessary, explain its consequence and recommend an answer; keep it focused. A client's agreement should lead to the promised work, not another routine approval question. Teach relevant Phoenix approaches through the client's product, without asking them to choose SDK components or operate developer tools.
-
-At each preview, explain what changed, give a focused action to try, and recommend the next step conditional on feedback. End the turn and wait before expanding the agreed increment unless the client requested a larger autonomous batch. Let them redirect, revisit decisions, or pause; overall scope approval does not remove these feedback points.
-
-### Study Phoenix and use its intended patterns
-
-Before generating the first slice, study the complete Phoenix documentation available for the project's installed version, including UX guidance and documented examples. Discover the full inventory with \`pnpm phoenix docs -l\` and read each document with \`pnpm phoenix docs -r <returned-path>\`; use \`pnpm phoenix docs -s '<topic>'\` to locate material again. In hosted environments, use the available documentation list/search/read tools instead. An index or search result alone is not a completed study. Track coverage in the specification so you can resume without rereading unchanged material.
-
-Use Phoenix's existing components, features, and supported workflows whenever they provide the required capability. Guide the client toward those approaches and explain their benefits. Use custom implementations only when the required capability is unavailable: verify the gap in the documentation, explain it and the proposed approach to the client, and keep the solution compatible with Phoenix's architecture. Missing documentation is not proof that a feature is unavailable.
-
-Revisit the relevant implementation examples as you build. [Phoenix UX guidance](references/phoenix-ux.md) provides navigation back to common topics; platform usage belongs in Phoenix docs rather than a parallel manual in this skill. Disclose inaccessible documentation and the resulting uncertainty instead of claiming full coverage or inventing APIs. Do not assume access to Phoenix's source repository or internal processes.
-
-### Maintain a living Markdown specification
-
-After inspecting the materials, create \`configurator-spec.md\` in the intended project, or update its existing equivalent. Keep it outside public/user-facing assets and use it as the single record of:
-
-- Product scope, intended users, source materials, assets, and confirmed product facts.
-- Configurable options, dependencies, compatibility rules, dimensions, and commercial rules.
-- Unknowns, conflicting information, proposals, agent-chosen design defaults, and explicitly agreed provisional business assumptions, distinguished from confirmed facts and client-approved decisions.
-- Accepted visual direction, navigation, interaction patterns, and finalization decisions, with their rationale.
-- The five-stage plan, current stage, implemented and remaining scope, documentation coverage, verification results, and next increment.
-
-Update it whenever new information, a decision, or completed work changes the plan. Keep it concise and current, not a conversation transcript. Read it when resuming, inspect the existing draft, and briefly remind the client where things stand. Preserve accepted behavior and styling; explain and agree on material departures before applying them. The specification supports collaboration without making every edit an approval step.`,a=`## 1. Gather inputs and present a representative first slice
+“Client” means the person creating the configurator. “Configurator user” means its intended user, such as a buyer, salesperson, or designer. Tailor the experience to that audience; do not assume a purchasing journey.`,i=`## 1. Gather inputs and present a representative first slice
 
 If no materials are supplied, explain the journey briefly and ask only for existing product documents, prices, pictures, drawings, models, or a plain-language description. Accept incomplete material; do not combine this opening with a setup questionnaire. If materials are already supplied, inspect them first.
 
@@ -38,19 +8,19 @@ Use [Product discovery](references/product-discovery.md) to extract facts and id
 
 Inspect the working environment internally: intended project, existing work, attachment access, editing, preview, and verification capabilities. Clarify ambiguous project identity before mutation. If a required capability is missing, do useful analysis, name the blocker, and distinguish a proposal from an implemented result.
 
-Complete the documentation study and start the specification before implementation. Explain the first slice and the likely milestones that follow. Build a limited but representative configuration with a meaningful visible interaction. Establish visual quality immediately: theme the UI for the product and brand, and give the 3D scene appropriate materials, lighting, background, and camera framing using Phoenix's supported features. The product must look right, not merely be present; apply Visual inspection before presenting the slice. Limited scope should not mean an arbitrary or visually neglected demo.
+Complete the core documentation study and start the specification before implementation. Explain the first slice and the likely milestones that follow. Build a limited but representative configuration with a meaningful visible interaction. Establish visual quality immediately: theme the UI for the product and brand, and give the 3D scene appropriate materials, lighting, background, and camera framing using Phoenix's supported features. The product must look right, not merely be present; apply Visual inspection before presenting the slice. Limited scope should not mean an arbitrary or visually neglected demo.
 
 Use confirmed information and supplied assets. Keep a known arrangement when layout limits are unknown; settle only questions that block this slice. Defer quote fields, delivery areas, tax handling, and other finalization details unless they prevent this preview from being useful. An unresolved price component can remain out of the slice rather than prompting an early commercial interview. When supplied models need conversion or repair before use, follow [Asset conversion](references/asset-conversion.md). Missing assets may require an agreed temporary proxy or a non-3D draft, clearly described as such, rather than invented production geometry.
 
 Once the materials establish a usable scope, the next handoff should normally be the first preview. Announce reversible choices together and build: “I'll use the illustrated sideboard and the brief's styling, with body and door finish controls. We'll review the appearance in the preview; delivery details can wait until finalization.” Invite correction without ending the turn to seek approval of these defaults.
 
-Start the preview as soon as it is useful, share its address once reachable, and keep it available through subsequent work where the environment permits. Present what the client can try and seek feedback on product representation and visual direction before moving on.`,o=`## 2. Plan the complete configuration experience
+Start the preview as soon as it is useful, share its address once reachable, and keep it available through subsequent work where the environment permits. Present what the client can try and seek feedback on product representation and visual direction before moving on.`,a=`## 2. Plan the complete configuration experience
 
 Identify all the main things users need to configure across the intended scope, including dependencies and unresolved areas. Group and order decisions by what users understand and choose first, and by actual product dependencies. Cover the whole experience in the plan without requiring every detailed business rule to be settled now.
 
 Use the Phoenix UX guidelines to choose the interaction model. Consider in-scene controls for actions tied to a visible part or location; use the sidebar for simpler or global options, selected-part details, and keeping track of the configuration. When there are more than a few choices, choose meaningful groups or navigation; an ordered flow should reflect a useful decision sequence, not merely the agent's interview stages. Do not force selection or assembly controls onto a simple fixed product.
 
-Record the proposed flow and its platform patterns in the specification. Demonstrate its structure through a representative working path in the preview rather than implementing every option or showing nonfunctional controls. Explain the complete proposed experience in product language, its key tradeoffs, and the implementation order. Get the client's feedback and agreement before expanding individual features.`,r=`## 3. Iteratively add options and features
+Record the proposed flow and its platform patterns in the specification. Demonstrate its structure through a representative working path in the preview rather than implementing every option or showing nonfunctional controls. Explain the complete proposed experience in product language, its key tradeoffs, and the implementation order. Get the client's feedback and agreement before expanding individual features.`,o=`## 3. Iteratively add options and features
 
 Implement the experience plan in small, useful increments. Establish the core interactions before multiplying secondary options; revisit priorities when new facts affect feasibility or cause substantial rework. Keep all agreed scope visible in the specification until implemented or explicitly deferred by the client.
 
@@ -60,13 +30,14 @@ For each increment:
 2. Revisit the applicable Phoenix examples and implement the chosen increment within the accepted design.
 3. Exercise the new interaction and affected existing behavior in the running preview, alongside the project's relevant automated checks. Check that controls apply to existing targets, selection changes update the editing context, and global versus per-part changes behave as intended.
 4. Apply Visual inspection to the configuration that best represents the product, not only to the part you changed.
-5. Update the specification and present the preview for feedback, including any verification gaps and the recommended next increment.
+5. Run [Appearance review](references/appearance-review.md) when the increment added, removed, or swapped a part, and before any hand-over.
+6. Update the specification and present the preview for feedback, including any verification gaps and the recommended next increment.
 
 Keep the domain rules, scene, selected options, dimensions, and pricing consistent as features become available. Preserve existing selections and accepted UI behavior; adding an option is not permission to redesign the experience. When an agreed rule changes, update the affected model, interface, pricing, and checks together.`,s=`## 4. Implement finalization
 
 Establish what completing the configuration means: saving, sharing, requesting a quote, ordering, or another agreed outcome. Determine the information collected, what is submitted and where, what the user receives, and how progress, success, failure, and recovery are communicated. Discover requirements earlier if they affect preceding design decisions, while keeping finalization implementation in this stage.
 
-Use Phoenix's supported finalization mechanisms and implement the agreed journey. Test payloads and outcomes without sending real messages or creating real orders unless explicitly authorized. Keep unfinished rules or commercial assumptions identifiable and prevent them from producing a misleading real quote or order.`,c=`## 5. Review the complete configurator and hand over
+Use Phoenix's supported finalization mechanisms and implement the agreed journey. Test payloads and outcomes without sending real messages or creating real orders unless explicitly authorized. Keep unfinished rules or commercial assumptions identifiable and prevent them from producing a misleading real quote or order.`,r=`## 5. Review the complete configurator and hand over
 
 Walk through the whole journey as the intended user: start, explore and change options, recover from mistakes, and finalize. Review product representation, visual quality, flow, discoverability, contextual controls, accessibility, and desktop/mobile behavior against the specification and client feedback.
 
@@ -74,9 +45,9 @@ Check representative valid and invalid combinations, boundaries, dependent chang
 
 Fix gaps and regressions, update the specification, and present the complete experience for the client's final review. State what is implemented, what remains provisional or unverified, and whether it is a working draft or ready for its intended users. Publishing and connecting live systems remain separate actions governed by the client's authorization and the environment's rules; obtain any required approval against the concrete result.
 
-Once the client says they are done, or the configurator is live and they confirm the work is finished, follow the \`phoenix-feedback\` skill to interview them for an evaluation of the run. Ask for it once, and send it only with their approval.`,l=`## Verification evidence
+Once the client says they are done, or the configurator is live and they confirm the work is finished, follow the \`phoenix-feedback\` skill to interview them for an evaluation of the run. Ask for it once, and send it only with their approval.`,d=`## Verification evidence
 
-Use the project's documented verification commands and available tools throughout. Distinguish automated checks, your actual preview observations, and client feedback. A successful build does not prove preview access or interaction quality, and neither automated checks nor interaction checks cover rendered appearance: Visual inspection is the only evidence for it. Missing browser automation need not prevent the client from using a preview: offer a focused check and record their result as client feedback. Disclose anything you cannot test; a generic “OK” is not evidence that an untested interaction works.`,d=`# Asset conversion
+Use the project's documented verification commands and available tools throughout. Distinguish automated checks, your actual preview observations, and client feedback. A successful build does not prove preview access or interaction quality, and neither automated checks nor interaction checks cover rendered appearance: Visual inspection is the only evidence for it. Missing browser automation need not prevent the client from using a preview: offer a focused check and record their result as client feedback. Disclose anything you cannot test; a generic “OK” is not evidence that an untested interaction works.`,c=`# Asset conversion
 
 Supplied models usually need work before they can be configured. Conversion is part of the product's appearance, not a preliminary chore: a converted model that is misplaced, incomplete, or stripped of its detail becomes a visible defect that the client sees before anything else.
 
@@ -103,9 +74,61 @@ Keep full detail on parts that are small, curved, and always visible, such as ca
 
 ## Verify every model, not the first one
 
-Inspect each converted model with the project's asset inspection tooling, and check the clauses above for every model in the set. A batch that reuses a script verified on one file still needs each result looked at: source files in one delivery frequently differ in origin, scale, and structure.`,h=`# Phoenix UX guidance
+Inspect each converted model with the project's asset inspection tooling, and check the clauses above for every model in the set. A batch that reuses a script verified on one file still needs each result looked at: source files in one delivery frequently differ in origin, scale, and structure.`,l=`# Appearance review
+
+An independent reviewer opens the running configurator, tries to find everything wrong with how it looks, and hands what it finds back to you to challenge and fix. This exists because an implementer judges its own rendered output badly: it inspects the state it is already in, and it reads its own intent into what it sees. Visual inspection covers what follows from the change you just made; this covers what you failed to notice.
+
+## Roles
+
+The reviewer is a fresh context with no memory of the implementation. It drives the preview itself and takes its own screenshots. It never works from screenshots you captured, because choosing what to look at is most of the judgement. It does not fix anything.
+
+You prepare the packet, challenge every candidate it returns, fix the ones that survive, and report. A candidate you reject is recorded with the reason, never silently dropped.
+
+## When it runs
+
+Before the first slice is presented, before hand-over, and after any increment that adds, removes, or swaps a part. Composition between parts is where appearance defects concentrate, and it is the one thing an inspection of a single state cannot see.
+
+## The packet
+
+Give the reviewer this, and not the conversation:
+
+1. How to start the preview and reach it.
+2. The client's own photographs, renders, drawings, and published dimensions.
+3. The control inventory from the specification: every property, its options, and which of those options add, remove, or swap a part.
+4. The states to cover: the default, one state for every option that changes which parts are present, and the extremes of any dimension or quantity.
+5. Whatever the specification records as deferred, provisional, or unknown.
+
+Item 4 is the point of the exercise. When the starting configuration has a part absent, the default view can never show that part, and no amount of looking at the default will reveal how it is composed.
+
+## What counts as a defect
+
+A defect is anchored to a named state and a screenshot the reviewer took, and cites one of:
+
+1. a divergence from the client's own material or published dimensions;
+2. a violation of a requirement the specification states; or
+3. a self-evident flaw: something floating, intersecting, clipped, overlapping, missing, mis-scaled, or unreadable.
+
+Everything else is a taste note. Collect taste notes in a separate list, each phrased as what you would change and why, and do not act on them: they are the client's call, and an implementation that chases them never finishes. Preference presented as defect is what makes an adversarial pass worthless, and it fails in both directions — a reviewer that cannot separate the two either floods you or stays silent.
+
+Do not re-report what the specification already records as deferred. Do say when a deferred item is worse than its record suggests.
+
+## Challenging what comes back
+
+For each defect, write the strongest case against it before you accept it. Is it visible in the screenshot cited? Is it caused by this build rather than by a limit of the supplied asset? Is it already recorded as deferred? Is the proposed correction the smallest one that resolves it? Record confirmed, refuted, or unresolved, with the evidence. An unresolved candidate is not a defect: if it would be serious, raise it as an open question instead of fixing speculatively.
+
+Merge candidates that describe the same underlying failure. The same defect described in different words is not a second defect.
+
+## Budget
+
+One reviewer pass, one challenge pass, and one re-inspection of the fixed defects in the states where they were found. Nothing wider unless the client asks for it. A correction that changes the agreed design is a decision for the client, not another round of review.
+
+## When the tools are not there
+
+With no way to run an independent reviewer, work through the same checks yourself as a separate pass against the packet alone, and record in the report that the review was not independent.
+
+With no browser automation, \`phoenix screenshot\` captures the canvas but not the interface around it, and \`phoenix inspect:state\` and \`phoenix inspect:scene\` only read, so no state other than the default can be reached. Review what you can reach and say which of the above went unchecked, rather than reporting a clean result.`,h=`# Phoenix UX guidance
 
-Use this lookup to revisit guidance after the complete documentation study required by the skill. Discover actual document paths through Phoenix docs; titles and search terms below are not paths. Read the relevant guideline and linked implementation example for the project's installed version before applying it.
+Use this lookup to revisit guidance after the core documentation study required by the skill. Discover actual document paths through Phoenix docs; titles and search terms below are not paths. Read the relevant guideline and linked implementation example for the project's installed version before applying it.
 
 | Decision                                  | Documentation to find                                     |
 | ----------------------------------------- | --------------------------------------------------------- |
@@ -116,7 +139,8 @@ Use this lookup to revisit guidance after the complete documentation study requi
 | Editing, selection, and review modes      | Interaction Modes                                         |
 | Swatches, cards, and other controls       | Choosing a Control                                        |
 | Product visibility and selection          | Canvas and Feedback, Canvas Selection, Selection Hotspots |
-| Add/remove actions with visual choices    | FABs, childEntityRecipes, thumbnailUrl                    |
+| Adding or removing where position matters | FABs (scene add/delete), Choosing a Control               |
+| Adding from a catalogue, position aside   | childEntityRecipes, thumbnailUrl, Choosing a Control      |
 | Contextual controls and dependent options | Component Filters, FilteredControls                       |
 | Keep the edited part in view              | Camera Fit Selection, Camera Transitions                  |
 | Submission and completion                 | Finalization                                              |
@@ -139,4 +163,4 @@ Keep facts traceable to sources. Geometry proves shape, not commercial availabil
 Extract available facts now; unresolved entries are not a queue of questions to ask next. Follow the skill's question threshold and defer unknowns that do not block the current work. Use reversible experience defaults without inventing business facts. When a business rule is needed now, explain the consequence and ask for the fact or an explicitly agreed provisional assumption. Continue independent work within the agreed increment; elapsed time is not agreement. For example, resolve whether a shelf is included or charged separately when implementing its pricing, not before a finish-only preview.
 
 Translate confirmed rules into representative allowed/disallowed combinations, boundary checks, and hand-calculated totals as their features are implemented.
-`;export const generatePhoenixCreateConfiguratorSkill=()=>e({name:"phoenix-create-configurator",description:"Guide a client from product documents and assets to a reviewed Phoenix configurator through a representative first slice, an overall experience plan, iterative implementation, and finalization. Use when creating a configurator, and for every later change that adds or reworks products, options, features or finalization, however small the increment; not for an isolated code fix.",sections:[n,i,a,o,r,s,c,t.visualInspection,l]});export const generatePhoenixCreateConfiguratorSkillReferences=()=>[{path:"references/phoenix-ux.md",content:h},{path:"references/product-discovery.md",content:p},{path:"references/asset-conversion.md",content:d}];
+`;export const generatePhoenixCreateConfiguratorSkill=()=>e({name:"phoenix-create-configurator",description:"Guide a client from product documents and assets to a reviewed Phoenix configurator through a representative first slice, an overall experience plan, iterative implementation, and finalization. Use when creating a configurator, and for every later change that adds or reworks products, options, features or finalization, however small the increment; not for an isolated code fix.",sections:[n,"## Foundations\n\n### Communicate the journey and expectations\n\nExplain all five stages at the start in plain language. Before each stage or increment, say what you will work on, what the client will be able to try, what remains for later, and when you will return for feedback. During longer work, give meaningful progress updates, including what is already usable.\n\nRead supplied information before asking questions. Treat an interview request as permission to gather necessary information throughout the work, not a requirement to ask about every decision before building. Use source-backed facts directly. Choose reversible design defaults yourself, state them briefly, and proceed; do not ask permission to use an illustrated starting configuration, follow supplied branding, or choose a standard Phoenix control.\n\nBefore asking, decide whether the answer would materially change the work due now and whether a useful slice can proceed without it. Ask only for a blocking ambiguity, a consequential business decision needed now, or a material departure from the accepted design. Otherwise record the open issue for the relevant stage. When a question is necessary, explain its consequence and recommend an answer; keep it focused. A client's agreement should lead to the promised work, not another routine approval question. Teach relevant Phoenix approaches through the client's product, without asking them to choose SDK components or operate developer tools.\n\nAt each preview, explain what changed, give a focused action to try, and recommend the next step conditional on feedback. End the turn and wait before expanding the agreed increment unless the client requested a larger autonomous batch. Let them redirect, revisit decisions, or pause; overall scope approval does not remove these feedback points.\n\n### Study Phoenix and use its intended patterns\n\nStudy the documentation in two parts: a core before the first slice, and the rest keyed to what you are about to build. Take the inventory first with `pnpm phoenix docs -l`, which prints every path and title; browse one area with `pnpm phoenix docs -c '<category>'`, read a document with `pnpm phoenix docs -r <returned-path>`, and locate material again with `pnpm phoenix docs -s '<topic>'`. In hosted environments, use the available documentation list/search/read tools instead.\n\nRead the core in full before the first slice: the documents listed as Key Docs in the `phoenix` skill's SDK Documentation section, which carry getting started, the domain model, components, project structure, state, expressions, webhooks, finalization, and migrations, together with the `UX Guidelines` category. That list is maintained there; do not keep a second copy of it here.\n\nRead the rest when an increment reaches it, and before implementing that increment: the remaining `Phoenix` documents for what the increment touches, such as theming and localization when you brand or translate the interface, sharing and sessions when its users receive links, and deployments before going live; `Layouts` and `Controls` for the interface; `3d scene` for the scene; `Relations`, `Recipes & Delete`, `Fabs`, `Drag & Drop`, and `Selection & Highlight` for a product assembled from parts; `Other features` and `Integrations` for finalization and external data; `Performance` before hand-over; and `Complex Use Cases` and `Demos` as worked examples. Take the names from the inventory you listed; this version may group its documentation differently. Judge a category you are deferring by what its documents say they are for, which `pnpm phoenix docs -c '<category>'` prints, not by its name or by how many documents it holds: a small category can hold the one control the product needs.\n\nRecord in the specification which categories you have read and which ones the remaining plan still needs, so a later turn resumes instead of starting again. An index or a search result alone is not a completed study, and reading the core is not permission to skip a category when the increment that needs it arrives.\n\nUse Phoenix's existing components, features, and supported workflows whenever they provide the required capability. Guide the client toward those approaches and explain their benefits. Use custom implementations only when the required capability is unavailable: verify the gap in the documentation, explain it and the proposed approach to the client, and keep the solution compatible with Phoenix's architecture. Missing documentation is not proof that a feature is unavailable.\n\nRevisit the relevant implementation examples as you build. [Phoenix UX guidance](references/phoenix-ux.md) provides navigation back to common topics; platform usage belongs in Phoenix docs rather than a parallel manual in this skill. Disclose inaccessible documentation and the resulting uncertainty instead of claiming full coverage or inventing APIs. Do not assume access to Phoenix's source repository or internal processes.\n\n### Maintain a living Markdown specification\n\nAfter inspecting the materials, create `configurator-spec.md` in the intended project, or update its existing equivalent. Keep it outside public/user-facing assets and use it as the single record of:\n\n- Product scope, intended users, source materials, assets, and confirmed product facts.\n- Configurable options, dependencies, compatibility rules, dimensions, and commercial rules.\n- Unknowns, conflicting information, proposals, agent-chosen design defaults, and explicitly agreed provisional business assumptions, distinguished from confirmed facts and client-approved decisions.\n- Accepted visual direction, navigation, interaction patterns, and finalization decisions, with their rationale.\n- The five-stage plan, current stage, implemented and remaining scope, documentation coverage, verification results, and next increment.\n\nUpdate it whenever new information, a decision, or completed work changes the plan. Keep it concise and current, not a conversation transcript. Read it when resuming, inspect the existing draft, and briefly remind the client where things stand. Preserve accepted behavior and styling; explain and agree on material departures before applying them. The specification supports collaboration without making every edit an approval step.",i,a,o,s,r,t.visualInspection,d]});export const generatePhoenixCreateConfiguratorSkillReferences=()=>[{path:"references/phoenix-ux.md",content:h},{path:"references/product-discovery.md",content:p},{path:"references/asset-conversion.md",content:c},{path:"references/appearance-review.md",content:l}];

package/dist/application-spec/generate-application/code/templates/skills/phoenix-review-skill.js

@@ -1,4 +1,4 @@
-import{renderAgentSkill as e}from"./agent-skill.js";let i=`Review all current git changes for correctness, Phoenix pattern violations, and security issues.
+import{renderAgentSkill as e}from"./agent-skill.js";let s=`Review all current git changes for correctness, Phoenix pattern violations, and security issues.
 
 ## Phoenix-Specific Review
 
@@ -28,6 +28,12 @@ import{renderAgentSkill as e}from"./agent-skill.js";let i=`Review all current gi
 - [ ] No unnecessary React re-renders (stable object references via memoEval)
 - [ ] Export pattern correct: default export of single component or array
 
+### Assistant setup (src/handlers/)
+
+- [ ] At most one phx.domain.createAssistantSetupHandler, synchronous, pure and deterministic over manifest and session inputs
+- [ ] Only removes original declaration entries, exposes descriptions and restriction flags, and rejects immutable keys
+- [ ] Narrows fields on the declaring alias before expansion; runs in browser execution and the webhook; browser GraphQL, tools and change recording use session narrowing while UI retains pure spec selectors; empty server instructions clear the baseline
+
 ### Webhooks (src/webhooks/)
 
 - [ ] Use phx.webhooks.\\*Builder pattern (finalizeHandlerBuilder, authHandlerBuilder)
@@ -60,7 +66,7 @@ import{renderAgentSkill as e}from"./agent-skill.js";let i=`Review all current gi
 
 ## Auto-Generated Files — DO NOT modify
 
-- .phoenix/ directory (except the option files in .phoenix/variants/, which the phoenix-variants skill writes), tsconfig.json, eslint.config.js, prettier.config.js
+- .phoenix/ directory (except the option files in .phoenix/variants/, which the phoenix-variants skill writes)
 - src/locales/\\*.ts files
 
 ### Runtime Verification
@@ -106,4 +112,4 @@ import{renderAgentSkill as e}from"./agent-skill.js";let i=`Review all current gi
 - **Overall assessment**: <1-2 sentence summary>
 \`\`\`
 
-If no findings at a severity level, omit that section. If no findings at all, state "No issues found" with a brief note on what was checked.`;export const generatePhoenixReviewSkill=()=>e({name:"phoenix-review",description:"Phoenix-specific code review checklist and report format for specs, expressions, invariants, components, webhooks, TypeScript and React code. Use when reviewing changes in this Phoenix configurator project, before committing or when asked for a code review.",sections:[i]});
+If no findings at a severity level, omit that section. If no findings at all, state "No issues found" with a brief note on what was checked.`;export const generatePhoenixReviewSkill=()=>e({name:"phoenix-review",description:"Phoenix-specific code review checklist and report format for specs, expressions, invariants, components, webhooks, TypeScript and React code. Use when reviewing changes in this Phoenix configurator project, before committing or when asked for a code review.",sections:[s]});

package/dist/application-spec/generate-application/code/templates/skills/phoenix-skill.js

@@ -1 +1 @@
-import{renderAgentSkill as e}from"./agent-skill.js";import{sdkGuidanceSections as t}from"./sdk-content.js";export const followsCanaryBuilds=e=>!e.useWorkspace&&e.sdkVersion.includes("-develop.");export const generatePhoenixSkill=({checkLatestCanary:n})=>e({name:"phoenix",description:`Phoenix SDK project conventions, covering project structure, architecture principles, key patterns, file and export rules, webhook membership, versioning the domain model once it is deployed, showing the user the dev preview and the build of a deploy, the run evaluation that follows a live deploy, inspecting the rendered result, and how to search the SDK documentation${n?", and the internal-beta check for the latest canary SDK build":""}. Use before writing or changing specs or source code in this Phoenix configurator project.`,sections:[...n?["## Stay on the Latest Canary\nDuring the internal beta this project uses the `canary` build of the SDK, which is published from every change to the platform. Once per conversation, before you change anything, compare the installed version with the newest canary:\n```bash\npnpm list @salsita-ai/sdk --depth 0\nnpm view @salsita-ai/sdk@canary version\n```\nWhen they differ, tell the user which version you are moving to, then update the project and regenerate its files:\n```bash\npnpm add @salsita-ai/sdk@canary\npnpm phoenix sync\n```\n`sync` rewrites the Phoenix skills, so read the ones you use again after it. When the user runs a globally installed `phoenix`, update that too with `npm install -g @salsita-ai/sdk@canary`. If the project no longer builds after the update, stop and tell the user; the `phoenix-feedback` skill covers reporting it."]:[],t.projectStructure,t.architecturePrinciples,t.keyPatterns,t.fileConventions,t.exportRules,t.webhookMembership,t.doNotEdit,t.modelVersioning,"## Show the Preview While You Work\nThe user should see the configurator change as you build it. Before your first change in a conversation, make sure `pnpm phoenix dev` is running (start it in the background when it is not) and open the address it prints as `Preview: <url>` (also written to `.phoenix/phoenix-dev.log`) in the user's browser: `open '<url>'` on macOS, `xdg-open '<url>'` on Linux, `Start-Process '<url>'` in PowerShell, `start \"\" \"<url>\"` in cmd. Keep the quotes, the shell would otherwise read a `?` in the address as a pattern. The log keeps the lines of earlier runs, so when you have just started dev, wait for the `Preview:` line written after your start and use the last one. Open it once; the preview reloads on every change, so tell the user to keep that tab open instead of opening it again.",t.visualInspection,'## Show the Build After a Deploy\n`pnpm phoenix deploy` starts a build on the server and waits for it to go live. Right after `Build <id> started` it prints `Follow the build in Studio: <url>`. Run the deploy so that you can read its output while it runs, and open that link in the user\'s browser, quoted as above, as soon as it appears, so they can follow the build they just triggered. When the line is missing, the sign-in is older than the link: tell the user the build is listed under Deployments in Studio, and that `pnpm phoenix login <workspace>` brings the link back.\n\nWhen the deploy reports the configurator live, load the `phoenix-feedback` skill before you write your final message and follow its "Evaluate the Run" section, so the user is asked about the run while they are still there. It is asked once per conversation, and only once the user has nothing more to build.',"## Code Review\nUse the `phoenix-review` skill to review code changes before committing.",t.sdkDocumentation]});
+import{renderAgentSkill as e}from"./agent-skill.js";import{sdkGuidanceSections as t}from"./sdk-content.js";export const followsCanaryBuilds=e=>!e.useWorkspace&&e.sdkVersion.includes("-develop.");export const generatePhoenixSkill=({checkLatestCanary:n})=>e({name:"phoenix",description:`Phoenix SDK project conventions, covering project structure, architecture principles, key patterns, file and export rules, webhook membership, versioning the domain model once it is deployed, showing the user the dev preview and the build of a deploy, the run evaluation that follows a live deploy, inspecting the rendered result, and how to search the SDK documentation${n?", and the internal-beta check for the latest canary SDK build":""}. Use before writing or changing specs or source code, or deploying this Phoenix configurator project.`,sections:[...n?["## Stay on the Latest Canary\nDuring the internal beta this project uses the `canary` build of the SDK, which is published from every change to the platform. Once per conversation, before you change anything, compare the installed version with the newest canary:\n```bash\npnpm list @salsita-ai/sdk --depth 0\nnpm view @salsita-ai/sdk@canary version\n```\nWhen they differ, tell the user which version you are moving to, then update the project and regenerate its files:\n```bash\npnpm add @salsita-ai/sdk@canary\npnpm phoenix sync\n```\n`sync` rewrites the Phoenix skills, so read the ones you use again after it. When the user runs a globally installed `phoenix`, update that too with `npm install -g @salsita-ai/sdk@canary`. If the project no longer builds after the update, stop and tell the user; the `phoenix-feedback` skill covers reporting it."]:[],t.projectStructure,t.architecturePrinciples,t.keyPatterns,t.fileConventions,t.exportRules,t.webhookMembership,t.doNotEdit,t.modelVersioning,"## Show the Preview While You Work\nThe user should see the configurator change as you build it. Before your first change in a conversation, make sure `pnpm phoenix dev` is running (start it in the background when it is not) and open the address it prints as `Preview: <url>` (also written to `.phoenix/phoenix-dev.log`) in the user's browser: `open '<url>'` on macOS, `xdg-open '<url>'` on Linux, `Start-Process '<url>'` in PowerShell, `start \"\" \"<url>\"` in cmd. Keep the quotes, the shell would otherwise read a `?` in the address as a pattern. The log keeps the lines of earlier runs, so when you have just started dev, wait for the `Preview:` line written after your start and use the last one. Open it once; the preview reloads on every change, so tell the user to keep that tab open instead of opening it again.",t.visualInspection,"## Show the Build After a Deploy\nImmediately before invoking `pnpm phoenix deploy`, refresh `conversation.log` in the project root with the current conversation. Prefer the agent application's native session export when available; do not invent an export command or scan unrelated sessions. Otherwise write the messages still available in context and label the log `reconstructed; incomplete`. Never present a compaction summary as verbatim earlier messages.\n\nUse UTF-8 text with a header naming the agent, export time, source (native export or reconstructed), covered session and known omissions. Preserve user and assistant messages in chronological order, plus tool names, arguments and results when available. Keep each tool result to at most 16 KiB of text, marking truncation explicitly; describe image attachments by reference rather than embedding binary/base64 data, and mark references whose files are not uploaded. Exclude internal instructions, hidden reasoning, credentials and unrelated sensitive content; mark redactions without repeating the removed content. Refresh the current session's log rather than appending duplicate copies or silently carrying over a previous session.\n\nShow the user the exact file to review or redact and obtain approval to include it before deploying; do not ask again when they have already approved that file. If they decline, move it out of the project root before deployment so it cannot be collected. Deploy includes the file in the build's private source archive, downloadable by those authorized to download that build's sources, and leaves it out when extracting build inputs. A missing log warns but does not block deployment. The CLI does not export, redact or validate the transcript's completeness for you.\n\n`pnpm phoenix deploy` starts a build on the server and waits for it to go live. Right after `Build <id> started` it prints `Follow the build in Studio: <url>`. Run the deploy so that you can read its output while it runs, and open that link in the user's browser, quoted as above, as soon as it appears, so they can follow the build they just triggered. When the line is missing, the sign-in is older than the link: tell the user the build is listed under Deployments in Studio, and that `pnpm phoenix login <workspace>` brings the link back.\n\nWhen the deploy reports the configurator live, load the `phoenix-feedback` skill before you write your final message and follow its \"Evaluate the Run\" section, so the user is asked about the run while they are still there. It is asked once per conversation, and only once the user has nothing more to build.","## Code Review\nUse the `phoenix-review` skill to review code changes before committing.",t.sdkDocumentation]});

package/dist/application-spec/generate-application/code/templates/skills/sdk-content.d.ts

@@ -1,20 +1,17 @@
 /**
  * Documented Phoenix SDK guidance, one Markdown section per entry.
  *
- * The agent guidance shipped into generated projects — the starter `AGENTS.md` and the Phoenix-owned
- * agent skills — is composed from these sections, so each documented fact has exactly one home and
- * the generated files differ only in which sections they carry.
+ * The agent guidance shipped into generated projects — the Phoenix-owned agent skills — is composed
+ * from these sections, so each documented fact has exactly one home and the generated files differ
+ * only in which sections they carry.
  */
 export declare const sdkGuidanceSections: {
-    /** Opening description of what a Phoenix configurator project is. */
-    readonly projectIntro: `## Phoenix Configurator Project
-
-Declarative 3D product configurator built with Phoenix SDK. Domain model defined in YAML, custom logic in TypeScript.`;
-    /** The three everyday `phoenix` package scripts. */
+    /** The everyday `phoenix` commands, and the one that brings `package.json` in line with the SDK. */
     readonly buildCommands: `## Build Commands
 - \`pnpm phoenix build\` — Full production build
 - \`pnpm phoenix dev\` — Development mode with hot reload
-- \`pnpm phoenix sync\` — Sync generated files without full build`;
+- \`pnpm phoenix sync\` — Sync generated files without full build
+- \`pnpm phoenix deps\` — Add the SDK's missing peer dependencies to \`package.json\` and move out-of-range ones into the SDK's range; it installs nothing, so run \`pnpm install\` after it`;
     /** Where `phoenix dev` writes its log and how to read it. */
     readonly devLogs: `## Dev Logs
 - \`pnpm phoenix dev\` writes all logs to \`.phoenix/phoenix-dev.log\`
@@ -30,8 +27,15 @@ Declarative 3D product configurator built with Phoenix SDK. Domain model defined
 - \`src/transformers/\` — Automatic state fixers (\`phx.frontend.transformerBuilder\`)
 - \`src/components/\` — ECS system components (\`phx.domain.attachComponent.withEntity()\`)
 - \`src/elements/\` — Page-level React components (\`phx.frontend.createCustomPhoenixLayoutElement()\`)
+  - \`ConfiguratorLayout\`: a layout element with this name replaces everything the built-in layout renders for a loaded configuration, in owner and read mode, finalization included. Prefer arranging the spec's layout components; write one for shell-level changes, such as moving the sidebar or adding an area the built-in layout has no place for
+    - Mount \`LayoutSlots.SharedCanvas\` (from \`@salsita-ai/sdk/configurator\`) in a positioned root covering the page, or the app loader stays on screen; put the UI above it, positioned and after it in the markup. Call \`useSceneSafeArea()\` (same import) and put \`containerRef\` on the element covering the whole canvas and \`safeAreaRef\` on the region the UI leaves free, with \`pointerEvents: 'none'\`, so the camera frames the scene there
+    - Sidebar moved, contents as the spec configures them: mount \`LayoutSlots.DesktopSidebar\` in a positioned container that sets its size, with \`side="start"\` on the left; \`docs/layouts/sidebar/in-a-custom-layout.mdx\` is the whole layout
+    - Your own UI: "Hooks for a Project Layout" in \`docs/phoenix/configurator-interface.mdx\` lists the hooks with what each returns (\`pnpm phoenix docs -r docs/phoenix/configurator-interface.mdx\`), \`docs/phoenix/layout-slots.mdx\` the built-in pieces you can still mount, and \`docs/layouts/custom-layout.mdx\` is a worked example
+    - Messages: mount \`LayoutSlots.Services\` for the built-in snackbars, or show violations, side-effect hints and errors yourself with \`phx.frontend.useConfiguratorMessages(onMessage)\`, not both. Either way mount a snackbar root (\`LayoutSlots.DesktopSnackbarsRoot\` or \`LayoutSlots.MobileSnackbarsRoot\`): save and built-in action errors are always snackbars
+    - Finalize over the spec's \`finalizeAction\` components, each naming a handler registered with \`phx.frontend.createPhoenixHandler\`: run each with \`phx.frontend.useFinalizeAction(handler)\` in a component of its own wrapped in \`PhoenixHandlerBoundary\` (from \`@salsita-ai/sdk/react\`), or mount \`FinalizeActions\` (from \`@salsita-ai/sdk/configurator\`) for the built-in buttons. \`finalizePage\` and \`finalizeButton\` are legacy
+    - Read mode and fullscreen are the layout's job, no hook enforces them: hide what a viewer must not change while \`phx.frontend.useAccessService().accessInfo.viewMode\` is \`true\`, and remove panels while \`phx.frontend.useIsFullscreenActive()\` is set; \`phx.frontend.useSetFullscreen()\` returns its setter
 - \`src/handlers/\` — Event & lifecycle handlers
-- \`src/webhooks/\` — Server-side webhook handlers (\`phx.webhooks.*Builder\`)
+- \`src/webhooks/\` — Server-side webhook handlers (\`phx.webhooks.*Builder\`); the webhook is the default export of \`src/webhooks/index.ts\`, which you create when the project needs its own handlers — without it the build uses a built-in inert webhook that answers only anonymous auth, so create the file before setting \`useAuthHook\` or \`useClerk\`
 - \`src/migrations/\` — Schema version migrations (v*.ts)
 - \`src/locales/\` — Locale catalogs (authored .po sources; compiled .ts, do not edit)
 - \`src/admin/\` — Admin interface (mirrors main src/ structure)
@@ -70,15 +74,17 @@ The default export must be what the folder's phx factory returns (for example \`
     /** Which components and handlers are bundled into the webhook. */
     readonly webhookMembership: `## Webhook Membership
 - User-authored components, admin components, and handlers are frontend-only by default.
-- A handler that registers \`createMapPublishedRevisionDataHandler\`, \`createMapPublishedChunkedDataHandler\`, \`createDataRowValidatorHandler\`, or \`createSheetValidatorHandler\` is included in the webhook automatically.
+- A handler that registers \`phx.domain.createAssistantSetupHandler\`, \`createMapPublishedRevisionDataHandler\`, \`createMapPublishedChunkedDataHandler\`, \`createDataRowValidatorHandler\`, or \`createSheetValidatorHandler\` is included in the webhook automatically.
+- An assistant setup handler receives the declaration-shaped whitelist and { role, sessionData, access }. Keep the exact entity/alias split from YAML; inherited fields and expanded member entries are absent. Narrow original declarations, then the SDK expands them. Use project-defined role/session data for per-user customization. Keep the handler synchronous, pure and deterministic. The handler runs in the browser and webhook. Return null to disable assistant execution, or omit whitelist entries to restrict them. Button and panel visibility use spec presence; project developers own dynamic UI filtering through normal layout mechanics such as $filter. Leaves expose optional descriptions; writable options allow only validate: true and allowDryRuns: false; recipe groups allow descriptions and allowDryRuns: false. Deletable entries are {}. Names, component bindings, hints and types are internal. Omitted overrides retain baseline values. Existing entity, enhanced-entity and action types constrain the handler; no separate generated manifest types. Browser GraphQL, tools and change recording use the session-derived manifest; rejected setup fails closed. UI reads the pure spec selector. Omitted server instructions or AI fields preserve the baseline. An empty server instructions string clears it.
 - To include another component or handler in the webhook, put \`'use webhook'\` as its first statement (leading comments are allowed).
 - A webhook-included file and its runtime local-import closure must not import browser SDK entrypoints (\`application\`, \`admin\`, \`configurator\`, \`editor\`, \`react\`, \`ui\`) or style/font/image assets. Spec parsing reports the unsafe import and inclusion reason as a diagnostic.
 - Keep browser rendering in an unpinned file. Move shared server-safe logic into a separate module when both frontend and webhook code need it.`;
     /** Generated files a project must not edit. */
     readonly doNotEdit: `## Do Not Edit
-- \`.phoenix/\` directory — completely regenerated on each build. The one exception is \`.phoenix/variants/\`, where the \`phoenix-variants\` skill has you write option files; a rebuild keeps it
-- \`tsconfig.json\`, \`eslint.config.js\`, \`prettier.config.js\`, \`.prettierignore\`, \`.linguirc\`, \`.nvmrc\`
-- \`src/locales/\` .ts files — compiled from .po files`;
+- \`.phoenix/\` directory — completely regenerated on each build. The one exception is \`.phoenix/variants/\`, where the \`phoenix-variants\` skill has you write option files; a rebuild keeps it. The project's TypeScript settings come from \`.phoenix/tsconfig.json\`; the root \`tsconfig.json\` is the project's and extends it. \`phoenix dev\`, \`phoenix build\` and the webhook bundle do not resolve \`paths\` aliases, so an alias added to the root file passes \`phoenix check\` and fails the build; use relative imports
+- \`.nvmrc\`
+- \`src/locales/\` .ts files — compiled from .po files
+- \`phoenix\` and \`phoenix-*\` folders under \`.claude/skills/\` and \`.agents/skills/\` — Phoenix rewrites its skills on every sync, removes anything else inside their folders and removes any other \`phoenix-*\` skill folder. To customise a skill, copy it to a folder whose name does not start with \`phoenix\``;
     /** When and how a deployed domain model gets a new version and a migration, with the recipe for replacing the starter. */
     readonly modelVersioning: `## Version the Domain Model Once It Is Deployed
 A deployed model version cannot change, because saved configurations depend on it. \`pnpm phoenix deploy\` is refused, before anything is uploaded, when the model differs from the one already deployed under the same version. The version is not written anywhere: \`model.latest\` is always the highest numbered version plus one, so a spec with only \`latest\` is v1, and \`applicationVersion\` plays no part. \`pnpm phoenix dev\` accepts every model change, so a working preview does not show that the deploy will pass.
@@ -284,10 +290,10 @@ Rendered appearance is a deliverable, not a side effect. Before presenting any p
 Inspect and report:
 
 1. Geometry. Every part rests on its support. Name where the product meets the ground and confirm its shadow and any selection indicator sit there too. Nothing floats, intersects, or protrudes. Scale and orientation are consistent between parts and match the stated dimensions. Each part is complete and present.
-2. Fidelity. The result matches the client's own photographs, renders, and drawings where supplied. Name any divergence.
-3. Response. Every configurable surface of every part reacts to its control, not only the parts you just changed.
-4. Density. Every decision the user must make is reachable without hunting, and no single property's options dominate the surface holding them.
-5. Loading. How long until a meaningful first frame, and whether anything indicates progress meanwhile.
+2. Response. Every configurable surface of every part reacts to its control, not only the parts you just changed.
+3. Loading. How long until a meaningful first frame, and whether anything indicates progress meanwhile.
+
+This covers what follows from the change you just made, in the state you are already in. Fidelity against the client's own material, the density of the controls, and every state you did not open belong to an independent reviewer, which the \`phoenix-create-configurator\` skill's Appearance review covers.
 
 Report defects you are deferring as defects. Do not call work done, verified, or complete while any of the above is unchecked or failing: say which, and recommend fixing now or later.
 

package/dist/application-spec/generate-application/code/templates/skills/sdk-content.js

@@ -1,12 +1,10 @@
-export const sdkGuidanceSections={projectIntro:`## Phoenix Configurator Project
-
-Declarative 3D product configurator built with Phoenix SDK. Domain model defined in YAML, custom logic in TypeScript.`,buildCommands:"## Build Commands\n- `pnpm phoenix build` — Full production build\n- `pnpm phoenix dev` — Development mode with hot reload\n- `pnpm phoenix sync` — Sync generated files without full build",devLogs:"## Dev Logs\n- `pnpm phoenix dev` writes all logs to `.phoenix/phoenix-dev.log`\n- Contains: spec parse errors, build errors, browser runtime errors, file watcher events\n- After making changes, always check the log for errors: `tail -50 .phoenix/phoenix-dev.log` or `grep ERROR .phoenix/phoenix-dev.log`\n- Rotated automatically at 10MB (`.log.1`, `.log.2` are older rotations)",projectStructure:"## Project Structure\n- `spec/` — Domain YAML specs (entities, relations, expressions, invariants, components, application config)\n- `src/expressions/` — Computed/derived entity properties (`phx.domain.implementCustomExpressions()`)\n- `src/actions/` — Domain operations declared under `actions:` in the spec (`phx.domain.implementActions()`), run by controls and exposed to the assistant\n- `src/invariants/` — Business rule constraints (`phx.domain.implementCustomInvariants()`)\n- `src/transformers/` — Automatic state fixers (`phx.frontend.transformerBuilder`)\n- `src/components/` — ECS system components (`phx.domain.attachComponent.withEntity()`)\n- `src/elements/` — Page-level React components (`phx.frontend.createCustomPhoenixLayoutElement()`)\n- `src/handlers/` — Event & lifecycle handlers\n- `src/webhooks/` — Server-side webhook handlers (`phx.webhooks.*Builder`)\n- `src/migrations/` — Schema version migrations (v*.ts)\n- `src/locales/` — Locale catalogs (authored .po sources; compiled .ts, do not edit)\n- `src/admin/` — Admin interface (mirrors main src/ structure)\n- `src/_shared/` — Shared utilities (NOT auto-imported, requires explicit imports)\n- `.phoenix/` — Auto-generated files (DO NOT EDIT, except the option files in `.phoenix/variants/`)\n- `public/` — Static assets (3D models, textures, images, HDRI maps, fonts)\n- `assets/` — Uploadable resources (PDF templates, email assets)",architecturePrinciples:"## Architecture Principles\n- YAML-first: 99% of configuration in spec/*.yaml, custom code is last resort\n- ECS pattern: entities (domain objects) + components (behavior/UI) + systems (SDK runtime)\n- Reactive state: immutable domain state flows through RxJS pipelines\n- Data binding: `$read` (read-only), `$write` (write-only), `$bind` (bidirectional) connect components to domain\n- memoEval: all component implementations must use memoEval for stable object references",keyPatterns:"## Key Patterns\n- Expressions = computed properties on entities (prefix: `$`), implemented per-entity in src/expressions/\n- Actions = named domain operations (`actions:` in YAML with `params` and `result` schemas), implemented in src/actions/, prepared through `actionSystem.prepareAction()` and exposed as assistant mutations through `assistant.actions`\n- Invariants = validation rules returning violations, static or dynamic\n- Transformers = auto-fixers maintaining consistency after state changes\n- Components defined in YAML with `$read`/`$bind` bindings, or custom in src/components/ using attachComponent builder\n- Webhooks = server-side finalization tasks (PDF, email, CSV, image rendering)\n- Filters = contextual component activation via navigationStates, viewStates, modes, selectedEntityIds",fileConventions:`## File Conventions
+export const sdkGuidanceSections={buildCommands:"## Build Commands\n- `pnpm phoenix build` — Full production build\n- `pnpm phoenix dev` — Development mode with hot reload\n- `pnpm phoenix sync` — Sync generated files without full build\n- `pnpm phoenix deps` — Add the SDK's missing peer dependencies to `package.json` and move out-of-range ones into the SDK's range; it installs nothing, so run `pnpm install` after it",devLogs:"## Dev Logs\n- `pnpm phoenix dev` writes all logs to `.phoenix/phoenix-dev.log`\n- Contains: spec parse errors, build errors, browser runtime errors, file watcher events\n- After making changes, always check the log for errors: `tail -50 .phoenix/phoenix-dev.log` or `grep ERROR .phoenix/phoenix-dev.log`\n- Rotated automatically at 10MB (`.log.1`, `.log.2` are older rotations)",projectStructure:"## Project Structure\n- `spec/` — Domain YAML specs (entities, relations, expressions, invariants, components, application config)\n- `src/expressions/` — Computed/derived entity properties (`phx.domain.implementCustomExpressions()`)\n- `src/actions/` — Domain operations declared under `actions:` in the spec (`phx.domain.implementActions()`), run by controls and exposed to the assistant\n- `src/invariants/` — Business rule constraints (`phx.domain.implementCustomInvariants()`)\n- `src/transformers/` — Automatic state fixers (`phx.frontend.transformerBuilder`)\n- `src/components/` — ECS system components (`phx.domain.attachComponent.withEntity()`)\n- `src/elements/` — Page-level React components (`phx.frontend.createCustomPhoenixLayoutElement()`)\n  - `ConfiguratorLayout`: a layout element with this name replaces everything the built-in layout renders for a loaded configuration, in owner and read mode, finalization included. Prefer arranging the spec's layout components; write one for shell-level changes, such as moving the sidebar or adding an area the built-in layout has no place for\n    - Mount `LayoutSlots.SharedCanvas` (from `@salsita-ai/sdk/configurator`) in a positioned root covering the page, or the app loader stays on screen; put the UI above it, positioned and after it in the markup. Call `useSceneSafeArea()` (same import) and put `containerRef` on the element covering the whole canvas and `safeAreaRef` on the region the UI leaves free, with `pointerEvents: 'none'`, so the camera frames the scene there\n    - Sidebar moved, contents as the spec configures them: mount `LayoutSlots.DesktopSidebar` in a positioned container that sets its size, with `side=\"start\"` on the left; `docs/layouts/sidebar/in-a-custom-layout.mdx` is the whole layout\n    - Your own UI: \"Hooks for a Project Layout\" in `docs/phoenix/configurator-interface.mdx` lists the hooks with what each returns (`pnpm phoenix docs -r docs/phoenix/configurator-interface.mdx`), `docs/phoenix/layout-slots.mdx` the built-in pieces you can still mount, and `docs/layouts/custom-layout.mdx` is a worked example\n    - Messages: mount `LayoutSlots.Services` for the built-in snackbars, or show violations, side-effect hints and errors yourself with `phx.frontend.useConfiguratorMessages(onMessage)`, not both. Either way mount a snackbar root (`LayoutSlots.DesktopSnackbarsRoot` or `LayoutSlots.MobileSnackbarsRoot`): save and built-in action errors are always snackbars\n    - Finalize over the spec's `finalizeAction` components, each naming a handler registered with `phx.frontend.createPhoenixHandler`: run each with `phx.frontend.useFinalizeAction(handler)` in a component of its own wrapped in `PhoenixHandlerBoundary` (from `@salsita-ai/sdk/react`), or mount `FinalizeActions` (from `@salsita-ai/sdk/configurator`) for the built-in buttons. `finalizePage` and `finalizeButton` are legacy\n    - Read mode and fullscreen are the layout's job, no hook enforces them: hide what a viewer must not change while `phx.frontend.useAccessService().accessInfo.viewMode` is `true`, and remove panels while `phx.frontend.useIsFullscreenActive()` is set; `phx.frontend.useSetFullscreen()` returns its setter\n- `src/handlers/` — Event & lifecycle handlers\n- `src/webhooks/` — Server-side webhook handlers (`phx.webhooks.*Builder`); the webhook is the default export of `src/webhooks/index.ts`, which you create when the project needs its own handlers — without it the build uses a built-in inert webhook that answers only anonymous auth, so create the file before setting `useAuthHook` or `useClerk`\n- `src/migrations/` — Schema version migrations (v*.ts)\n- `src/locales/` — Locale catalogs (authored .po sources; compiled .ts, do not edit)\n- `src/admin/` — Admin interface (mirrors main src/ structure)\n- `src/_shared/` — Shared utilities (NOT auto-imported, requires explicit imports)\n- `.phoenix/` — Auto-generated files (DO NOT EDIT, except the option files in `.phoenix/variants/`)\n- `public/` — Static assets (3D models, textures, images, HDRI maps, fonts)\n- `assets/` — Uploadable resources (PDF templates, email assets)",architecturePrinciples:"## Architecture Principles\n- YAML-first: 99% of configuration in spec/*.yaml, custom code is last resort\n- ECS pattern: entities (domain objects) + components (behavior/UI) + systems (SDK runtime)\n- Reactive state: immutable domain state flows through RxJS pipelines\n- Data binding: `$read` (read-only), `$write` (write-only), `$bind` (bidirectional) connect components to domain\n- memoEval: all component implementations must use memoEval for stable object references",keyPatterns:"## Key Patterns\n- Expressions = computed properties on entities (prefix: `$`), implemented per-entity in src/expressions/\n- Actions = named domain operations (`actions:` in YAML with `params` and `result` schemas), implemented in src/actions/, prepared through `actionSystem.prepareAction()` and exposed as assistant mutations through `assistant.actions`\n- Invariants = validation rules returning violations, static or dynamic\n- Transformers = auto-fixers maintaining consistency after state changes\n- Components defined in YAML with `$read`/`$bind` bindings, or custom in src/components/ using attachComponent builder\n- Webhooks = server-side finalization tasks (PDF, email, CSV, image rendering)\n- Filters = contextual component activation via navigationStates, viewStates, modes, selectedEntityIds",fileConventions:`## File Conventions
 - Components: PascalCase (.tsx)
 - Utilities: kebab-case (.ts)
 - Expressions: entity-name.ts
 - Migrations: v*.ts (sequential)
 - Specs: kebab-case.yaml
-- Underscore folders (_shared/, _utils/) are NOT auto-imported`,exportRules:'## Export Rules\nAll files in src/expressions/, src/actions/, src/invariants/, src/transformers/, src/components/, src/handlers/, src/elements/, src/webhooks/ MUST use default exports. Can be a single item or an array. Named exports are ignored by the SDK auto-import system.\nThe default export must be what the folder\'s phx factory returns (for example `phx.frontend.createCustomPhoenixLayoutElement()` in src/elements/). Any other value, such as a plain React component, stops the application at start with an "Invalid default export in <file>" error. Put plain components and helpers in an underscore folder.',webhookMembership:"## Webhook Membership\n- User-authored components, admin components, and handlers are frontend-only by default.\n- A handler that registers `createMapPublishedRevisionDataHandler`, `createMapPublishedChunkedDataHandler`, `createDataRowValidatorHandler`, or `createSheetValidatorHandler` is included in the webhook automatically.\n- To include another component or handler in the webhook, put `'use webhook'` as its first statement (leading comments are allowed).\n- A webhook-included file and its runtime local-import closure must not import browser SDK entrypoints (`application`, `admin`, `configurator`, `editor`, `react`, `ui`) or style/font/image assets. Spec parsing reports the unsafe import and inclusion reason as a diagnostic.\n- Keep browser rendering in an unpinned file. Move shared server-safe logic into a separate module when both frontend and webhook code need it.",doNotEdit:"## Do Not Edit\n- `.phoenix/` directory — completely regenerated on each build. The one exception is `.phoenix/variants/`, where the `phoenix-variants` skill has you write option files; a rebuild keeps it\n- `tsconfig.json`, `eslint.config.js`, `prettier.config.js`, `.prettierignore`, `.linguirc`, `.nvmrc`\n- `src/locales/` .ts files — compiled from .po files",modelVersioning:"## Version the Domain Model Once It Is Deployed\nA deployed model version cannot change, because saved configurations depend on it. `pnpm phoenix deploy` is refused, before anything is uploaded, when the model differs from the one already deployed under the same version. The version is not written anywhere: `model.latest` is always the highest numbered version plus one, so a spec with only `latest` is v1, and `applicationVersion` plays no part. `pnpm phoenix dev` accepts every model change, so a working preview does not show that the deploy will pass.\n\nTo change a model that has been deployed as v<N>:\n1. Keep the deployed model, unchanged, as `model.v<N>` in the spec. A file of its own, such as `spec/model-v<N>.yaml`, keeps `latest` readable.\n2. Make the change in `model.latest`, which is now v<N+1>.\n3. Add `src/migrations/v<N+1>.ts` exporting `migrateToV<N+1>`. It receives the saved entities of v<N> and returns entities that are valid in v<N+1>; `ModelV<N>` and `ModelV<N+1>` are generated global namespaces.\n\nThe admin model is versioned on its own, under `src/admin/migrations/`, with its types in `AdminV<N>`.\n\n**Replacing the starter.** When the first deployment of the workspace was the starter, its `Box` model is v1 in production. When the real model replaces it, keep the starter's model as `model.v1` and define the real model in `latest`. Configurations saved from the starter are not worth converting, so the migration returns the starting state of the new model, the `initialDomainEntities` of its preset, and drops the boxes:\n```typescript\n// src/migrations/v2.ts\nimport type { Migration } from '@salsita-ai/sdk/domain'\n\nexport const migrateToV2: Migration<ModelV1.AnyDomainEntity, ModelV2.AnyDomainEntity> = () => [\n  // the entities of the new model's preset\n]\n```\nAn entity of a type the new version no longer has must not stay in the returned state. An entity id starts with its type (`Box-1`), so an entity that keeps its data under a new type name needs a new id and every relation pointing at it rewritten. Read `docs/phoenix/migrations.mdx` before writing any other migration.",sdkDocumentation:'## SDK Documentation\n\nAlways search SDK docs for relevant examples before implementing Phoenix features.\n\n### Commands\n- `pnpm phoenix docs` — Full documentation index with descriptions\n- `pnpm phoenix docs -s <term>` — Search all doc content and metadata (case-insensitive)\n- `pnpm phoenix docs --dir` — Print the absolute docs directory for grep or ripgrep\n- `pnpm phoenix docs -r <path>` — Read specific doc (raw text to stdout)\n- `pnpm phoenix docs -c <category>` — List docs in a category\n- `pnpm phoenix docs -l` — List all doc paths with titles\n\n### Key Docs\n- `docs/phoenix/getting-started.mdx` — Setup, prerequisites, first project\n- `docs/phoenix/quickstart.mdx` — End-to-end tutorial building a configurator\n- `docs/phoenix/domain-model.mdx` — Entities, attributes, relations, specs\n- `docs/phoenix/components.mdx` — ECS pattern, YAML components, custom components\n- `docs/phoenix/project-structure.mdx` — Files, folders, conventions\n- `docs/phoenix/best-practices.mdx` — YAML-first, code patterns, common pitfalls\n- `docs/phoenix/state-management.mdx` — Reactive state, RxJS pipelines, data flow\n- `docs/phoenix/expression-context.mdx` — Expression API, context object, helpers\n- `docs/phoenix/webhooks.mdx` — Server-side finalization workflows\n- `docs/phoenix/finalization.mdx` — Finalization system, PDF/email/CSV generation\n- `docs/phoenix/migrations.mdx` — Schema versioning, migration files\n\n### Agent Workflow\n1. Find relevant docs by content: `pnpm phoenix docs -s \'camera\'`\n2. Read matching doc: `pnpm phoenix docs -r docs/3d-scene/cameras/transitions.mdx`\n3. Search within a doc: `pnpm phoenix docs -r <path> | grep "example"`\n4. Search titles only as a fallback: `pnpm phoenix docs -l | grep "camera"`\n5. Search generated files directly when needed: `grep -rn "camera" "$(pnpm phoenix docs --dir)"`\n6. Browse a topic area: `pnpm phoenix docs -c "Layouts"`',assetInspection:"## 3D Asset Inspection\n\nRun `pnpm phoenix inspect:assets` to discover all glTF/GLB files in `public/` and get a summary table. Use `--file <path>` for detailed single-file inspection.\n\n**When to use:** before writing YAML/code that references objectName, materialsToOverride, morphTargetInfluences, or object positioning.\n\n**What it shows per node:**\n- Name, type (Mesh/Light/Camera/Empty), children\n- Transform: `pos=`, `rot=`, `scale=` (only non-default values shown)\n- Per-node morph targets: `morphs=Width,Height`\n- Bounding box: `bounds=WxHxD` (width x height x depth in meters)\n- Origin placement: `origin=center`, `bottom-center`, `top-center`, `bottom-corner`, etc. with numerical offset\n\n**Use cases:**\n- Find exact node names for `objectName` in scene entity components\n- Find material names for `materialsToOverride`\n- Find morph target names for `morphTargetInfluences`\n- Check model dimensions (bounds) for positioning, dimension indicators, or invariants\n- Check origin placement to understand how models anchor (center vs bottom-center)\n- Use `--json` for programmatic access to all data\n\n**Flags:** `--objects`, `--materials`, `--morphs`, `--animations`, `--json`",screenshotCli:"## Screenshot CLI\n\nCapture 3D canvas screenshots from a running dev server via `pnpm phoenix screenshot`.\n\n**Prerequisites:**\n1. `phoenix dev` must be running (starts the WebSocket server on port 3020)\n2. Configurator must be open in a browser (the browser does the actual rendering)\n\n**Options:**\n- `--output, -o` — Output file path (default: `./screenshot.png`)\n- `--width, -w` — Width in pixels (default: 1920)\n- `--height` — Height in pixels (default: 1080)\n- `--format, -f` — Image format: PNG or JPEG (default: PNG)\n- `--port` — WebSocket server port (default: 3020)\n\n**Example workflow:**\n1. Start dev server: `pnpm phoenix dev`\n2. Open configurator in browser (or via Playwright MCP)\n3. Take screenshot: `pnpm phoenix screenshot -o ./render.png -w 2560 --height 1440`\n\n**Use cases:** visual regression testing, generating product images, debugging 3D renders",inspectState:"## Inspect: State\n\nGet the current editor runtime state as JSON via `pnpm phoenix inspect:state`.\n\n**Prerequisites:** same as screenshot (dev server running + browser open)\n\n**Options:**\n- `--output, -o` — Output file path (prints to stdout if omitted)\n- `--sections, -s` — Comma-separated: entities, navigation, validation (default: all)\n- `--pretty` — Pretty-print JSON (default: true)\n- `--port` — WebSocket server port (default: 3020)\n\n**Example:** `pnpm phoenix inspect:state -o ./state.json -s entities,navigation`\n\n**Lifecycle status:** Always included in response. Shows which systems are ready:\n- `domainLoaded` — domain data loaded\n- `domainContextReady` — domain context initialized (entities available)\n- `configuratorReady` — 3D configurator initialized\n- `sessionAuthenticated` — session service active\n- `editorMode` — editor mode enabled\n\n**Tips:** Use `--sections` to limit payload size. Pipe through `head`/`tail` for partial output (e.g., `pnpm phoenix inspect:state | head -50`).\n\n**Use cases:** AI agent context, debugging entity state, inspecting navigation/validation",inspectData:`## Inspect: Data
+- Underscore folders (_shared/, _utils/) are NOT auto-imported`,exportRules:'## Export Rules\nAll files in src/expressions/, src/actions/, src/invariants/, src/transformers/, src/components/, src/handlers/, src/elements/, src/webhooks/ MUST use default exports. Can be a single item or an array. Named exports are ignored by the SDK auto-import system.\nThe default export must be what the folder\'s phx factory returns (for example `phx.frontend.createCustomPhoenixLayoutElement()` in src/elements/). Any other value, such as a plain React component, stops the application at start with an "Invalid default export in <file>" error. Put plain components and helpers in an underscore folder.',webhookMembership:"## Webhook Membership\n- User-authored components, admin components, and handlers are frontend-only by default.\n- A handler that registers `phx.domain.createAssistantSetupHandler`, `createMapPublishedRevisionDataHandler`, `createMapPublishedChunkedDataHandler`, `createDataRowValidatorHandler`, or `createSheetValidatorHandler` is included in the webhook automatically.\n- An assistant setup handler receives the declaration-shaped whitelist and { role, sessionData, access }. Keep the exact entity/alias split from YAML; inherited fields and expanded member entries are absent. Narrow original declarations, then the SDK expands them. Use project-defined role/session data for per-user customization. Keep the handler synchronous, pure and deterministic. The handler runs in the browser and webhook. Return null to disable assistant execution, or omit whitelist entries to restrict them. Button and panel visibility use spec presence; project developers own dynamic UI filtering through normal layout mechanics such as $filter. Leaves expose optional descriptions; writable options allow only validate: true and allowDryRuns: false; recipe groups allow descriptions and allowDryRuns: false. Deletable entries are {}. Names, component bindings, hints and types are internal. Omitted overrides retain baseline values. Existing entity, enhanced-entity and action types constrain the handler; no separate generated manifest types. Browser GraphQL, tools and change recording use the session-derived manifest; rejected setup fails closed. UI reads the pure spec selector. Omitted server instructions or AI fields preserve the baseline. An empty server instructions string clears it.\n- To include another component or handler in the webhook, put `'use webhook'` as its first statement (leading comments are allowed).\n- A webhook-included file and its runtime local-import closure must not import browser SDK entrypoints (`application`, `admin`, `configurator`, `editor`, `react`, `ui`) or style/font/image assets. Spec parsing reports the unsafe import and inclusion reason as a diagnostic.\n- Keep browser rendering in an unpinned file. Move shared server-safe logic into a separate module when both frontend and webhook code need it.",doNotEdit:"## Do Not Edit\n- `.phoenix/` directory — completely regenerated on each build. The one exception is `.phoenix/variants/`, where the `phoenix-variants` skill has you write option files; a rebuild keeps it. The project's TypeScript settings come from `.phoenix/tsconfig.json`; the root `tsconfig.json` is the project's and extends it. `phoenix dev`, `phoenix build` and the webhook bundle do not resolve `paths` aliases, so an alias added to the root file passes `phoenix check` and fails the build; use relative imports\n- `.nvmrc`\n- `src/locales/` .ts files — compiled from .po files\n- `phoenix` and `phoenix-*` folders under `.claude/skills/` and `.agents/skills/` — Phoenix rewrites its skills on every sync, removes anything else inside their folders and removes any other `phoenix-*` skill folder. To customise a skill, copy it to a folder whose name does not start with `phoenix`",modelVersioning:"## Version the Domain Model Once It Is Deployed\nA deployed model version cannot change, because saved configurations depend on it. `pnpm phoenix deploy` is refused, before anything is uploaded, when the model differs from the one already deployed under the same version. The version is not written anywhere: `model.latest` is always the highest numbered version plus one, so a spec with only `latest` is v1, and `applicationVersion` plays no part. `pnpm phoenix dev` accepts every model change, so a working preview does not show that the deploy will pass.\n\nTo change a model that has been deployed as v<N>:\n1. Keep the deployed model, unchanged, as `model.v<N>` in the spec. A file of its own, such as `spec/model-v<N>.yaml`, keeps `latest` readable.\n2. Make the change in `model.latest`, which is now v<N+1>.\n3. Add `src/migrations/v<N+1>.ts` exporting `migrateToV<N+1>`. It receives the saved entities of v<N> and returns entities that are valid in v<N+1>; `ModelV<N>` and `ModelV<N+1>` are generated global namespaces.\n\nThe admin model is versioned on its own, under `src/admin/migrations/`, with its types in `AdminV<N>`.\n\n**Replacing the starter.** When the first deployment of the workspace was the starter, its `Box` model is v1 in production. When the real model replaces it, keep the starter's model as `model.v1` and define the real model in `latest`. Configurations saved from the starter are not worth converting, so the migration returns the starting state of the new model, the `initialDomainEntities` of its preset, and drops the boxes:\n```typescript\n// src/migrations/v2.ts\nimport type { Migration } from '@salsita-ai/sdk/domain'\n\nexport const migrateToV2: Migration<ModelV1.AnyDomainEntity, ModelV2.AnyDomainEntity> = () => [\n  // the entities of the new model's preset\n]\n```\nAn entity of a type the new version no longer has must not stay in the returned state. An entity id starts with its type (`Box-1`), so an entity that keeps its data under a new type name needs a new id and every relation pointing at it rewritten. Read `docs/phoenix/migrations.mdx` before writing any other migration.",sdkDocumentation:'## SDK Documentation\n\nAlways search SDK docs for relevant examples before implementing Phoenix features.\n\n### Commands\n- `pnpm phoenix docs` — Full documentation index with descriptions\n- `pnpm phoenix docs -s <term>` — Search all doc content and metadata (case-insensitive)\n- `pnpm phoenix docs --dir` — Print the absolute docs directory for grep or ripgrep\n- `pnpm phoenix docs -r <path>` — Read specific doc (raw text to stdout)\n- `pnpm phoenix docs -c <category>` — List docs in a category\n- `pnpm phoenix docs -l` — List all doc paths with titles\n\n### Key Docs\n- `docs/phoenix/getting-started.mdx` — Setup, prerequisites, first project\n- `docs/phoenix/quickstart.mdx` — End-to-end tutorial building a configurator\n- `docs/phoenix/domain-model.mdx` — Entities, attributes, relations, specs\n- `docs/phoenix/components.mdx` — ECS pattern, YAML components, custom components\n- `docs/phoenix/project-structure.mdx` — Files, folders, conventions\n- `docs/phoenix/best-practices.mdx` — YAML-first, code patterns, common pitfalls\n- `docs/phoenix/state-management.mdx` — Reactive state, RxJS pipelines, data flow\n- `docs/phoenix/expression-context.mdx` — Expression API, context object, helpers\n- `docs/phoenix/webhooks.mdx` — Server-side finalization workflows\n- `docs/phoenix/finalization.mdx` — Finalization system, PDF/email/CSV generation\n- `docs/phoenix/migrations.mdx` — Schema versioning, migration files\n\n### Agent Workflow\n1. Find relevant docs by content: `pnpm phoenix docs -s \'camera\'`\n2. Read matching doc: `pnpm phoenix docs -r docs/3d-scene/cameras/transitions.mdx`\n3. Search within a doc: `pnpm phoenix docs -r <path> | grep "example"`\n4. Search titles only as a fallback: `pnpm phoenix docs -l | grep "camera"`\n5. Search generated files directly when needed: `grep -rn "camera" "$(pnpm phoenix docs --dir)"`\n6. Browse a topic area: `pnpm phoenix docs -c "Layouts"`',assetInspection:"## 3D Asset Inspection\n\nRun `pnpm phoenix inspect:assets` to discover all glTF/GLB files in `public/` and get a summary table. Use `--file <path>` for detailed single-file inspection.\n\n**When to use:** before writing YAML/code that references objectName, materialsToOverride, morphTargetInfluences, or object positioning.\n\n**What it shows per node:**\n- Name, type (Mesh/Light/Camera/Empty), children\n- Transform: `pos=`, `rot=`, `scale=` (only non-default values shown)\n- Per-node morph targets: `morphs=Width,Height`\n- Bounding box: `bounds=WxHxD` (width x height x depth in meters)\n- Origin placement: `origin=center`, `bottom-center`, `top-center`, `bottom-corner`, etc. with numerical offset\n\n**Use cases:**\n- Find exact node names for `objectName` in scene entity components\n- Find material names for `materialsToOverride`\n- Find morph target names for `morphTargetInfluences`\n- Check model dimensions (bounds) for positioning, dimension indicators, or invariants\n- Check origin placement to understand how models anchor (center vs bottom-center)\n- Use `--json` for programmatic access to all data\n\n**Flags:** `--objects`, `--materials`, `--morphs`, `--animations`, `--json`",screenshotCli:"## Screenshot CLI\n\nCapture 3D canvas screenshots from a running dev server via `pnpm phoenix screenshot`.\n\n**Prerequisites:**\n1. `phoenix dev` must be running (starts the WebSocket server on port 3020)\n2. Configurator must be open in a browser (the browser does the actual rendering)\n\n**Options:**\n- `--output, -o` — Output file path (default: `./screenshot.png`)\n- `--width, -w` — Width in pixels (default: 1920)\n- `--height` — Height in pixels (default: 1080)\n- `--format, -f` — Image format: PNG or JPEG (default: PNG)\n- `--port` — WebSocket server port (default: 3020)\n\n**Example workflow:**\n1. Start dev server: `pnpm phoenix dev`\n2. Open configurator in browser (or via Playwright MCP)\n3. Take screenshot: `pnpm phoenix screenshot -o ./render.png -w 2560 --height 1440`\n\n**Use cases:** visual regression testing, generating product images, debugging 3D renders",inspectState:"## Inspect: State\n\nGet the current editor runtime state as JSON via `pnpm phoenix inspect:state`.\n\n**Prerequisites:** same as screenshot (dev server running + browser open)\n\n**Options:**\n- `--output, -o` — Output file path (prints to stdout if omitted)\n- `--sections, -s` — Comma-separated: entities, navigation, validation (default: all)\n- `--pretty` — Pretty-print JSON (default: true)\n- `--port` — WebSocket server port (default: 3020)\n\n**Example:** `pnpm phoenix inspect:state -o ./state.json -s entities,navigation`\n\n**Lifecycle status:** Always included in response. Shows which systems are ready:\n- `domainLoaded` — domain data loaded\n- `domainContextReady` — domain context initialized (entities available)\n- `configuratorReady` — 3D configurator initialized\n- `sessionAuthenticated` — session service active\n- `editorMode` — editor mode enabled\n\n**Tips:** Use `--sections` to limit payload size. Pipe through `head`/`tail` for partial output (e.g., `pnpm phoenix inspect:state | head -50`).\n\n**Use cases:** AI agent context, debugging entity state, inspecting navigation/validation",inspectData:`## Inspect: Data
 
 Get the current editor context data as JSON via \`pnpm phoenix inspect:data\`.
 
@@ -71,10 +69,10 @@ Rendered appearance is a deliverable, not a side effect. Before presenting any p
 Inspect and report:
 
 1. Geometry. Every part rests on its support. Name where the product meets the ground and confirm its shadow and any selection indicator sit there too. Nothing floats, intersects, or protrudes. Scale and orientation are consistent between parts and match the stated dimensions. Each part is complete and present.
-2. Fidelity. The result matches the client's own photographs, renders, and drawings where supplied. Name any divergence.
-3. Response. Every configurable surface of every part reacts to its control, not only the parts you just changed.
-4. Density. Every decision the user must make is reachable without hunting, and no single property's options dominate the surface holding them.
-5. Loading. How long until a meaningful first frame, and whether anything indicates progress meanwhile.
+2. Response. Every configurable surface of every part reacts to its control, not only the parts you just changed.
+3. Loading. How long until a meaningful first frame, and whether anything indicates progress meanwhile.
+
+This covers what follows from the change you just made, in the state you are already in. Fidelity against the client's own material, the density of the controls, and every state you did not open belong to an independent reviewer, which the \`phoenix-create-configurator\` skill's Appearance review covers.
 
 Report defects you are deferring as defects. Do not call work done, verified, or complete while any of the above is unchecked or failing: say which, and recommend fixing now or later.
 

package/dist/application-spec/generate-application/code/templates/tsconfig.d.ts

@@ -1 +1,6 @@
+/**
+ * The project's TypeScript settings, generated to `.phoenix/tsconfig.json` and rewritten whenever they
+ * differ. Paths are relative to `.phoenix/`. The project's root `tsconfig.json` extends this file, and
+ * `phoenix check` uses it directly when the project has no root `tsconfig.json`.
+ */
 export declare const generateApplicationSpecTsconfig: () => string;

package/dist/application-spec/generate-application/code/templates/tsconfig.js

@@ -31,6 +31,6 @@ export const generateApplicationSpecTsconfig=()=>`{
 
     "paths": {}
   },
-  "include": ["src", ".phoenix", "prettier.config.js", "eslint.config.js", "./.phoenix/globals.d.ts"]
+  "include": ["../src", ".", "../prettier.config.js", "../eslint.config.js", "./globals.d.ts"]
 }
 `;

package/dist/application-spec/generate-application/code/templates/webhook-index.d.ts

@@ -1 +1,6 @@
-export declare const generateApplicationSpecWebhookIndex: () => string;
+/** Where the generated webhook entry takes its handler from. */
+export interface WebhookIndexOptions {
+    /** Whether the project has `src/webhooks/index.ts`; without it the entry holds the built-in webhook. */
+    readonly hasWebhookEntry: boolean;
+}
+export declare const generateApplicationSpecWebhookIndex: ({ hasWebhookEntry }: WebhookIndexOptions) => string;

package/dist/application-spec/generate-application/code/templates/webhook-index.js

@@ -1,7 +1,16 @@
-import{autoHeader as e}from"../common/file-headers.js";export const generateApplicationSpecWebhookIndex=()=>`${e("webhook.ts","Webhook entry point — imports builders (sets globalThis.phx.webhooks) then re-exports user handler.")}
+import{autoHeader as e}from"../common/file-headers.js";export const generateApplicationSpecWebhookIndex=({hasWebhookEntry:o})=>o?`${e("webhook.ts","Webhook entry point — imports builders (sets globalThis.phx.webhooks) then re-exports user handler.")}
 export * as builders from './webhook-builders.js'
 
 import implementation from '../src/webhooks/index.js'
 
 export const handler = implementation
+`:`${e("webhook.ts","Webhook entry point — imports builders (sets globalThis.phx.webhooks) then exports the built-in handler, because the project has no src/webhooks/index.ts.")}
+export * as builders from './webhook-builders.js'
+
+// A webhook needs at least one handler; anonymous auth stays inert until spec/application.yaml sets useAuthHook
+const authHandler = phx.webhooks.authHandlerBuilder
+  .withAnonymousHandler(async () => ({ success: true, data: {}, role: 'anonymous' }))
+  .build()
+
+export const handler = phx.webhooks.webhookBuilder.withAuthHook(authHandler).build()
 `;

package/dist/application-spec/generate-application/code/templates/webhooks-config.js

@@ -1,6 +1,5 @@
-import{generateEnvReader as e}from"../common/env-reader.js";import{autoHeader as r}from"../common/file-headers.js";let t={IS_DEV:{type:"bool",default:!1,devDefault:!0},ASSISTANT_STRICT_THREADS:{type:"bool",default:!1},AWS_S3_PUBLIC_RESOURCES_BUCKET:{type:"str",required:!0},AWS_S3_RESOURCES_REGION:{type:"str",required:!0},DEPLOYMENT_RESOURCES_PATH:{type:"str",default:"deployment-resources"}},o={CLERK_API_KEY:{type:"str",required:!0},FRONTEND_URL:{type:"str",required:!0},JWT_SECRET_BASE64:{type:"str",required:!0},OAUTH_PROVIDER_CLIENT_ID:{type:"str",required:!0},OAUTH_PROVIDER_CLIENT_SECRET:{type:"str",required:!0},OAUTH_PROVIDER_BASE_URL:{type:"str",required:!0},RESOURCES_URL:{type:"str",required:!0}};export const generateApplicationSpecWebhooksConfig=i=>{let n=i.infra.env?.webhook??{},R=i.appMetadata.useClerk?o:{},{imports:E,config:p}=e({...t,...R,...n}),_=E.length>0?`import { ${E.join(", ")} } from 'envalid'
-`:"";return`${r("webhooks.config.ts","Runtime environment config for the webhook server.")}
-${_}import { createEnvReader } from '@salsita-ai/sdk/common/env'
+import{generateEnvReader as e}from"../common/env-reader.js";import{autoHeader as r}from"../common/file-headers.js";let t={IS_DEV:{type:"bool",default:!1,devDefault:!0},ASSISTANT_STRICT_THREADS:{type:"bool",default:!1},AWS_S3_PUBLIC_RESOURCES_BUCKET:{type:"str",required:!0},AWS_S3_RESOURCES_REGION:{type:"str",required:!0},DEPLOYMENT_RESOURCES_PATH:{type:"str",default:"deployment-resources"}},o={CLERK_API_KEY:{type:"str",required:!0},FRONTEND_URL:{type:"str",required:!0},JWT_SECRET_BASE64:{type:"str",required:!0},OAUTH_PROVIDER_CLIENT_ID:{type:"str",required:!0},OAUTH_PROVIDER_CLIENT_SECRET:{type:"str",required:!0},OAUTH_PROVIDER_BASE_URL:{type:"str",required:!0},RESOURCES_URL:{type:"str",required:!0}};export const generateApplicationSpecWebhooksConfig=i=>{let n=i.infra.env?.webhook??{},R=i.appMetadata.useClerk?o:{},{imports:E,config:p}=e({...t,...R,...n}),_=[...E,"createEnvReader"].sort();return`${r("webhooks.config.ts","Runtime environment config for the webhook server.")}
+import { ${_.join(", ")} } from '@salsita-ai/sdk/common/env'
 
 const readRuntimeConfig = createEnvReader(${p})