Refine Studio product previews

.github/workflows/deploy-pages-channel.yml

@@ -76,6 +76,9 @@ jobs:
       - name: Install wasm-bindgen-cli
         run: cargo install wasm-bindgen-cli --version 0.2.114 --locked
 
+      - name: Install dioxus-cli
+        run: cargo install dioxus-cli --version 0.7.9 --locked
+
       - name: Install espflash
         if: inputs.channel == 'beta'
         run: cargo install espflash --version 3.3.0 --locked

.github/workflows/deploy-studio-pages.yml

@@ -66,6 +66,9 @@ jobs:
       - name: Install wasm-bindgen-cli
         run: cargo install wasm-bindgen-cli --version 0.2.114 --locked
 
+      - name: Install dioxus-cli
+        run: cargo install dioxus-cli --version 0.7.9 --locked
+
       - name: Install espflash
         run: cargo install espflash --version 3.3.0 --locked
 

.gitignore

@@ -34,9 +34,7 @@ perf.data*
 .builtins-source-hash
 traces/
 profiles/
-lp-app/lpa-studio-web/public/pkg/
 lp-app/lpa-studio-web/public/fw-browser-worker.js
-lp-app/lpa-studio-web/public/firmware/
 lp-app/lpa-studio-web/dist/
 lp-app/lpa-studio-web/story-images/.new/
 lp-app/lpa-studio-web/story-images/.scratch/

AGENTS.md

@@ -246,14 +246,14 @@ be migrated unless a separate migration plan asks for it.
 
 ## Studio UI visual baselines
 
-When a change touches non-generated files under `lp-app/lp-studio-web/`, run the
+When a change touches non-generated files under `lp-app/lpa-studio-web/`, run the
 Studio story baseline helper before committing:
 
 ```bash
 just studio-story-baselines-if-needed
 ```
 
-If it updates files under `lp-app/lp-studio-web/story-images/`, include those
+If it updates files under `lp-app/lpa-studio-web/story-images/`, include those
 PNG changes in the same commit and mention the affected story baselines in the
 final summary. The helper intentionally ignores generated web artifacts,
 scratch PNGs, fresh check PNGs, and the baseline PNGs themselves.

Cargo.toml

