@unoverse-platform/studio 0.1.58 → 0.1.60

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@unoverse-platform/studio",
-  "version": "0.1.58",
+  "version": "0.1.60",
   "type": "module",
   "description": "Unoverse Studio: the local authoring app. Reads your own rx/ folder, no backend.",
   "scripts": {

package/src/host.ts

@@ -22,21 +22,19 @@ export const UNOVERSE_BASE = "";
 export const hasAuth = false;
 
 /**
- * The universe Studio is signed into (the header connection), or null when offline.
- * THE LIVE PREVIEW'S SERVER. One source of truth: the same selection App.tsx keeps
- * (`studio:universe` is its usePersistentState pointer into the saved universe list),
- * so it is impossible to be signed into one universe and silently previewing against
- * another. The shared screens fall back to the local dev platform only when no
- * universe is connected.
+ * THE LIVE PREVIEW'S SERVER: always null here, meaning the local dev platform.
+ *
+ * This used to read the universe picked in the header (`studio:universe`), written by
+ * the connect button. That chrome is gone (LOCAL_STUDIO.md §Publish is terminal-only) —
+ * and reading the stale localStorage value after removing the UI left Live mode aimed
+ * at a universe nobody could change or clear, failing with that universe's errors
+ * (seen live: "Unknown Unoverse template" from a universe the app was never published
+ * to). So local Studio's Live preview targets the local dev platform, full stop.
+ * Pointing Live at the workspace's own universe (unoverse.yaml) is future work and
+ * will come from the workspace, not from a browser store.
  */
 export function liveUniverseUrl(): string | null {
-  try {
-    const raw = localStorage.getItem("studio:universe");
-    const url = raw === null ? null : (JSON.parse(raw) as string | null);
-    return url || null;
-  } catch {
-    return null;
-  }
+  return null;
 }
 
 /**

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

@@ -102,16 +102,16 @@ fetch it as raw markdown.
 ## Step 3: Deploy loop (after the artifact is written)
 
 Components and templates have NO scaffold command. Author them from the references
-(mirror the closest existing artifact). Validation lives in Studio: its publish step
+(mirror the closest existing artifact). Validation lives in the deploy lint (`unoverse deploy studio`): it
 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://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 |
+| Component / atom / template / style | Preview in Studio (`unoverse studio`), then `unoverse deploy studio`: the deploy lint gates it |
 | Existing component restyle/edit only | takes effect live (the SDK reads `design/` directly) |
-| Agent skill / prompt block | publish from Studio, same gate |
+| Agent skill / prompt block | `unoverse deploy studio`, same gate |
 | Node | Studio's Nodes screen: Load sample → Run. A node is YAML; running it is the only proof (no build) |
 
 **Close the loop with the developer.** After creating something visual, tell them how

package/vendor/skills/unoverse-prompt-component/SKILL.md

@@ -32,7 +32,7 @@ It prints every part the agent can fill, its description, and its limits. Read t
 output, not the YAML. Then run the design lint
 (`node -e "import('./packages/base/src/lint/design/index.mjs').then(m=>{const r=m.lintDefinitions();console.log(r.problems.length);r.problems.forEach(p=>console.log(p.level,p.file,p.msg))})"`).
 
-In a **Studio developer workspace**, the same linter runs as Studio's publish lint; it
+In a **Studio developer workspace**, the same linter runs as the deploy lint (`unoverse deploy studio`); it
 catches two of the five traps below by name. Read what it says rather than silencing it, and always do the final proof in
 Step 6: one real fill.