@unoverse-platform/studio 0.1.45 → 0.1.47

package/vendor/sdk/lib/primitives.tsx

@@ -247,7 +247,7 @@ function useTextSelection(enabled: boolean) {
  * (childList change) OR streaming text (a child resizing) — but only while the user is
  * already near the bottom, so scrolling up to read history is never yanked back down.
  * NOT chat-specific: any `overflow:auto` Box can opt in. The SDK owns behaviour, never
- * styles — the scroll container itself is defined in `rx/` (the conversation state box).
+ * styles — the scroll container itself is defined in `design/` (the conversation state box).
  */
 function useAutoScrollToEnd(enabled: boolean) {
   const ref = useRef<HTMLDivElement | null>(null);
@@ -281,11 +281,11 @@ function useAutoScrollToEnd(enabled: boolean) {
 /**
  * Generic "sticky bar that reveals only once you've scrolled past the element before it"
  * (opt-in via `node.revealOnStick`). Pins the bar at the top (its own `position: sticky`
- * + `top` in `rx/`) and, using an IntersectionObserver on the bar's PREVIOUS sibling as
+ * + `top` in `design/`) and, using an IntersectionObserver on the bar's PREVIOUS sibling as
  * the sentinel (e.g. a hero image), keeps it hidden while that sibling is on screen and
  * fades it in once the sibling scrolls away. A negative margin removes the bar's flow
  * footprint so it OVERLAYS the content (no gap at the top). NOT card-specific: any sticky
- * bar can opt in. The SDK owns behaviour, never styles — the bar's look lives in `rx/`.
+ * bar can opt in. The SDK owns behaviour, never styles — the bar's look lives in `design/`.
  */
 function useRevealWhenStuck(enabled: boolean) {
   const ref = useRef<HTMLDivElement | null>(null);
@@ -415,7 +415,7 @@ export function IconView({ name, style, theme }: { name?: string; style?: Record
 
 /**
  * `Skeleton` — built-in loading placeholder. ALL dimensions are DATA, fetched
- * from the theme (theme.skeleton ← rx/styles/semantic/skeleton.json). The SDK
+ * from the theme (theme.skeleton ← design/styles/semantic/skeleton.json). The SDK
  * authors nothing here but structure (flex/full). `bars` are 'width height' pairs.
  */
 export function SkeletonView({ variant = "text", theme }: { variant?: string; theme: ResolvedTheme }): ReactNode {
@@ -680,9 +680,9 @@ export function InputView({ node, data, theme, onAction }: { node: UnoverseNode;
  * markdown-to-jsx overrides for the `Markdown` primitive.
  *
  * ⛔ AUTHORS ZERO STYLE VALUES. Every element style is read verbatim from the
- *    SERVED prose recipe (`theme.prose` ← rx/styles/semantic/prose.json). The SDK
+ *    SERVED prose recipe (`theme.prose` ← design/styles/semantic/prose.json). The SDK
  *    only maps element → recipe key and supplies BEHAVIOUR (target=_blank, image
- *    error-fallback). No hex, no px/rem, no weights here — they live in rx/.
+ *    error-fallback). No hex, no px/rem, no weights here — they live in design/.
  *
  * Built once per theme (stable component identities so streaming re-renders don't
  * remount images and drop their broken-state).
@@ -734,7 +734,7 @@ function buildMarkdownOverrides(theme: ResolvedTheme, inheritLinkColor = false)
     // INLINE MARKS and BLOCKS. Authored copy uses all of these (a bolded access code, a
     // rule between sections, a quoted term), and an element absent from this map renders
     // at the browser's default — the one place a definition's look escapes the token
-    // layer. Each maps to a served recipe key; the VALUES live in rx/styles/semantic/prose.
+    // layer. Each maps to a served recipe key; the VALUES live in design/styles/semantic/prose.
     strong: { props: { style: s("strong") } },
     em: { props: { style: s("emphasis") } },
     del: { props: { style: s("strikethrough") } },

package/vendor/sdk/lib/render.tsx

@@ -12,7 +12,7 @@
  *  `Button` (and its styling logic) kept leaking back into the dispatcher.
  *
  *  THE FRAMEWORK IN ONE SENTENCE: this SDK is a FIXED, GENERIC interpreter. ALL
- *  UX is built in DATA (rx/ definitions + the served theme) — an author creates
+ *  UX is built in DATA (design/ definitions + the served theme) — an author creates
  *  ANY interface WITHOUT editing this SDK. (See FRAMEWORK.md.)
  *
  *  WHERE THINGS LIVE:
@@ -30,7 +30,7 @@
  *
  *  Need something the vocab can't express? Prefer extending the generic interpreter
  *  ONCE (a new style-vocab key in ./style, a new model projection) over a primitive.
- *  You almost never need to touch this file — build it in rx/ first.
+ *  You almost never need to touch this file — build it in design/ first.
  * ════════════════════════════════════════════════════════════════════════════
  */
 import type { ReactNode } from "react";

package/vendor/sdk/lib/style.ts

@@ -1,7 +1,7 @@
 /**
  * The style + animation INTERPRETER — neutral vocab → CSS, resolving token NAMES
  * against a theme FETCHED from the server. ⛔ OWNS ZERO STYLE VALUES (no hex, no
- * px/rem/em, no recipes); every value lives in rx/styles and is served. See
+ * px/rem/em, no recipes); every value lives in design/styles and is served. See
  * FRAMEWORK.md and render.tsx's header. Enforced by test/golden-rule.test.mjs.
  */
 import type { CSSProperties } from "react";
@@ -227,10 +227,10 @@ export function cssDecls(css: CSSProperties, important = false): string {
 }
 
 /**
- * Serialize the SERVED keyframes (theme.keyframes ← rx/styles/semantic/keyframes.json)
+ * Serialize the SERVED keyframes (theme.keyframes ← design/styles/semantic/keyframes.json)
  * into a CSS string, injected ONCE per render root (<style>). This authors zero values —
  * it only structures DATA into `@keyframes uno-<name>{ <stop>{ <prop>:<val> } }`. Adding a
- * new animation = adding a keyframe to rx/ + a `style.animation` ref in a definition. No
+ * new animation = adding a keyframe to design/ + a `style.animation` ref in a definition. No
  * SDK edit, no new primitive. Keyframe decls use real CSS prop names, KEBAB-CASE
  * (`box-shadow`, never `boxShadow`) — that is the canonical authored form, lint-enforced.
  * Property keys are still kebab-normalized here, exactly as Studio's gallery serializer

package/vendor/sdk/lib/template.tsx

@@ -179,7 +179,7 @@ export function StreamedUnoverseTemplate({ client, store, uri, onAction, theme:
    * THE LATCH, PUBLISHED FOR CHROME (docs/MCP_COMPLETE_GUIDE.md §The Component Latch).
    *
    * `resolveLatch` derives WHICH instance the conversation addresses; the composer's pill
-   * is ordinary rx chrome, so it needs those facts as template state to bind against. Same
+   * is ordinary design chrome, so it needs those facts as template state to bind against. Same
    * shape as the voice service (§4 "services feed the state"): a producer writes derived
    * values into the normal bucket, and `core` learns no UI concept — nothing here knows a
    * pill exists.
@@ -328,7 +328,7 @@ export function StreamedUnoverseTemplate({ client, store, uri, onAction, theme:
 
   // Timeline — GENERIC iterator. Walks the timeline and renders the `user` / `assistant`
   // DATA sub-tree per turn. Zero chat UX in the SDK: bubbles, alignment, structure all live
-  // in those sub-trees (rx/templates/chatlayout/*.json). The assistant sub-tree's ComponentSlot
+  // in those sub-trees (design/templates/chatlayout/*.json). The assistant sub-tree's ComponentSlot
   // is scoped to THAT turn's components.
   const resolveTimeline = (node: UnoverseNode, key?: React.Key): ReactNode => {
     return (

package/vendor/sdk/lib/theme.ts

@@ -2,8 +2,8 @@
  * useUnoverseTheme — fetch the RESOLVED theme from the MCP server by name.
  *
  * The SDK owns ZERO token values. The server owns the visual (apps/unoverse/
- * rx/styles, resolved live) and serves it at `unoverse://theme/{name}`; this hook
- * fetches it (cached in the client). A brand change in rx/styles is refresh-only
+ * design/styles, resolved live) and serves it at `unoverse://theme/{name}`; this hook
+ * fetches it (cached in the client). A brand change in design/styles is refresh-only
  * — there is no baked theme in this bundle to rebuild (UNOVERSE_SPEC §2d-1).
  */
 import { useEffect, useState } from "react";

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

@@ -1,18 +1,35 @@
 ---
 name: unoverse-create
-description: Create or edit Unoverse platform artifacts: UI components (including briefed/AI-filled components), templates, atoms and styles (rx/), 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 when the user wants to create, add, build, or modify a component, template, theme, brand, org pack, agent skill, prompt block, custom node, or workflow in an Unoverse starter repo.
+description: "Create or edit Unoverse platform artifacts: UI components (including briefed/AI-filled components), templates, 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, template, 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
 
-You are helping a developer build in the **Unoverse developer carve-out**, the three
-editable folders mounted into the running platform:
+You are helping a developer build in an Unoverse project: the three editable folders
+the platform reads.
 
 | Folder | What lives there |
 |---|---|
-| `apps/unoverse/rx/` | **Design** (data, not code): components, atoms, org-scoped templates + styles |
-| `apps/unoverse/prompts/` | **Behavior**: agent skills (`skills/`) + prompt blocks (`blocks/`) |
-| `apps/unoverse/nodes/` | **Logic**: custom workflow nodes, authored as YAML |
+| `design/` | **Design** (data, not code): per-project components, templates + styles; each project is `design/<project>/` |
+| `prompts/` | **Behavior**: agent skills (`skills/`) + prompt blocks (`blocks/`) |
+| `nodes/` | **Logic**: custom workflow nodes, authored as YAML |
+
+Paths in this skill are relative to the project root. In a Studio developer workspace
+that is the workspace folder itself; in the platform monorepo it is `apps/unoverse/`.
+
+## Step 0: Anchor in the project before writing
+
+1. **Pick the right `design/<project>/`.** Every design artifact belongs to a project (an
+   "org"). If the workspace has more than one, or the only one looks like a placeholder,
+   ask which project the artifact belongs to. Never invent a new project folder to hold
+   one artifact.
+2. **The design system is installed, not on disk.** A developer workspace holds only the
+   developer's own projects; the marketplace design system (shared atoms, components,
+   the token foundation) resolves from the installed platform. See it through Studio's
+   authoring MCP: `listDefinitions` (kind `atom` / `component`, org `marketplace`),
+   `readDefinition` for a full definition, `getVocabulary` for the closed node/style
+   vocabulary. Compose those atoms; never hand-roll a shape the design system already
+   ships. (In the platform monorepo the same material is on disk at `design/marketplace/`.)
 
 ## Step 1: Identify the artifact, read its playbook
 
@@ -31,40 +48,54 @@ anything**:
 | A workflow (wire nodes into an agent/pipeline on the Canvas) | `references/workflow.md` |
 
 Workflows are the one artifact that is NOT files: they are built live on the running
-platform through the `canvas` MCP (registered by this repo's `.mcp.json`).
+platform through the `canvas` MCP (registered by the project's `.mcp.json`).
 The playbook covers the bind/build/test contract.
 
 If it's ambiguous (e.g. "add a card that shows weather"), it's usually a **component**
 (the UI) plus possibly a **node** (the data source). Confirm the scope with the user.
 
-**New to design artifacts?** The guided learning journey at `docs/design/` (README →
-quick-start → … → troubleshooting) teaches components, templates, the state model
-(incl. locked voice/native state), tokens, Studio, and validation in order;
-`docs/design/CLAUDE.md` is the condensed agent rulebook. The playbooks here assume that
-material.
+**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) →
+[components](https://docs.unoverse.ai/design/components.md) →
+[state](https://docs.unoverse.ai/design/state.md) →
+[templates](https://docs.unoverse.ai/design/templates.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, templates, 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.
 
 ## Step 2: Hard rules (apply to every artifact)
 
-1. **Only edit the three carve-out folders.** Never touch, vendor, or work around the
+1. **Only edit the three project folders.** Never touch, vendor, or work around the
    SDK, engine, or server. They are not yours to change. If a task seems to require an
    SDK change, the answer is almost always "express it as data". Re-read the playbook.
 2. **Docs are the source of truth.** The playbooks name the design journey and the deep
-   references ([UNOVERSE_AUTHORING](https://github.com/unoverse-platform/docs/blob/main/unoverse/UNOVERSE_AUTHORING.md), [UNOVERSE_STATE_MODEL](https://github.com/unoverse-platform/docs/blob/main/unoverse/UNOVERSE_STATE_MODEL.md), [UNOVERSE_LAYERS](https://github.com/unoverse-platform/docs/blob/main/unoverse/UNOVERSE_LAYERS.md),
-   [UNOVERSE_CONFORMANCE](https://github.com/unoverse-platform/docs/blob/main/unoverse/UNOVERSE_CONFORMANCE.md)). They live in the docs repo
-   (https://github.com/unoverse-platform/docs), not in your repo. When the user's request goes beyond the playbook, read the named section rather
-   than improvising conventions.
+   references ([UNOVERSE_AUTHORING](https://docs.unoverse.ai/unoverse/UNOVERSE_AUTHORING.md),
+   [UNOVERSE_STATE_MODEL](https://docs.unoverse.ai/unoverse/UNOVERSE_STATE_MODEL.md),
+   [UNOVERSE_LAYERS](https://docs.unoverse.ai/unoverse/UNOVERSE_LAYERS.md),
+   [UNOVERSE_CONFORMANCE](https://docs.unoverse.ai/unoverse/UNOVERSE_CONFORMANCE.md)),
+   all served at docs.unoverse.ai. When the user's request goes beyond the playbook,
+   read the named section rather than improvising conventions.
 3. **UI is data.** No pixels, hex colors, or CSS anywhere: token names only. No logic
    in definitions: anything computed (totals, formatting, chosen colors) is computed in
    the node and sent as a plain field.
 4. **Audit before you're done.** Every component/template must pass the conformance
-   checklist ([UNOVERSE_AUTHORING](https://github.com/unoverse-platform/docs/blob/main/unoverse/UNOVERSE_AUTHORING.md) §9). Walk it item by item.
+   checklist ([UNOVERSE_AUTHORING](https://docs.unoverse.ai/unoverse/UNOVERSE_AUTHORING.md) §9).
+   Walk it item by item.
 5. **Discovery meta is ranked, not read.** Any spatially-discoverable artifact (a
    component or template with a manifest, an agent skill, a node) is selected by
    embedding `title`/`name` + `whenToUse`/`description` + `category` against the user's
    own words (or the planner's task). The strict contract is
-   `docs/nodes/node-discoverability.md`: outcome-first, utterance-shaped, opening
-   words dominate, disqualify by property (never name a sibling). Each playbook carries
-   the summary; read doc 14 before writing any meta.
+   [node-discoverability](https://docs.unoverse.ai/nodes/node-discoverability.md):
+   outcome-first, utterance-shaped, opening words dominate, disqualify by property
+   (never name a sibling). Each playbook carries the summary; read that page before
+   writing any meta.
 
 ## Step 3: Deploy loop (after the artifact is written)
 
@@ -72,18 +103,21 @@ Components and templates have NO scaffold command. Author them from the referenc
 (mirror the closest existing artifact). Validation lives in Studio: its publish step
 lints every definition before anything leaves the machine (0 errors required, doc-cited
 messages; justify any warning), and the conformance checklist is
-[UNOVERSE_CONFORMANCE](https://github.com/unoverse-platform/docs/blob/main/unoverse/UNOVERSE_CONFORMANCE.md).
+[UNOVERSE_CONFORMANCE](https://docs.unoverse.ai/unoverse/UNOVERSE_CONFORMANCE.md).
 
 | Artifact | To see it live |
 |---|---|
 | Component / atom / template / style | Preview in Studio (`unoverse studio`), then publish from Studio: the publish lint gates it |
-| Existing component restyle/edit only | takes effect live (the SDK reads `rx/` directly) |
+| Existing component restyle/edit only | takes effect live (the SDK reads `design/` directly) |
 | Agent skill / prompt block | publish from Studio, same gate |
 | Node | Studio's Nodes screen: Load sample → Run. A node is YAML; running it is the only proof (no build) |
 
-Verify the platform with `unoverse check` (services, schema, environment). Studio opens
-on :4108 (`unoverse studio` from the project folder).
+**Close the loop with the developer.** After creating something visual, tell them how
+to see it: open Studio (`unoverse studio`, :4108), find the artifact, preview it. The
+deliverable is the rendered thing, never the YAML alone.
 
-> In the platform monorepo (not the starter), the node docs live at
-> `packages/docs/nodes/`, the design journey at `packages/docs/design/`, and the dev loop
-> is just `npm run dev`. Component nodes synthesize from rx/ definitions at boot.
+Verify the platform with `unoverse check` (services, schema, environment).
+
+> In the platform monorepo (not a developer workspace), the project root is
+> `apps/unoverse/`, the docs source is `packages/docs/`, and the dev loop is
+> `npm run dev`. Component nodes synthesize from design/ definitions at boot.

package/vendor/skills/unoverse-create/references/agent-skill.md

@@ -7,7 +7,7 @@ at runtime (e.g. how to handle complaints, how to walk a user through a process)
 ## Where files go
 
 ```
-apps/unoverse/prompts/skills/<skill-name>/
+prompts/skills/<skill-name>/
   SKILL.md           # required: frontmatter + instructions
 ```
 
@@ -21,7 +21,7 @@ The runtime scans this folder and serves skills to agents; agents match on the
 name: skill-name                # required: lowercase, numbers, hyphens; max 64 chars
 title: Skill Name               # human display name, shown as the item's title in listings
 description: What this skill IS: ONE short line (≤ 120 chars), the listing subtitle
-whenToUse: The SELECTION text: outcome-first, in the user's vocabulary; ranked against intent for spatial discovery. See docs/nodes/node-discoverability.md. The node rules apply verbatim.
+whenToUse: The SELECTION text: outcome-first, in the user's vocabulary; ranked against intent for spatial discovery. See https://docs.unoverse.ai/nodes/node-discoverability.md. The node rules apply verbatim.
 version: 1.0.0                  # optional, semver
 category: ai                    # optional: ai | integration | workflow | utility
 triggers:                       # optional, max 20 keywords/phrases (2–50 chars each)
@@ -53,7 +53,8 @@ is invalid.
    discovery / findIntent). Write it **outcome-first in the user's vocabulary**
    ("Handle an unhappy customer: a complaint, frustration, or a request to
    escalate…"), never mechanism-first. The full rules are
-   `docs/nodes/node-discoverability.md`. They apply to skills verbatim.
+   [node-discoverability](https://docs.unoverse.ai/nodes/node-discoverability.md).
+   They apply to skills verbatim.
 2. **Study an existing skill** in `prompts/skills/` and match its voice and structure.
 3. Keep instructions outcome-focused and scannable: short sections, bulleted do/don't
    lists, explicit escalation/stop conditions.
@@ -61,5 +62,7 @@ is invalid.
 
 ## Ship
 
-`docker compose restart unoverse`. The runtime rescans skills at boot. Verify the
-skill appears via the platform's skill listing (`unoverse check` for overall health).
+Publish from Studio (the publish lint gates it). Operators running the platform
+directly can instead `docker compose restart unoverse`: the runtime rescans skills at
+boot. Verify the skill appears via the platform's skill listing (`unoverse check` for
+overall health).

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

@@ -8,7 +8,7 @@ is an ingredient.
 ## Where files go
 
 ```
-apps/unoverse/prompts/blocks/<category>/<block-name>.md
+prompts/blocks/<category>/<block-name>.md
 ```
 
 The immediate subdirectory is the block's category (existing: `core/`, `formatting/`).
@@ -40,4 +40,5 @@ present tense, no meta-commentary about being a block.]
 
 ## Ship
 
-`docker compose restart unoverse`. The runtime rescans blocks at boot.
+Publish from Studio (the publish lint gates it). Operators running the platform
+directly can instead `docker compose restart unoverse`: the runtime rescans blocks at boot.

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

@@ -13,11 +13,11 @@ client. They share one discipline and one failure mode.
 
 ## 1. How overriding actually works: name a token to override, omit it to inherit
 
-`rx/marketplace/styles` is the **foundation**: the shared token contract every org
+`design/marketplace/styles` is the **foundation**: the shared token contract every org
 inherits. Your org pack is read **on top** of it.
 
-The server builds a theme in three passes (`packages/base/src/definitions/theme.ts`,
-`buildTheme`):
+The server builds a theme in three passes (`buildTheme`, in the platform's theme
+resolver):
 
 1. the foundation's `base/` then `semantic/`, into a flat registry keyed by dotted path
 2. **your org's `base/` then `semantic/`, over the top**
@@ -45,8 +45,8 @@ re-copying anything.
 
 | Pack | `styles/base/` holds |
 |---|---|
-| Foundation (`rx/marketplace/`) | `border` `color` `motion` `radius` `shadow` `spacing` `typography` |
-| A brand (`rx/bpp/`) | `color` `typography` **only** |
+| Foundation (`design/marketplace/`) | `border` `color` `motion` `radius` `shadow` `spacing` `typography` |
+| A brand (`design/bpp/`) | `color` `typography` **only** |
 
 BPP names two files and inherits the other five. That ratio is the health check: a pack
 redefining `spacing` or `radius` is not branding, it is forking. The neutral core is
@@ -57,7 +57,7 @@ redefining `spacing` or `radius` is not branding, it is forking. The neutral cor
 An org is a folder. There is no registry to edit and nothing to declare.
 
 ```
-rx/<neworg>/
+design/<neworg>/
   styles/
     base/color.yaml          brand INGREDIENTS (color.brand.*)
     base/typography.yaml     font families only
@@ -85,10 +85,11 @@ you genuinely differ.
 
 Its theme is then served at `unoverse://theme/<neworg>/light`, and a template points at it.
 
-## 4. Anatomy of an org pack (`rx/<org>/styles/`)
+## 4. Anatomy of an org pack (`design/<org>/styles/`)
 
-Read `rx/bpp/styles/` as the worked example. Every file there carries a `$description`
-explaining its own job, and those descriptions are the spec.
+Read an installed org pack as the worked example (Studio MCP `listOrgs` →
+`listDefinitions`; in the platform monorepo, `design/bpp/styles/`). Every file in a healthy
+pack carries a `$description` explaining its own job, and those descriptions are the spec.
 
 | File | Holds | Rule |
 |---|---|---|
@@ -127,7 +128,7 @@ naming your situation is the intended answer.
 Copying an org pack is mechanical, and every gotcha is a name that exists in more than one
 place. Work through them in order.
 
-1. **Copy the folder.** `rx/<source>/` → `rx/<neworg>/`, keeping `styles/`, `components/`,
+1. **Copy the folder.** `design/<source>/` → `design/<neworg>/`, keeping `styles/`, `components/`,
    `templates/`.
 2. **Rename the templates.** Folder AND the id inside the manifest. `bpp-chat-layout`
    becomes `lyceum-chat-layout` in both places. Template ids are org-qualified and they
@@ -137,25 +138,25 @@ place. Work through them in order.
    is addressed `unoverse://components/<org>/<name>`. The one forbidden case is a name
    that shadows a design-system (marketplace) component; the publish lint catches it.
    Update template manifest `name`s only where the id itself is org-branded.
-4. **Register the client surface** if the demo client serves it
-   (`packages/demo/src/demo/clients.js`).
+4. **Register the client surface** if a demo client serves it (platform monorepo only:
+   `packages/demo/src/demo/clients.js`).
 5. **Point the app at the new theme.** Templates reference `unoverse://theme/<org>/<name>`.
    A copied template still names the old org until you change it.
 
 ## 7. Done means all four
 
-- `grep -ri "<oldorg>" rx/<neworg>/` returns **nothing**. This is the check that catches
+- `grep -ri "<oldorg>" design/<neworg>/` returns **nothing**. This is the check that catches
   the id someone missed at midnight, and it is the one people skip.
 - The new org appears in **Studio's universe dropdown** and its theme renders.
 - **Studio's publish lint: 0 errors.** Justify any warning out loud.
 - The conformance checklist passes for every copied component
-  ([UNOVERSE_CONFORMANCE](https://github.com/unoverse-platform/docs/blob/main/unoverse/UNOVERSE_CONFORMANCE.md)).
+  ([UNOVERSE_CONFORMANCE](https://docs.unoverse.ai/unoverse/UNOVERSE_CONFORMANCE.md)).
 
 ## Deeper references
 
 Token structure and the resolve order:
-[UNOVERSE_AUTHORING](https://github.com/unoverse-platform/docs/blob/main/unoverse/UNOVERSE_AUTHORING.md).
+[UNOVERSE_AUTHORING](https://docs.unoverse.ai/unoverse/UNOVERSE_AUTHORING.md).
 Which tier owns what:
-[UNOVERSE_LAYERS](https://github.com/unoverse-platform/docs/blob/main/unoverse/UNOVERSE_LAYERS.md).
+[UNOVERSE_LAYERS](https://docs.unoverse.ai/unoverse/UNOVERSE_LAYERS.md).
 Styles are W3C design tokens, two-tier base/semantic, resolved live by the server and
 served at `unoverse://theme/{org}/{name}`. The SDK fetches them and bundles none.

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

@@ -1,15 +1,20 @@
-# Playbook: Components & Atoms (rx data)
+# Playbook: Components & Atoms (design data)
 
-**Read first:** `docs/design/components.md` (the microapp anatomy) + `docs/design/state.md`
-(the state model). Deep law: [UNOVERSE_AUTHORING](https://github.com/unoverse-platform/docs/blob/main/unoverse/UNOVERSE_AUTHORING.md) §3 (three homes),
-`UNOVERSE_STATE_MODEL.md` §5 (the six rules), `UNOVERSE_LAYERS.md` (states own layouts).
-**Study the exemplar before writing**: `rx/sab/components/product-card` is the canonical
-State Model v2 component; mirror it exactly.
+**Read first:** [design/components](https://docs.unoverse.ai/design/components.md) (the
+microapp anatomy) + [design/state](https://docs.unoverse.ai/design/state.md) (the state
+model). Deep law: [UNOVERSE_AUTHORING](https://docs.unoverse.ai/unoverse/UNOVERSE_AUTHORING.md) §3 (three homes),
+[UNOVERSE_STATE_MODEL](https://docs.unoverse.ai/unoverse/UNOVERSE_STATE_MODEL.md) §5 (the six rules),
+[UNOVERSE_LAYERS](https://docs.unoverse.ai/unoverse/UNOVERSE_LAYERS.md) (states own layouts).
+**Study an exemplar before writing.** The canonical State Model v2 state tree is inlined
+below; for a full worked component, read an installed one through Studio's MCP
+(`listDefinitions` kind `component`, then `readDefinition`), and prefer a rich
+multi-state one over a starter stub. (In the platform monorepo the canonical exemplar
+is on disk: `design/sab/components/product-card`.)
 
 ## The anatomy
 
 ```
-apps/unoverse/rx/<project>/components/<name>/
+design/<project>/components/<name>/
   <name>.yaml      # ROOT: envelope (name/category/nodeSize/outputs/props) + the STATE TREE + root
   manifest.yaml    # RENDER CONTRACT + discovery meta (title / description ≤120 /
                    #   whenToUse utterance-shaped). Presence = spatially discoverable;
@@ -25,7 +30,7 @@ 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 canonical shape
-(`rx/sab/components/product-card/product-card.yaml`):
+(a product-card component: a grid state and a detail page with nested steps):
 
 ```yaml
 state:
@@ -101,9 +106,9 @@ The rules, in the order they bite:
      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`. Guard:
-     `server/src/runtime/content-card-hydration.test.ts`; law:
-     `UNOVERSE_MCP_TEMPLATE_PROTOCOL.md` §Content-attached cards.
+     `primaryImage` `images` `link` `callToAction`. Law:
+     `UNOVERSE_MCP_TEMPLATE_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
    conversation flow: the flow is its placeholder there. One EXCEPTION is the
@@ -119,7 +124,8 @@ The rules, in the order they bite:
    closes itself, or a NEW TEMPLATE loads (the template swap is the hard refresh boundary).
    Durable slices also opt out of `cancelBelow` retraction when a higher template state
    takes over. Default `"turn"`: the instance returns to inline / retires on the next
-   user turn. Values are a closed set: `turn | conversation` (lint-checked; docs/design/04).
+   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
    (`step`, `phase`, …) are the component's own business; the template never sees them.
    The only thing that crosses is the public `view`. The component writes ONLY its own
@@ -135,14 +141,18 @@ The rules, in the order they bite:
    of bound fields). Same shape, different values = ONE state, data-driven: seven wizard
    questions sharing one shape are one `question` state whose data changes, never seven
    files (LAYERS §4, §7).
-5. **Atoms** (`rx/marketplace/atoms/`, via `Ref`) are for shapes shared across components, authoring-time
+5. **Atoms** (the installed design system's shared shapes, used via `Ref`; list them with
+   Studio's MCP `listDefinitions` kind `atom`, 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;
    **`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`
    guard (unprovided ⇒ that piece stays hidden), `{{key}}` style bindings take the value.
    ⚠ Icon: literal = `icon: "phone"`; bound = `bind: { name: field }`.
-6. **Briefs: components an AI fills** (docs/design/03 §Briefed components; deep law: [UNOVERSE_AUTHORING](https://github.com/unoverse-platform/docs/blob/main/unoverse/UNOVERSE_AUTHORING.md) §3b). A `brief`
+6. **Briefs: components an AI fills**
+   ([design/components](https://docs.unoverse.ai/design/components.md) §Briefed components;
+   deep law: [UNOVERSE_AUTHORING](https://docs.unoverse.ai/unoverse/UNOVERSE_AUTHORING.md) §3b). A `brief`
    sits ON the node that renders what it describes, next to its `bind`, never in the
    manifest, never a separate file:
    - bound element → `"brief": { "description": "…", "maxLength": 60 }`
@@ -157,15 +167,16 @@ The rules, in the order they bite:
    for surgical refinement). **The schema IS the instruction channel.**
    Write briefs, never side-channel prompts/skills for filling a component. Shape is
    closed + linted. Pairs with the single-state permanent pattern (rule 2) for
-   continuously-enriched pages; exemplar: `rx/yasisland/components/perfect-day`.
+   continuously-enriched pages.
 7. **Tokens only** (LAW 1) + closed style keys + real space-scale steps
-   (`docs/design/06`): an invented step is silently broken CSS.
+   ([design/styles-and-tokens](https://docs.unoverse.ai/design/styles-and-tokens.md)):
+   an invented step is silently broken CSS.
 8. **Lifecycle hooks: the component fetches its own data** (full doc:
-   `docs/design/lifecycle-hooks.md`; deep law:
-   [UNOVERSE_AUTHORING](https://github.com/unoverse-platform/docs/blob/main/unoverse/UNOVERSE_AUTHORING.md) §3c). When a component needs data the
+   [design/lifecycle-hooks](https://docs.unoverse.ai/design/lifecycle-hooks.md); deep law:
+   [UNOVERSE_AUTHORING](https://docs.unoverse.ai/unoverse/UNOVERSE_AUTHORING.md) §3c). When a component needs data the
    workflow did not send (not from an AI = brief, not from the workflow = `input` props),
    it declares CALLS that the platform runs at a platform-owned fire point. **No code**:
-   a hook is data like everything else in `rx/`. It's for DATA, not styling or logic.
+   a hook is data like everything else in `design/`. It's for DATA, not styling or logic.
    - **Two phases**: `onStart` (the instance is created: data every copy needs) and
      `onEnterView` (the instance entered a named STATE: data only that state needs). A
      detail view's content is `onEnterView`, NEVER `onStart` — hydrating at creation
@@ -183,7 +194,7 @@ The rules, in the order they bite:
      never travels through a model. Use it for "fill this card with its own record".
 
    ```yaml
-   # manifest.yaml — the shipped rx/sab/components/product-card
+   # manifest.yaml — the shipped product-card exemplar
    lifecycle:
      - phase: onEnterView
        layouts: [ detail ]      # STATE names; the grid state never wakes it
@@ -199,7 +210,7 @@ The rules, in the order they bite:
    - **`allowedHosts` in the manifest is NOT optional**: a hook that makes requests
      without it is a lint ERROR (deny by default). Credentials are named by type in the
      manifest and resolved server-side from encrypted storage; **a key never sits in
-     `rx/`** (a shared design folder) and never reaches the client.
+     `design/`** (a shared design folder) and never reaches the client.
    - A phase fires once per instance; enrichment streams in (no blocked render); errors
      fail quietly, leaving whatever the card already had.
 
@@ -232,14 +243,13 @@ The rules, in the order they bite:
    LEGACY form. It still runs for handlers that predate declared calls, but it is **never
    the one to copy**: a script fetches any host with a key from the environment, and the
    calls runtime settles both questions.
-   Exemplar: `rx/yasisland/components/restaurant-card/` (maps lookup, declared calls).
 
-## Discovery meta: write it to RANK (docs/nodes/node-discoverability.md)
+## Discovery meta: write it to RANK ([node-discoverability](https://docs.unoverse.ai/nodes/node-discoverability.md))
 
 A component with a manifest is an **MCP app**: spatial embeds `` `title. whenToUse||description
 [category]` `` and ranks it against the USER'S OWN WORDS (`findIntent`). The meta is the
 selection text, not documentation. Weak meta makes a working component invisible. The
-strict contract (doc 14, applies verbatim):
+strict contract (that page, applied verbatim):
 
 - **`title`** = the thing itself, human display name, no mechanism, no org prefix.
 - **`description`** = what it IS, ONE line ≤120 chars, the listing subtitle; never
@@ -260,7 +270,8 @@ component. Its key nouns/verbs must appear in `whenToUse`'s first sentence.
 
 ## Workflow
 
-1. Study `rx/sab/components/product-card`; copy its folder shape.
+1. Study the closest installed exemplar (Studio MCP `listDefinitions` → `readDefinition`;
+   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

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

@@ -1,13 +1,19 @@
 # Playbook: custom workflow nodes
 
-**Read first, in order:**
-
-1. `docs/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. `docs/nodes/manifest-nodes.md`: the format in full, including the run context.
-3. `docs/nodes/node-discoverability.md`: **read before writing `whenToUse`**.
-4. As needed: `credentials.md`, `who-can-run-it.md`, `config-schema.md`, `service-connectors.md`,
-   `mcp-services.md`, `signal-routing.md`, `testing-nodes.md`.
+**Read first, in order** (all served at docs.unoverse.ai; append `.md` for raw markdown):
+
+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.
+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),
+   [config-schema](https://docs.unoverse.ai/nodes/config-schema.md),
+   [service-connectors](https://docs.unoverse.ai/nodes/service-connectors.md),
+   [mcp-services](https://docs.unoverse.ai/nodes/mcp-services.md),
+   [signal-routing](https://docs.unoverse.ai/nodes/signal-routing.md),
+   [testing-nodes](https://docs.unoverse.ai/nodes/testing-nodes.md).
 
 This playbook adds the workflow around those docs. It never overrides them.
 
@@ -20,7 +26,7 @@ is a folder of YAML files that the platform interprets.
 missing a capability. Say so and stop, rather than reaching for code.
 
 ```
-apps/unoverse/nodes/<package>/
+nodes/<package>/
   package.yaml              # name, category, allowedHosts, requires
   credentials/
     <name>Credential.yaml   # the SHAPE of a credential, never a value
@@ -79,7 +85,7 @@ package only for a new integration.
    ```
 
    `required: false` is right for almost every node: the trigger already decided who was let
-   in. See `docs/nodes/who-can-run-it.md`.
+   in. See [who-can-run-it](https://docs.unoverse.ai/nodes/who-can-run-it.md).
 3. **Write `interface.yaml`.** Name outputs for what they carry, because those names become
    what someone types in a template.
 4. **Write `config.yaml`.** Every value the workflow supplies needs `ui:field: template`. A
@@ -107,7 +113,7 @@ package only for a new integration.
 5. **Write `api/run.yaml`.** A list, each entry named. Include `error` wherever the service
    can answer 200 with a failure body. Where one call is really many, name the capability on
    the call rather than trying to express a loop: `paginate`, `chunk`, `poll` or `state`.
-   See `docs/nodes/calls-that-loop.md`, and declare each one in `requires`. A call
+   See [calls-that-loop](https://docs.unoverse.ai/nodes/calls-that-loop.md), and declare each one in `requires`. A call
    authenticates with `credential: { scheme, token }`, which is OUTBOUND: how the node proves
    itself to the vendor. It is not `node.yaml`'s `auth`, which is who may run the node.
 6. **Write `api/events.yaml`.** One row per output connector, in the order `interface.yaml`