@unoverse-platform/studio 0.1.85 → 0.1.86

package/vendor/sdk/lib/transition/decide.ts

@@ -0,0 +1,53 @@
+/**
+ * The commit decision — the Transition Model's pure heart (UNOVERSE_TEMPLATE_MODEL §13).
+ *
+ * The mount double-buffers its arrangement and asks ONE question per render:
+ * may the committed arrangement change now? The answer depends only on the two
+ * arrangements — no store, no DOM, no time — so the contract is a pure function
+ * under conformance tests and can never regress silently.
+ *
+ * - "immediate":   commit with no ceremony (first paint; the guest's own
+ *                  navigation changed the layout; an un-directed mount — no
+ *                  verdict governs it, so its behaviour is exactly pre-contract).
+ * - "transition":  a BOUNDARY happened — the governing verdict changed (settle
+ *                  or clear) — commit as the one designed, animatable change.
+ * - "hold":        membership moved with no boundary (a data ripple). The shelf
+ *                  does not move. The caller owns the fail-open grace (§13.5).
+ * - "none":        nothing changed.
+ */
+
+export interface Arrangement {
+  /** The template's active layout (shape) name. */
+  layoutName: string | null;
+  /** Held pointers, in display order. */
+  held: string[];
+  /** Identity of the governing verdict (sorted held-pointer join), null when no
+   *  verdict governs — the un-directed mount. */
+  verdictSig: string | null;
+}
+
+export type CommitDecision = "immediate" | "transition" | "hold" | "none";
+
+const sameHeld = (a: string[], b: string[]) => a.length === b.length && a.every((p, i) => p === b[i]);
+
+/**
+ * `directed` = the placement grants a director, so every delivery WILL settle.
+ * A directed mount's membership therefore moves only at the settle — including
+ * the very first batch, whose cards arrive as separate messages before any
+ * verdict exists (committing each arrival painted the shelf in six pops, the
+ * first-appearance flicker observed live). Un-directed mounts keep committing
+ * immediately: no settle is ever coming for them.
+ */
+export function decideCommit(committed: Arrangement | null, next: Arrangement, directed: boolean): CommitDecision {
+  if (!committed) return "immediate";
+  // The guest's own navigation (name-sync layout change) is never held back.
+  if (next.layoutName !== committed.layoutName) return "immediate";
+  if (sameHeld(next.held, committed.held)) return "none";
+  // Membership moved. A changed governing verdict IS the boundary (settle/clear).
+  if (next.verdictSig !== committed.verdictSig) return "transition";
+  // Directed: the settle is coming — hold until it lands (grace fails open).
+  if (directed) return "hold";
+  // No verdict governs an un-directed mount: commit as it always did.
+  if (next.verdictSig === null) return "immediate";
+  return "hold";
+}

package/vendor/sdk/lib/transition/guestHold.ts

@@ -0,0 +1,34 @@
+/**
+ * THE GUEST'S HAND OUTRANKS THE DIRECTOR (UNOVERSE_TEMPLATE_MODEL §6b rule 3,
+ * state priority): a pointer whose LATEST write is the guest's own interaction,
+ * holding a non-base face the mount claims (an open Detail View), stays in the
+ * mount's scope regardless of deliveries and settles. Observed live without
+ * this: a new batch settled and yanked the guest out of an open detail page.
+ *
+ * The hold releases exactly as the model says: the guest's ✕ writes the face
+ * back to the base — no longer a non-base guest hold — and the current
+ * arrangement takes over. A re-delivered instance is an ARRIVAL (its merge
+ * out-touches the guest write) and may be re-faced, per §4 level 2.
+ *
+ * Pure over reads so the priority law is conformance-testable.
+ */
+
+export interface GuestHoldReads {
+  touchOf(p: string): number;
+  interactionTouchOf(p: string): number;
+  viewOf(p: string): string | undefined;
+}
+
+export function guestHeldPointers(
+  pointers: readonly string[],
+  reads: GuestHoldReads,
+  claimedLayouts: readonly string[],
+  baseLayout: string | null,
+): string[] {
+  return pointers.filter((p) => {
+    const it = reads.interactionTouchOf(p);
+    if (!it || it < reads.touchOf(p)) return false; // latest write is not the guest's
+    const v = reads.viewOf(p);
+    return !!v && v !== baseLayout && claimedLayouts.includes(v);
+  });
+}