@@ -12,8 +12,9 @@ members = [
     "lp-app/lpa-server",
     "lp-app/lpa-client",
     "lp-app/lpa-link",
-    "lp-app/lpa-studio-ux",
+    "lp-app/lpa-studio-core",
     "lp-app/lpa-studio-web",
+    "lp-app/lpa-studio-web-story-macros",
     "lp-fw/fw-browser",
     "lp-fw/fw-core",
     "lp-fw/fw-host",
@@ -74,7 +75,7 @@ default-members = [
     "lp-app/lpa-server",
     "lp-app/lpa-client",
     "lp-app/lpa-link",
-    "lp-app/lpa-studio-ux",
+    "lp-app/lpa-studio-core",
     "lp-fw/fw-core",
     "lp-fw/fw-host",
     "lp-fw/fw-checks",

docs/adr/2026-06-18-browser-serial-shim.md

@@ -22,7 +22,7 @@ into unrelated Rust validation.
 
 Use a tiny JavaScript shim for direct Web Serial stream ownership.
 
-- `lp-app/lp-studio-web/public/browser-serial.js` owns
+- `lp-app/lpa-studio-web/public/browser-serial.js` owns
   `navigator.serial.requestPort()`, `SerialPort.open()`, stream readers,
   stream writers, line buffering, and close/cancel behavior.
 - The shim installs a narrow global function surface before the Rust wasm module

docs/adr/2026-06-18-studio-action-session-architecture.md

@@ -32,7 +32,7 @@ Studio is split into three application-facing crates:
   events, diagnostics, capabilities, and session records.
 - `lp-studio-runtime` executes effects and translates link/client/runtime facts
   back into Studio events.
-- `lp-studio-web` renders `StudioState` with Dioxus and dispatches
+- `lpa-studio-web` renders `StudioState` with Dioxus and dispatches
   `StudioAction` values.
 
 The core loop is:

docs/adr/2026-06-18-studio-native-storybook.md

@@ -17,7 +17,7 @@ props. That makes them well suited to local fixture-driven stories.
 
 ## Decision
 
-Studio component stories will be native Dioxus code in `lp-studio-web`.
+Studio component stories will be native Dioxus code in `lpa-studio-web`.
 
 - Story files live next to components as sibling `*_stories.rs` modules.
 - A small explicit Rust registry collects story descriptors and render functions.

docs/adr/2026-06-18-studio-story-png-baselines.md

@@ -18,18 +18,18 @@ before investing in CI visual-regression infrastructure.
 
 ## Decision
 
-Commit a curated baseline PNG set for `lp-studio-web` stories.
+Commit a curated baseline PNG set for `lpa-studio-web` stories.
 
-- Committed baselines live under `lp-app/lp-studio-web/story-images/`.
+- Committed baselines live under `lp-app/lpa-studio-web/story-images/`.
 - Scratch review PNGs stay gitignored under
-  `lp-app/lp-studio-web/story-images/.scratch/`.
+  `lp-app/lpa-studio-web/story-images/.scratch/`.
 - Fresh check output lives under gitignored
-  `lp-app/lp-studio-web/story-images/.new/`.
+  `lp-app/lpa-studio-web/story-images/.new/`.
 - `just studio-story-baselines` regenerates the committed baseline set.
 - `just studio-story-check` compares fresh story PNGs to committed baselines
   without updating them.
 - `just studio-story-baselines-if-needed` runs baseline generation only when
-  non-generated files under `lp-app/lp-studio-web/` changed since `HEAD`.
+  non-generated files under `lp-app/lpa-studio-web/` changed since `HEAD`.
 - Story captures are clipped to the marked story canvas content rather than the
   full browser viewport.
 - Baseline and check commands require `oxipng` so fresh captures are normalized
@@ -51,3 +51,16 @@ and baseline updates should remain intentional.
 CI can later run `just studio-story-check`, but CI should not commit updated
 PNGs. If the image set grows substantially or churn becomes painful, revisit
 this decision before adding Git LFS or hard visual gates.
+
+## 2026-06-23 Addendum: Responsive Baseline Matrix
+
+The project editor foundation makes responsive layout a first-order part of the
+Studio UI. The accepted baseline set now captures each story at `sm`, `md`, and
+`lg` viewports. Baseline filenames include the viewport id, such as
+`studio__editor-shell__sm.png`, so check mode can compare the full story by
+viewport matrix and report changed, new, or removed images precisely.
+
+This increases baseline count and disk usage, but keeps responsive regressions
+visible while the editor shell, node tree, and device rail are still taking
+shape. The same `oxipng` normalization remains required for baseline and check
+modes.

docs/adr/2026-06-18-studio-web-provisioning-controller.md

@@ -23,7 +23,7 @@ plug into the same user journey.
 
 ## Decision
 
-Use a thin browser-side provisioning controller in `lp-studio-web`.
+Use a thin browser-side provisioning controller in `lpa-studio-web`.
 
 - The controller dispatches real `StudioActionKind` values into `StudioApp`.
 - It drains returned `StudioEffect` values through the active browser runtime.

docs/adr/2026-06-22-studio-pages-deployment.md

@@ -40,8 +40,10 @@ manual workflow, then published as static commits to the corresponding Pages
 repository.
 
 Deployment tooling stages clean release-only artifacts under `target/pages/`
-and generates `version.json`, `.nojekyll`, and `CNAME` files. This avoids
-uploading stale debug wasm from `lp-app/lpa-studio-web/public/pkg`.
+and generates `version.json`, `.nojekyll`, and `CNAME` files. Studio app
+JS/WASM comes from `dx` release output, and generated runtime sidecars are
+copied into that output from `target/studio-web-assets/` instead of being staged
+under source `public/`.
 
 ## Consequences
 

docs/adr/2026-06-23-studio-hierarchical-ux-node-dispatch.md

@@ -0,0 +1,78 @@
+# ADR 2026-06-23: Studio Hierarchical UX Node Dispatch
+
+## Status
+
+Accepted.
+
+## Context
+
+The Studio device manager started with a small static UX tree:
+
+```text
+StudioUx
+  DeviceUx
+  ProjectUx
+```
+
+Exact target matching was enough for that shape. The project editor needs more
+dynamic action targets: node tree, individual nodes, slot rows, assets, changes,
+bus views, probes, and eventually binding controls attached to slot rows.
+
+Several designs were considered:
+
+- Keep exact static dispatch and add ad hoc string checks as needed.
+- Add a non-owning `UxRegistry` or router that maps target prefixes to owners.
+- Add a registry-owned component tree of boxed dynamic UX nodes.
+- Make `UxNodeId` path-shaped and dispatch hierarchically through the explicit
+  ownership tree.
+
+## Decision
+
+Studio will use path-shaped `UxNodeId` values and owner-local hierarchical
+dispatch.
+
+The ownership tree remains explicit Rust structs:
+
+```text
+StudioUx
+  owns DeviceUx
+  owns ProjectUx
+```
+
+The address tree is a UX path:
+
+```text
+studio.device
+studio.project
+studio.project.node_tree
+studio.project.node.<id>
+studio.project.node.<id>.slot.<slot-path>
+studio.project.asset.<id>
+studio.project.changes
+studio.project.bus
+```
+
+`StudioUx` owns top-level routing. It handles `studio.device` and routes
+`studio.project` plus `studio.project.*` to project ownership. `ProjectUx` owns
+interpretation of project-local subtargets.
+
+Actions remain in-process typed values. The target address identifies the UX
+surface; the boxed typed operation identifies what to do. This decision does
+not introduce serialized action commands or a remote action protocol.
+
+## Consequences
+
+The model keeps Rust ownership simple. There is no weak-reference graph,
+`Rc<RefCell<_>>` ownership tree, or boxed async node runtime.
+
+Dynamic addresses do not imply dynamic object ownership. A slot row can be
+addressed without being stored as an independently owned UX node.
+
+Dispatch has some manual machinery. Each owner must parse and handle its own
+subtree clearly, with explicit errors for unknown targets or wrong operation
+types.
+
+A future `UxRegistry` is still possible if Studio grows non-tree routing,
+plugin-style mounting, or cross-cutting introspection needs. If introduced
+later, it should build on the path-shaped `UxNodeId` model rather than replacing
+typed in-process actions.