package/vendor/sdk/lib/transition/index.ts

@@ -0,0 +1,9 @@
+/**
+ * The Transition Model (UNOVERSE_TEMPLATE_MODEL §13) — the render layer's
+ * designed way of moving interfaces in and out of a mounted template:
+ * `decide.ts` (the pure commit decision), `MountArrangement.tsx` (the
+ * double-buffer), `viewTransition.ts` (the theme-gated animated commit).
+ */
+export { decideCommit, type Arrangement, type CommitDecision } from "./decide";
+export { MountArrangement } from "./MountArrangement";
+export { commitArrangement } from "./viewTransition";

package/vendor/sdk/lib/transition/viewTransition.ts

@@ -0,0 +1,29 @@
+/**
+ * The commit IS the animation (UNOVERSE_TEMPLATE_MODEL §13.4): when the theme
+ * asks for motion, the boundary commit is wrapped in the browser's View
+ * Transitions API — the browser diffs old and new and animates; the THEME's CSS
+ * owns every duration and ease. The SDK contributes only this generic behaviour
+ * and NO styles. Engines without the API, and themes that author no motion, get
+ * the instant commit — today's behaviour, gracefully.
+ */
+
+import { flushSync } from "react-dom";
+
+type WithViewTransition = { startViewTransition?: (cb: () => void) => unknown };
+
+export function commitArrangement(commit: () => void, motion: boolean): void {
+  const doc = typeof document !== "undefined" ? (document as unknown as WithViewTransition) : undefined;
+  if (!motion || typeof doc?.startViewTransition !== "function") {
+    commit();
+    return;
+  }
+  // From a microtask, outside React's lifecycle, so flushSync is legal: the
+  // API snapshots, the commit flushes the new DOM, the browser animates.
+  queueMicrotask(() => {
+    try {
+      doc.startViewTransition!(() => flushSync(commit));
+    } catch {
+      commit(); // fail open — the change lands even if the ceremony breaks
+    }
+  });
+}

package/vendor/skills/unoverse-create/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: unoverse-create
-description: "Create or edit Unoverse platform artifacts: UI components (including briefed/AI-filled components), apps, atoms and styles (design/), brand and org packs (themes, tokens, rebranding, cloning a universe for a new client), agent skills and prompt blocks (prompts/), custom workflow nodes (nodes/), and workflows built live on the Canvas via the builder MCP. Use whenever the user wants to create, add, build, or modify a component, app, card, page, theme, brand, org pack, agent skill, prompt block, custom node, or workflow in an Unoverse project, even if they don't say 'Unoverse' (they'll describe UI like 'a card with a button and an image' or 'a page the AI fills in')."
+description: "Create or edit Unoverse platform artifacts: UI components (including briefed/AI-filled components), apps, templates (arrangements with open parts a delivery fills — shelf grids, emails, comparison pages), atoms and styles (design/), brand and org packs (themes, tokens, rebranding, cloning a universe for a new client), agent skills and prompt blocks (prompts/), custom workflow nodes (nodes/), and workflows built live on the Canvas via the builder MCP. Use whenever the user wants to create, add, build, or modify a component, app, card, page, theme, brand, org pack, agent skill, prompt block, custom node, or workflow in an Unoverse project, even if they don't say 'Unoverse' (they'll describe UI like 'a card with a button and an image' or 'a page the AI fills in')."
 ---
 
 # Creating Unoverse Artifacts
@@ -30,8 +30,10 @@ that is the workspace folder itself; in the platform monorepo it is `apps/unover
    ([components](https://github.com/unoverse-platform/marketplace/tree/main/definitions/components), [atoms](https://github.com/unoverse-platform/marketplace/tree/main/definitions/atoms), [styles](https://github.com/unoverse-platform/marketplace/tree/main/definitions/styles)).
    Study the closest exemplar there, then compose those atoms and reference those
    components; never hand-roll a shape the base already ships. Everything is plain
-   YAML files — no connection, no running platform needed. (In the platform monorepo
+   YAML files: no connection, no running platform needed. (In the platform monorepo
    the same material is on disk at `design/marketplace/`.)
+   [The design system](https://docs.unoverse.ai/design/design-system.md) is the guide to
+   what ships and how to use it.
 
 ## Step 1: Identify the artifact, read its playbook
 
@@ -42,6 +44,7 @@ anything**:
 |---|---|
 | A UI component or shared atom, incl. a page/card the AI fills with content (briefed) | `references/component.md` (§Briefs for AI-filled) |
 | An app (chat surface, wizard shell) | `references/app.md` |
+| A template: an arrangement with open parts a delivery fills (a shelf grid, an email, a comparison page) | `references/template.md` |
 | A style / theme / token change on ONE component | `references/component.md` §Tokens |
 | A brand: an org pack, a rebrand, a new client universe, cloning an org | `references/brand.md` |
 | An agent skill (behavior guide the AI follows) | `references/agent-skill.md` |
@@ -59,15 +62,18 @@ If it's ambiguous (e.g. "add a card that shows weather"), it's usually a **compo
 **New to design artifacts?** The guided learning journey at
 [docs.unoverse.ai/design](https://docs.unoverse.ai/design/overview.md)
 ([quick-start](https://docs.unoverse.ai/design/quick-start.md) →
+[essentials](https://docs.unoverse.ai/design/essentials.md) →
+[interface-data](https://docs.unoverse.ai/design/interface-data.md) →
 [components](https://docs.unoverse.ai/design/components.md) →
 [state](https://docs.unoverse.ai/design/state.md) →
+[templates](https://docs.unoverse.ai/design/templates.md) →
 [apps](https://docs.unoverse.ai/design/apps.md) →
 [styles-and-tokens](https://docs.unoverse.ai/design/styles-and-tokens.md) →
 [studio](https://docs.unoverse.ai/design/studio.md) →
 [validate-and-ship](https://docs.unoverse.ai/design/validate-and-ship.md) →
-[troubleshooting](https://docs.unoverse.ai/design/troubleshooting.md)) teaches
-components, apps, the state model (incl. locked voice/native state), tokens,
-Studio, and validation in order;
+[troubleshooting](https://docs.unoverse.ai/design/troubleshooting.md)) teaches the
+shared grammar every artifact uses, the four kinds, the state model (incl. locked
+voice/native state), tokens, **studio**, and validation in order;
 [design/CLAUDE.md](https://docs.unoverse.ai/design/CLAUDE.md) is the condensed agent
 rulebook. The playbooks here assume that material. Append `.md` to any docs URL to
 fetch it as raw markdown.

package/vendor/skills/unoverse-create/references/app.md

@@ -16,15 +16,16 @@ already in the workspace. (Monorepo: `design/sab/apps/sab-chat`.)
 A component is a state tree whose public states are its whole interface; an app
 declares its OWN state tree in the manifest and reacts to components by name:
 
-> A component enters a public view → the app asks "do I have a state with that
+> A component enters a public state → the app asks "do I have a state with that
 > name?" Match: the app enters that state and its layout draws. No match: the
 > component renders inline in the flow. Always.
 
 Derived off the store, never stored, no wiring. The component never knows apps
 exist, and post-spawn the app NEVER writes a component's state. Name-match is the
-default convention (`reactsTo:` on an app state is the rare escape hatch for
-vocabulary mismatches). **Rule of thumb: component causes it = a reaction state;
-app knows it = a base substate or app state.**
+ONLY mechanism: an app state reacts because its name matches, so give the app the
+name the component writes. (`reactsTo:` is DESIGN-ONLY: nothing in the runtime
+reads it, so never author it.) **Rule of thumb: component causes it = a reaction
+state; app knows it = a base substate or app state.**
 
 ## The manifest states tree: one declaration, everything follows
 
@@ -33,13 +34,21 @@ The canonical shape (a chat layout: a base arrangement plus a reaction ladder):
 ```yaml
 states:
   main:                 # the base arrangement, FIRST
+    layout: layouts/main
     states:
-      welcome: {}       # contained substate; first substate = the landing default
-  focus: {}             # then the reaction ladder, in priority order
-  products: {}
-  detail: {}
+      welcome:          # contained substate; first substate = the landing default
+        layout: layouts/main-welcome
+  focus:                # then the reaction ladder, in priority order
+    layout: layouts/focus
+  products:
+    layout: layouts/products
+  detail:
+    layout: layouts/detail
 ```
 
+Every state DECLARES its drawing as a path relative to the app folder (2026-08-29
+ruling): no same-name default, no assumed folder, `{}` is not a complete state.
+
 - **Top-level order IS the priority ladder**, base first. The app can be in ONE
   state at a time: it walks the list top-down and enters the first of its states that
   ANY hosted component currently matches. The ladder is DERIVED from the tree; never
@@ -59,19 +68,22 @@ states:
 - **A higher state CANCELS the claims below it**: while active, hosted components in
   lower-ranked states retract to inline (durable `lifetime: "conversation"` slices opt
   out), so releasing it lands on the BASE arrangement, never a stale lower one.
-- Ties (two components in the same view): most recent write wins (`limit: 1`).
+- Ties (two components in the same state): most recent write wins (`limit: 1`).
 - **No word is special.** `focus` outranks `products` by list position only; the engine
   matches names and walks the list. Even priority is data.
 - The app's own condition-guarded moods (a welcome hero on an empty conversation)
   are private substates of the base, never ladder entries: the app does not
   rearrange between them.
 
-## The anatomy: manifest-only (NO `<name>.yaml` envelope)
+## The anatomy: ONE FOLDER GRAMMAR (2026-08-29 — apps match components/templates)
 
 ```
 design/<project>/apps/<name>/
-  manifest.yaml    # THE ENVELOPE: the whole app contract, incl. the states tree
-  layouts/         # the ARRANGEMENTS: one per state that owns one (same-name default)
+  <name>.yaml      # THE ENVELOPE: type: app + the states tree (what the app IS);
+                   #   each state declares its layout path and carries its preview
+  manifest.yaml    # THE MCP FACE: description/whenToUse/inputSchema/binding/
+                   #   makeMCP/assetDomains — how the outside finds and calls it
+  layouts/         # the ARRANGEMENTS: one per state, each DECLARED by path in the tree
     main.yaml      #   the base: the core alone
     products.yaml  #   state "products" → core + cards rail
     detail.yaml    #   state "detail"  → core + full record page
@@ -84,7 +96,7 @@ design/<project>/apps/<name>/
 Each layout = a complete arrangement: `$include: components/core` + that state's
 surface. Shared chrome lives ONCE in `components/`; every layout includes it. The tree
 claims the instance, the layout's surface renders it: a reaction state's layout holds a
-ComponentSlot selecting the matching view.
+ComponentSlot selecting the matching state.
 
 ## manifest.yaml (the app contract)
 
@@ -121,27 +133,29 @@ ComponentSlot. Lint-enforced:
 ## Surfaces: apps REACT, they never own
 
 One instance → one placeholder: the flow is the placeholder for `inline`; a reaction
-state's layout (via its inner surface) is the placeholder for a matched view. The SDK
+state's layout (via its inner surface) is the placeholder for a matched state. The SDK
 keeps a claimed instance out of the flow; never hide a flow copy yourself.
 
 - **Flow slot**: `{ type: ComponentSlot, select: {} }`, always present.
-- **Reaction surface**: select by the public `view`, never by type/id:
+- **Reaction surface**: select by the public `state`, never by type/id:
   ```yaml
   type: ComponentSlot
   appWidth: panel
   select:
     from: all
-    where: { field: view, eq: detail }
+    where:
+      field: state
+      eq: page
     limit: 1
   frame:  # chrome; an inner bare ComponentSlot marks the placement
   ```
-  ❌ `select: { type: [...] }`, ❌ `where.field` ≠ `view`, ❌ app chrome
-  writing a component's slice, all lint-flagged. (`defaultState` as the select field
-  is the v1 legacy spelling.)
+  ❌ `select: { type: [...] }`, ❌ `where.field` ≠ `state`, ❌ app chrome
+  writing a component's slice, all lint-flagged. (`view` and `defaultState` are the
+  legacy spellings of the select field.)
 - **Input tools are app chrome** (unchanged rule): a composer, an edit form, a
   picker is owned by the app, never a streamed component state; chrome never
   "arrives". A card's Edit stages its data into the app's one input tool.
-- **App state** (`setTemplateValue`) is ONLY for the app's own chrome (a
+- **App state** (`setAppValue`) is ONLY for the app's own chrome (a
   disclosure, the composer `draft`). "Is something focused" is DERIVED, never stored.
 - **Chrome reacts via `surfacedView`** (SDK-projected active view name, `""` = all
   inline): `visibleWhen { field: surfacedView, in: ["", "products"] }`.
@@ -180,5 +194,5 @@ whole, see brand.md). Addresses: apps
 4. **See it**: in Studio, the state switcher reads the tree (base first, ladder order),
    base substates beneath, freely combinable; acting inside the preview transitions
    like the runtime. Then run it live: the bound workflow streams components, a card
-   entering a public view walks the ladder and rearranges the app end-to-end,
+   entering a public state walks the ladder and rearranges the app end-to-end,
    and its ✕ hands the lower state back.

package/vendor/skills/unoverse-create/references/component.md

@@ -16,10 +16,11 @@ folder shape. (In the platform monorepo the richest multi-state exemplar is on d
 
 ```
 design/<project>/components/<name>/
-  <name>.yaml      # ROOT: envelope (name/category/nodeSize/outputs/props) + the STATE TREE + root
+  <name>.yaml      # the envelope: name/category/nodeSize/outputs/props + `states:` + `values:` (root only as a real shell)
   manifest.yaml    # RENDER CONTRACT + discovery meta (title / description ≤120 /
-                   #   whenToUse utterance-shaped). Presence = spatially discoverable;
-                   #   the envelope NEVER duplicates the meta.
+                   #   whenToUse utterance-shaped). REQUIRED on every artifact EXCEPT
+                   #   a flat file nothing discovers (2026-08-30); the envelope NEVER
+                   #   duplicates the meta.
   layouts/         # the DRAWINGS: one file per state that owns an arrangement
   components/      # component-local shared partials (earned: 2+ layouts share a shape)
 ```
@@ -32,14 +33,14 @@ manifest, no folders. Structure is EARNED; start flat.
 A component is **data plus a state tree**; each state owns the layout(s) that draw it.
 The root's `state:` block IS the design, readable top to bottom.
 
-> **THE GATE — answer this before adding ANY state to `view`:**
+> **THE GATE, answer this before adding ANY state to the tree:**
 > *"Would a hosting app rearrange the page to show this?"*
 > **No → it's a private step**: nest it under `on:` inside an existing public state.
 > **Yes → public.**
 > ⚠ "The user asked for N states" never means N public states. In-place swaps
 > (confirmation, success, empty, error, loading, a form's next step) are almost always
-> PRIVATE. Privacy is the default; promotion to `view` is a deliberate act with a
-> app consequence.
+> PRIVATE. Privacy is the default; promotion to a PUBLIC state is a deliberate act
+> with an app consequence.
 
 The canonical shape (a product-card component). Note where each state landed and why:
 `products` and `detail` are PUBLIC because an app genuinely rearranges for each (a
@@ -47,35 +48,30 @@ grid rail vs a full page); `detail`'s inner `detail`/`apply` are PRIVATE steps b
 applying swaps content in place — the page does not move:
 
 ```yaml
-state:
-  view:                      # the PUBLIC axis
-    initial: products
+states:                      # TOP LEVEL (2026-08-29), like every kind; the word is
+  products:                  #   `state` everywhere (setValue/Switch on/select field)
+    layout: layouts/products            # REQUIRED path: nothing assumed
+  detail:                               # the full page
+    layout: layouts/product
+    on: step                            # a PRIVATE axis: the steps inside detail
     states:
-      products: {}                          # no layout key: same-name default, {} is complete
-      detail:                               # the full page
-        layout: product                     # declared ONLY because the filename differs
-        on: step                            # a PRIVATE axis: the steps inside detail
-        initial: detail
-        states:
-          detail: { layout: product-detail }
-          apply:  { layout: product-apply }
-root:
-  type: Box
-  children:
-    - type: Switch
-      on: view                              # the root switches on `view`, ONE case active
-      cases:
-        products: { $include: layouts/products }
-        detail:   { $include: layouts/product }
+      detail: { layout: layouts/product-detail }
+      apply:  { layout: layouts/product-apply }
+values:                      # STARTING VALUES of keys the component writes (scalars)
+  progressPct: 10%
 ```
 
+**No `root`**: the compiler synthesizes the `Switch on state` from the tree. Author
+a root ONLY as a real shell (chrome beyond the plain Switch); a restated Switch is
+linted as redundant.
+
 The rules, in the order they bite:
 
-- **The axis is `view`.** The component's public state lives in its slice under `view`.
-  The root is a `Switch on view`; buttons transition with
-  `setValue { values: [{ key: view, value: detail }] }`. That write is the ENTIRE
+- **The word is `state`** (ruled 2026-08-29). The component's public state lives in
+  its slice under `state`. The root is a `Switch on state`; buttons transition with
+  `setValue { values: [{ key: state, value: detail }] }`. That write is the ENTIRE
   transition machinery: no guards, no events, no per-component machines.
-- **Public states are the top level of the `view` axis** and they are the app's
+- **Public states are the top level of `states:`** and they are the app's
   WHOLE vocabulary: everything apps can react to, nothing more. Steps nest
   privately (`on: <key>` + `initial` + `states`), invisible outside the component.
   The placement rule is THE GATE above: **if the app must rearrange to show it,
@@ -84,11 +80,11 @@ The rules, in the order they bite:
   **The tell in Studio:** non-initial public states preview FULL-BLEED (no stage
   padding), precisely because they are app-liftable surfaces. If a state you
   meant as an in-place swap suddenly renders edge-to-edge, you promoted a private
-  step to `view` — move it into the nest.
-- **Each state owns its layout(s).** `layout:` is OPTIONAL: a state with no declaration
-  draws the layout of its own name, and `{}` is a complete state. Write `layout:` only
-  when the filename differs. A layout is never addressable on its own; only its owning
-  state selects it. Name states for what they MEAN (`detail`), never for their drawing. **Substate drawings are axis-prefixed**: a step's file carries its axis key
+  step to the public menu — move it into the nest.
+- **Each state owns its layout(s), DECLARED as a path** (`layout: layouts/<file>`,
+  REQUIRED — 2026-08-29; no same-name default, `{}` is not complete; the one
+  exception is a FLAT component with no layouts/ folder). A layout is never
+  addressable on its own; only its owning state selects it. Name states for what they MEAN (`detail`), never for their drawing. **Substate drawings are axis-prefixed**: a step's file carries its axis key
   (`step-register`, `callState-idle`) and is declared via `layout:`; unprefixed
   files are arrangements (exemplars: `course-application`, `voice-chat`).
 - **Shell vs steps.** A state's own layout is its SHELL, always on while the state is
@@ -106,20 +102,20 @@ The rules, in the order they bite:
   inline. The server compiles the tree to the public menu + initials it serves
   (`publicStates`, `initialView`). Post-spawn, the app NEVER writes a component's
   state.
-- **Unmatched view = inline. Always.** An ignored public state does not stay put, it
+- **Unmatched state = inline. Always.** An ignored public state does not stay put, it
   FALLS INLINE in the flow. A step that must never move the page belongs in the nest,
   not on the public menu.
-- Legacy: v1's `defaultState` field and layout-name-sync are superseded; the SDK reads
-  `defaultState` only as a migration alias for `view`. New authoring writes `view`.
+- Legacy: `view` (the v2 intermediate) and v1's `defaultState` are read-only
+  aliases; layout-name-sync is superseded. New authoring writes `state`.
 
 ## The rules (Studio's publish lint enforces all of these; 0 errors required)
 
 1. **Three homes for everything it shows** (AUTHORING §3):
    - static content → **hardcoded literals** in the layout (`value`, literal `items: []` on
      Each, `src`), never props, never `state`;
-   - internal view-state → the **`state` block, SCALARS ONLY** (`step`, `phase`,
-     `progressPct`): an array/object/URL in `state` is slop (workflow data → props;
-     static → hardcode);
+   - starting values of keys it writes → the **`values:` block, SCALARS ONLY**
+     (`step`, `phase`, `progressPct`; `state:` scalars = legacy): an array/object/URL
+     there is slop (workflow data → props; static → hardcode);
    - workflow-fed data → **`props` with `input: true`** (the `default` is the preview mock).
      Usually empty.
    - **Projected-field preview rule:** any LOCKED/projected field a
@@ -127,7 +123,7 @@ The rules, in the order they bite:
      a prop with a preview default: Studio's bare component preview supplies ONLY prop
      defaults, so an undeclared projected read renders NOTHING there; live, the projected
      value wins and the default never applies. A Ref-embedded component's root Switch
-     likewise needs a `default:` case (`view` is absent without a spawned slice).
+     likewise needs a `default:` case (`state` is absent without a spawned slice).
    - **Who owns a mood: the DRIVER decides.** Ask what WRITES the discriminant:
      (1) the component's own buttons (`setValue`) → component substates on a private axis,
      names from the design (`course-application`); (2) a service projecting a NAMED value
@@ -143,12 +139,15 @@ The rules, in the order they bite:
    - **Prop names = the data contract. Never invent them.** Source data hydrates props
      BY NAME (as-is, no mapping); a name the source doesn't carry silently renders the
      preview default (tell: title streams, image stays mock). Content-attached cards use
-     the writer vocabulary: `title` `tagline` `description` `bodyCopy` `introParagraph`
-     `primaryImage` `images` `link` `callToAction`. Law:
+     the writer vocabulary, listed layer by layer in
+     [design/interface-data](https://docs.unoverse.ai/design/interface-data.md)
+     (`title` `tagline` `description` `bodyCopy` `primaryImage` `images` …). Law:
      `UNOVERSE_MCP_APP_PROTOCOL.md` §Content-attached cards (platform spec; a
      guard test in the platform server enforces it).
-2. **Root = `Switch on view`**, cases per PUBLIC state, each `$include` of the state's
-   layout (the tree above). Keep an `inline` state for any component that lives in a
+2. **NO root: the compiler synthesizes the `Switch on state`** from `states:` (the tree
+   above), so a hand-written root that merely restates the tree is lint-flagged as
+   redundant. Author a `root:` ONLY for real always-on chrome beyond that Switch.
+   Keep an `inline` state for any component that lives in a
    conversation flow: the flow is its placeholder there. One EXCEPTION is the
    **single-state (permanent) component**: exactly ONE public state, NO inline. It
    arrives in its surface, cannot leave it (no ✕, no other state), and is enriched in
@@ -164,14 +163,14 @@ The rules, in the order they bite:
    takes over. Default `"turn"`: the instance returns to inline / retires on the next
    user turn. Values are a closed set: `turn | conversation` (lint-checked;
    [design/components](https://docs.unoverse.ai/design/components.md)).
-3. **State is local; the `view` is the interface** (STATE_MODEL §5). Private axes
+3. **Private state is local; the public `state` is the interface** (STATE_MODEL §5). Private axes
    (`step`, `phase`, …) are the component's own business; the app never sees them.
-   The only thing that crosses is the public `view`. The component writes ONLY its own
-   slice (`setValue`): expand = `setValue { view: "detail" }`; its expanded layout
+   The only thing that crosses is the public `state`. The component writes ONLY its own
+   slice (`setValue`): expand = `setValue { state: "page" }`; its expanded layout
    carries its own ✕ back down. When a hosting app has a state of that name, the
    instance **lifts out of the flow into that state's slot**. The SDK renders each
    instance in exactly ONE placeholder, so you never hide a flow copy yourself (no
-   `hideBelow`, no overlay hack). ❌ NEVER `setTemplateValue` to open a surface
+   `hideBelow`, no overlay hack). ❌ NEVER `setAppValue` to open a surface
    (the deprecated bridge, linted). ❌ Never guard a layout against its own state:
    the tree owns "which state is active"; a layout re-checking its discriminant is
    the double-guard smell the model removes.
@@ -182,7 +181,7 @@ The rules, in the order they bite:
 5. **Atoms** (the base design system's shared shapes, used via `Ref`; browse them at
    [marketplace/definitions/atoms](https://github.com/unoverse-platform/marketplace/tree/main/definitions/atoms), or on disk at `design/marketplace/atoms/` in the
    platform monorepo) are for shapes shared across components, authoring-time
-   only (the server expands them before serving; no Studio view). `Ref props` remaps FIELDS;
+   only (the server expands them before serving; no Studio entry). `Ref props` remaps FIELDS;
    **`Ref with` passes LITERALS**: `{ "type": "Ref", "ref": "button", "with": { "label":
    "Learn more", "icon": "arrowRight" }, "action": { … } }`. A bind whose field is a `with`
    key becomes a hardcoded attribute, a truthy `with` key drops a matching `visibleWhen`
@@ -225,7 +224,7 @@ The rules, in the order they bite:
      `onEnterView` only. Omit it and every state fires.
    - **Name the handler for what it DOES, never for the phase** (`fetchPlaceDetails`, not
      `onEnterView`): the phase already said the moment.
-   - **Nothing to wire up.** A component changing its own view writes `view`, and that
+   - **Nothing to wire up.** A component changing its own face writes `state`, and that
      write IS the event the hook reacts to. No signal to author, no action to chain.
    - **Prefer a platform-ready handler.** `getDetail` (zero code) reads the instance's
      `universal_id` and merges the stored record's fields in by name, so authored copy
@@ -311,9 +310,11 @@ component. Its key nouns/verbs must appear in `whenToUse`'s first sentence.
 1. Study the closest published exemplar ([marketplace/definitions/components](https://github.com/unoverse-platform/marketplace/tree/main/definitions/components);
    monorepo: `design/sab/components/product-card`); copy its folder shape.
 2. Declare the state tree first: public states on top, steps nested, each state owning
-   its layout (same-name default, `layout:` only when the filename differs).
-3. Write the envelope + manifest + layouts; root = `Switch on view`; every shown thing
-   in its ONE home; transitions are `setValue` writes to `view` (or a private axis).
+   its layout as a root-relative path (`layout: layouts/<file>`, required; a FLAT
+   component with no layouts/ folder declares face-only states with no layout).
+3. Write the envelope + manifest + layouts; the root is synthesized from `states:`; every
+   shown thing in its ONE home; transitions are `setValue` writes to `state` (or a private
+   axis).
 4. Publish from Studio; its lint must report 0 errors (the rules are v2-aware and cite
    the doc for every rule).
 5. Restart unoverse → Studio: mock (prop defaults + the state switcher reads the tree:

package/vendor/skills/unoverse-create/references/node.md

@@ -5,7 +5,9 @@
 1. [nodes/CLAUDE.md](https://docs.unoverse.ai/nodes/CLAUDE.md): the authoritative agent
    guide. The folder, the eight non-negotiable rules, every file with an example, and
    the lint-error-to-fix table.
-2. [nodes/manifest-nodes](https://docs.unoverse.ai/nodes/manifest-nodes.md): the format in full, including the run context.
+2. [nodes/manifest-nodes](https://docs.unoverse.ai/nodes/manifest-nodes.md): the format in full.
+   [nodes/expressions](https://docs.unoverse.ai/nodes/expressions.md) is the template and
+   expression grammar, the sandbox, and every root the run context carries.
 3. [nodes/node-discoverability](https://docs.unoverse.ai/nodes/node-discoverability.md): **read before writing `whenToUse`**.
 4. As needed: [credentials](https://docs.unoverse.ai/nodes/credentials.md),
    [who-can-run-it](https://docs.unoverse.ai/nodes/who-can-run-it.md),