@scayle/storefront-devtools 0.2.0-alpha.1 → 0.2.0-alpha.2

package/CHANGELOG.md

@@ -1,5 +1,15 @@
 # @scayle/storefront-devtools
 
+## 0.2.0-alpha.2
+
+### Patch Changes
+
+- Added dependency `@vitejs/devtools-kit@catalog:`
+- Removed dependency `sirv@catalog:`
+- The Inertia.js, oRPC, and Storefront context panels now run as iframe apps in the dock. Page scripts in your app send them their data over `devframe/in-page-channel`. The panels keep rendering when you switch the dock between Float, Edge, and Popup, and they no longer show up as extra apps in Vue DevTools.
+
+  The Resource Center entry is gone, and so are the `./inertia/renderer`, `./orpc/renderer`, `./storefront/renderer`, and `./resource-center/client` subpath exports. The dock loads the panels itself, so nothing outside this package imported them.
+
 ## 0.2.0-alpha.1
 
 ### Patch Changes

package/README.md

@@ -10,7 +10,7 @@
 </h4>
 
 <p align="center">
-  The SCAYLE <strong>Storefront DevTools</strong> package wires the Vite DevTools dock into the Storefront Application V3, with an Inertia.js inspector, an oRPC call inspector, a Storefront context viewer, a Resource Center, and Vue DevTools, behind a single Vite plugin call.
+  The SCAYLE <strong>Storefront DevTools</strong> package adds the Vite DevTools dock to the Storefront Application V3 with one Vite plugin call. The dock holds an Inertia.js inspector, an oRPC call inspector, a Storefront context viewer, and Vue DevTools.
 </p>
 <p align="center">
   <a href="#"><img src="https://img.shields.io/badge/license-MIT-blue.svg" alt="SCAYLE's Storefront DevTools is released under the MIT license." /></a>
@@ -18,30 +18,29 @@
 
 ## Overview
 
-`@scayle/storefront-devtools` is a dev-only Vite plugin. It hosts the Vite DevTools dock and registers a **SCAYLE Storefront** dock group, plus a **Vue** group:
+`@scayle/storefront-devtools` is a dev-only Vite plugin. It hosts the Vite DevTools dock and registers two dock groups, **SCAYLE Storefront** and **Vue**:
 
-- **Inertia.js panel**: every visit your app makes, correlated into one request per navigation. Shows the response body and headers, the Inertia protocol details (partial reload keys, asset version, redirects), and a lifecycle timeline, with diagnostics for common mistakes like a missing partial-reload prop. The [Inertia.js panel](#inertiajs-panel) section covers it in depth.
-- **oRPC panel**: every call to your `/api` endpoint, decoded from its wire format back to typed input and output. Groups calls by procedure, classifies failures, and tracks per-procedure timing. The [oRPC panel](#orpc-panel) section covers it in depth.
-- **Storefront context panel**: a read-only view of the resolved shop, country, locale, and session for the page you're looking at, read from the Inertia page the SDK ships. The [Storefront context panel](#storefront-context-panel) section covers it.
-- **Resource Center**: the Storefront documentation, embedded in the dock so you don't have to leave the app to look something up.
-- **Vue panel**: the component tree and timeline you'd otherwise get from a separate `vite-plugin-vue-devtools` install, mounted in the same dock.
+- The Inertia.js panel lists every visit your app makes, one request per navigation. It shows the response body and headers, the Inertia protocol details (partial reload keys, asset version, redirects), and a lifecycle timeline, and it flags common mistakes such as a missing partial-reload prop. The [Inertia.js panel](#inertiajs-panel) section covers it in depth.
+- The oRPC panel lists every call to your `/api` endpoint and decodes each call's `{ json, meta }` envelope back to typed input and output. It groups calls by procedure, classifies failures, and tracks timing per procedure. The [oRPC panel](#orpc-panel) section covers it in depth.
+- The Storefront context panel is a read-only view of the resolved shop, country, locale, and session for the page you're looking at, taken from the Inertia page the SDK ships. The [Storefront context panel](#storefront-context-panel) section covers it.
+- The Vue panel gives you the component tree and timeline in the same dock, so you don't need a separate `vite-plugin-vue-devtools` install.
 
-The plugin runs only on the dev server and drops out of production builds with no environment flag needed — see "Production safety" below for exactly why.
+The plugin only runs on the dev server and drops out of production builds without an environment flag. [Production safety](#production-safety) explains why.
 
-## Why not the browser Network tab?
+## Beyond the browser Network tab
 
-The browser's Network tab is the right tool for raw HTTP. These panels exist for what it structurally cannot show.
+Use the browser's Network tab for raw HTTP. These panels cover what it can't show.
 
-- **Inertia visits often have no network footprint.** The initial page load embeds the page object in the HTML, so it is never an XHR. Client-side history navigations, prefetch cache hits, and `preserveState` updates produce no request at all. The Network tab has no row for any of these. The panel captures them from Inertia's DOM events and history, so they are visible.
-- **The panel diffs and correlates across visits.** It shows a structural props diff between consecutive visits, links a deferred-prop reload to the parent visit that triggered it, and renders the lifecycle event timeline. The Network tab shows one request at a time with no memory of the last one.
-- **oRPC bodies on the wire are not your arguments.** Every oRPC call is a `POST /api` carrying a `{ json, meta }` envelope. The Network tab shows that envelope raw and cannot reconstruct the `Date`, `Map`, `Set`, or `BigInt` values it encodes, because JSON has no way to represent them. The panel decodes the envelope to the typed value your handler actually received.
-- **oRPC calls are indistinguishable in the Network tab.** They are all POSTs to the same `/api` URL, so you cannot tell `basket/add` from `wishlist/remove` without opening each one and reading the body. The panel groups by procedure, aggregates per-procedure timing, and classifies each failure as validation, server, or network.
+- Many Inertia visits never hit the network. The initial page load embeds the page object in the HTML, so no XHR fires. Client-side history navigations, prefetch cache hits, and `preserveState` updates send no request at all, and the Network tab has no row for them. The Inertia.js panel picks them up from Inertia's DOM events and from history.
+- The Inertia.js panel compares visits. It diffs the props of consecutive visits, links a deferred-prop reload to the visit that triggered it, and draws the lifecycle event timeline. The Network tab shows one request at a time and forgets the one before.
+- An oRPC request body isn't the argument your code passed. Every oRPC call is a `POST` under `/api` with a `{ json, meta }` envelope. The Network tab shows that envelope as raw JSON and can't rebuild the `Date`, `Map`, `Set`, or `BigInt` values it encodes, because JSON has no way to represent them. The oRPC panel decodes the envelope back to the typed value your handler received.
+- oRPC calls get lost in the Network tab, between the images, scripts, and page visits a storefront loads. The oRPC panel lists only oRPC calls, groups them by procedure, adds up the timing per procedure, and classifies each failure as validation, server, or network.
 
-Where it overlaps the Network tab (the per-call HTTP view of a single oRPC request), the panels do not try to replace it. Use the Network tab for the raw transaction, the panels for the framework-level meaning.
+Where the two overlap, in the HTTP view of a single oRPC request, the panels don't try to replace the Network tab. Use the Network tab for the raw transaction and the panels for what it means to Inertia and oRPC.
 
 ## Installation
 
-The package ships with Storefront Application V3 by default. To add it manually:
+The package ships with Storefront Application V3 by default. To add it yourself:
 
 ```bash
 pnpm add -D @scayle/storefront-devtools
@@ -49,7 +48,7 @@ pnpm add -D @scayle/storefront-devtools
 
 ## Integration
 
-The package is consumed only from the Storefront Application V3 `vite.config.ts`. No other application code changes are required: the dock client and the Inertia and oRPC capture clients are injected into the application's client entry automatically.
+The only file you change is the Storefront Application V3 `vite.config.ts`. The plugin injects the dock client and the Inertia and oRPC page scripts into the app's client entry, so the rest of your app code stays as it is.
 
 Import the default export and spread it into the `plugins` array, after `@vitejs/plugin-vue`:
 
@@ -75,147 +74,178 @@ export default defineConfig({
 })
 ```
 
-`storefrontDevtools()` returns an array of Vite plugins, so it must be spread. It also provides the Vue DevTools panel itself, so no separate `vite-plugin-vue-devtools` is needed.
+`storefrontDevtools()` returns an array of Vite plugins, so you have to spread it. It includes the Vue DevTools panel, so you don't need `vite-plugin-vue-devtools` on top.
 
 ### Dev server path exclusion
 
-The dock and its assets are served by Vite under `/__devtools/` and `/__storefront-devtools/`. The Storefront Application V3 serves pages through a Hono dev server with a country-prefix redirect, which would otherwise catch those paths and rewrite them. `@scayle/storefront-build` already excludes the DevTools mount paths from the Hono dev server, so no extra configuration is needed when both packages are present.
+Vite serves the dock and its assets under `/__devtools/` and `/__storefront-devtools/`. The Storefront Application V3 serves pages through a Hono dev server with a country-prefix redirect, which would catch those paths and rewrite them. `@scayle/storefront-build` already excludes the DevTools paths from the Hono dev server, so with both packages installed you need no extra configuration.
 
-`storefrontDevtools()` takes no options. It always registers the Inertia.js, oRPC, Storefront context, Resource Center, and Vue panels, and always injects into the Storefront Application V3's own client entry (`src/client/main.ts`).
+`storefrontDevtools()` takes no options. It always registers the Inertia.js, oRPC, Storefront context, and Vue panels, and it always injects into the Storefront Application V3's own client entry (`src/client/main.ts`).
 
 ## Opening the dock
 
-Run the Storefront Application V3 dev server (`pnpm dev`) and open the app. A floating launcher appears on the page. Open it, then open the **SCAYLE Storefront** group to reach the **Inertia.js**, **oRPC**, **Storefront**, and **Resource Center** entries, or the **Vue** group for the component tree and timeline.
+Run the Storefront Application V3 dev server (`pnpm dev`) and open the app. A floating launcher appears on the page. Open it, then open the **SCAYLE Storefront** group for the **Inertia.js**, **oRPC**, and **Storefront** entries, or the **Vue** group for the component tree and timeline.
 
-The launcher is injected into the client entry (not the HTML) because the Storefront Application V3 composes its HTML through the SSR renderer, so Vite's `transformIndexHtml` hook never fires. The same mechanism injects every panel's capture client.
+The plugin injects the launcher into the client entry instead of the HTML. The Storefront Application V3 builds its HTML in the SSR renderer, so Vite's `transformIndexHtml` hook never fires. Every panel's page script arrives through the same injection.
 
-## Security: how the dock authenticates the browser
+## Security and browser authorization
 
-The dock's browser side and the Vite dev server talk over a WebSocket RPC channel (`@devframes/hub`, using `crossws` as its transport abstraction). That channel is not limited to rendering our panels — `@vitejs/devtools` ships its own built-in RPC surface with real capabilities on the developer's machine, most notably **`vite:core:open-in-editor`** (opens an arbitrary file path in the developer's editor) and a terminals feed. This package sets `builtinDevTools: false`, which drops the upstream Terminals/Messages/Inspector docks and their UI, but the underlying RPC declarations are part of `@vitejs/devtools` itself, not something a consumer can un-register from the wire protocol. Two independent gates protect this channel:
+The dock in the browser talks to the Vite dev server over a WebSocket RPC channel (`@devframes/hub`, with `crossws` as its transport layer). Our panels aren't the only thing on that channel. `@vitejs/devtools` ships its own RPC functions with real reach into your machine, for example `vite:core:open-in-editor`, which opens any file path in your editor, and a terminals feed. This package sets `builtinDevTools: false`, which drops the upstream Terminals, Messages, and Inspector docks and their UI. The RPC declarations behind them stay, because they belong to `@vitejs/devtools` itself and a consumer can't remove them. Two independent checks protect the channel.
 
-- **Origin allowlist.** `@vitejs/devtools` only accepts WebSocket connections whose `Origin` header matches a built-in loopback allowlist (`localhost`, `127.0.0.1`, and similar). This check is a **plain string match, not a DNS or hosts-file resolution** — a custom dev hostname that resolves to loopback via `/etc/hosts` or a local DNS override (e.g. `dev-my-app.example.com`) is invisible to it and gets rejected by default. If your setup needs a non-default hostname (a reverse proxy, a tunnel, a custom `/etc/hosts` entry), list it explicitly via `devtools: { allowedOrigins: ['https://dev-my-app.example.com'] }` in the app's Vite config.
-- **One-time client authorization.** On top of the origin check, `@vitejs/devtools` gates the RPC connection behind a one-time code by default (`clientAuth: true`). On first connection from a new browser, the `pnpm dev` terminal prints `devframe auth code <code>` and a magic-link URL (`...#devframe_otp=<code>`); enter the code in the dock's prompt, or open the printed URL, to authorize that browser. Until then, the dock stays unauthorized — this is expected, not a connection failure.
+### Origin allowlist
 
-**Disabling the authorization gate.** Setting `devtools: { clientAuth: false }` (or the `VITE_DEVTOOLS_DISABLE_CLIENT_AUTH=true` env var) skips the one-time-code prompt. Per `@vitejs/devtools`'s own documentation: _"if you disable client authentication, any browsers can connect to the devtools and access to your server and filesystem (including other devices, if you open server `host` option to LAN or WAN)."_ Only disable this in an environment where every request already reaches only a trusted developer (never with `server.host` bound to a LAN/WAN interface), and never in anything resembling a shared or production-adjacent environment.
+`@vitejs/devtools` accepts a WebSocket connection only when its `Origin` header matches a built-in loopback allowlist (`localhost`, `127.0.0.1`, and similar). The check compares strings. It doesn't resolve DNS or read your hosts file, so a custom dev hostname that points at loopback through `/etc/hosts` or a local DNS override (for example `dev-my-app.example.com`) gets rejected by default. If your setup needs another hostname, such as a reverse proxy, a tunnel, or a custom `/etc/hosts` entry, add it with `devtools: { allowedOrigins: ['https://dev-my-app.example.com'] }` in the app's Vite config.
 
-**Production safety.** `storefrontDevtools()` always registers its plugins, with no `import.meta.env.PROD` check on our side — the safety comes from `@vitejs/devtools` itself. The plugin that actually opens the WebSocket RPC server does so from Vite's `configureServer` hook, which Vite only ever calls during `vite dev`/`vite serve`, never during `vite build`. A production build and its runtime output carry no RPC server, no WebSocket endpoint, and none of the injected capture/launcher code reachable from a deployed Storefront Application V3.
+### One-time client authorization
 
-## How it works
+On top of the origin check, `@vitejs/devtools` puts the RPC connection behind a one-time code by default (`clientAuth: true`). The first time a new browser connects, the `pnpm dev` terminal prints `devframe auth code <code>` and a magic-link URL (`...#devframe_otp=<code>`). Enter the code in the dock's prompt, or open the printed URL, to authorize that browser. The dock stays unauthorized until you do, and that's expected.
 
-The package has two halves, both running in the host page's browser context, connected through a `window` global. There is no iframe between them: the Inertia panel mounts directly into the dock's panel element (a custom-render entry) and reads the capture store off `window`.
+### Turning off the authorization check
+
+Setting `devtools: { clientAuth: false }` (or the `VITE_DEVTOOLS_DISABLE_CLIENT_AUTH=true` environment variable) skips the one-time code. The `@vitejs/devtools` documentation warns about this: _"if you disable client authentication, any browsers can connect to the devtools and access to your server and filesystem (including other devices, if you open server `host` option to LAN or WAN)."_ Only turn it off where every request comes from a trusted developer. Never do it with `server.host` bound to a LAN or WAN interface, or in a shared environment or anything close to production.
+
+### Production safety
+
+`storefrontDevtools()` registers its plugins in every build, with no `import.meta.env.PROD` check of its own. The safety comes from `@vitejs/devtools`. Its plugin opens the WebSocket RPC server from Vite's `configureServer` hook, and Vite calls that hook during `vite dev` and `vite serve`, never during `vite build`. A production build and its runtime output carry no RPC server, no WebSocket endpoint, and none of the injected page scripts or launcher code.
+
+## Page scripts and panel apps
+
+The package has two halves. Page scripts run in the app's own page and capture what happens there. Panel apps run in iframes inside the dock and render what the page scripts publish. The two talk over `devframe/in-page-channel`, a `postMessage` channel between the page and the iframes the dock hosts for it.
 
 ```
-host page (browser)
-  injected client (into the app's client entry)      dock custom-render
-    DOM-event capture (inertia:*)                       Vue panel
-      -> Correlator -> RequestRecords          reads &  mounted into the dock DOM
-    history-capture (pushState/replaceState)   ───────▶ subscribes to the store
+app page (browser)                                  dock iframe
+  page script (injected into the client entry)        panel app (/__storefront-devtools/panels/)
+    DOM-event capture (inertia:*)                       ?view=inertia | orpc | storefront
+      -> Correlator -> RequestRecords
+    history-capture (pushState/replaceState)
     network timing (PerformanceObserver)
-      -> DevToolsStore on window
-  window.__STOREFRONT_DEVTOOLS_STORE__
+      -> DevToolsStore
+    createPageScriptChannel()   ── state snapshots ──▶  connectPanelChannel()
+                                ◀── getState, clear,    mirrors the latest
+                                    setPaused ───────   snapshot into a Vue ref
 ```
 
-### Capture (host page)
+### Capture in the app page
 
-On load, the injected client builds a `DevToolsStore`, stashes it at `window.__STOREFRONT_DEVTOOLS_STORE__`, and wires three non-invasive sources into it:
+On load, the Inertia page script builds a `DevToolsStore` and feeds it from three sources, none of which change how Inertia behaves:
 
-- **DOM events** — `document.addEventListener` over the Inertia 3.x `inertia:*` events. Each event's detail is safely serialized (depth-limited, functions and abort signals stripped) and fed to the store. No `router.on()` patching.
-- **Network timing** — a `PerformanceObserver` over resource-timing entries, matched to in-flight requests by URL.
-- **Client-side history** — a `history.pushState` / `replaceState` patch that detects client visits (`router.push` / `router.replace`) that bypass the normal Inertia event lifecycle.
+- Inertia 3.x's `inertia:*` DOM events, through `document.addEventListener`. The script copies each event's detail with a depth limit, drops functions and abort signals, and hands it to the store. It doesn't patch `router.on()`.
+- A `PerformanceObserver` over resource-timing entries, matched to in-flight requests by URL.
+- A `history.pushState` / `replaceState` patch that catches client visits (`router.push` / `router.replace`) that skip the normal Inertia event lifecycle.
 
-Every handler is wrapped so the devtools can never crash the host application.
+Every handler runs inside a guard, so a devtools error can't crash the app.
 
 ### Correlation
 
-A correlator groups the raw events into one `RequestRecord` per logical visit, matching events by a visit fingerprint plus an active-visit pointer. It handles deferred prop reloads, prefetch cache hits, POST→redirect flows, 409 asset-version mismatches, and the initial page load. Records are kept in a bounded buffer (200), and a compact summary of the previous session is persisted to `sessionStorage` so requests from before a reload remain visible.
+A correlator groups the raw events into one `RequestRecord` per visit. It matches events by a visit fingerprint plus a pointer to the active visit, and it handles deferred prop reloads, prefetch cache hits, POST→redirect flows, 409 asset-version mismatches, and the initial page load. The store keeps the latest 200 records and saves a compact summary to `sessionStorage`, so the requests from before a reload stay visible.
 
 ### oRPC capture
 
-The oRPC panel follows the same shape with its own store on `window.__STOREFRONT_DEVTOOLS_ORPC_STORE__`. Its injected client patches `window.fetch` once on load. Each request whose path starts with `/api` is recorded as one `OrpcCall`: the procedure name (the path after `/api`), the JSON input read from the request body, and on response the JSON output, the status, the duration, and any error. Every other fetch passes through untouched, and the original response or rejection always reaches the app unchanged, so the patch can never break a real request. The store caps the buffer at 200, classifies each failure as validation, server, or network, and persists a previous-session summary like the Inertia store. The wire JSON is captured as-is, not the decoded oRPC values.
+The oRPC panel follows the same shape with its own store and page script. The page script patches `window.fetch` once on load. For each request whose path starts with `/api`, it records one `OrpcCall`: the procedure name (the path after `/api`), the input from the request body, and, once the response arrives, the output, status, duration, and any error. Every other fetch passes through untouched, and the app always gets the original response or rejection, so the patch can't break a real request. The store keeps the latest 200 calls, classifies each failure as validation, server, or network, and saves a previous-session summary the way the Inertia store does. It keeps each input, output, and error in two forms: decoded to typed values, and as the raw `{ json, meta }` envelope, which the Data tab can show too.
+
+### Publishing to the panels
+
+Each page script opens its own channel (`storefront-devtools:inertia`, `storefront-devtools:orpc`) and pushes a snapshot of its store to the connected panels whenever the store changes. It sends at most one snapshot per 16 ms, so a burst of Inertia events costs one message instead of twenty. A timer paces this rather than `requestAnimationFrame`, because the browser pauses animation frames in a hidden tab, and the dock can sit in a Picture-in-Picture window while the app's tab is in the background. A panel that opens later asks for the current snapshot with `getState`. **Pause** and **Clear** reach the store the same way, as channel calls.
+
+Snapshots cross the channel through structured clone, which rejects functions, so the page scripts run captured values through `safeClone` before they store them. The channel stays inside one browser tab, so two open tabs never see each other's requests.
 
 ### Storefront context
 
-Unlike the Inertia and oRPC panels, the Storefront context panel has no capture client of its own: it reads the live Inertia page directly from the Inertia panel's store (`window.__STOREFRONT_DEVTOOLS_STORE__`), so it only shows data that store has already captured.
+Unlike the Inertia and oRPC panels, the Storefront context panel has no page script of its own. The Inertia page script serves it on a second channel, `storefront-devtools:storefront`, which carries only the current Inertia page and sends a new snapshot only when that page changes. The panel shows what the Inertia store has already captured, nothing more.
 
-### Mounting a panel into the dock
+### Panel apps
 
-Every custom-render panel (Inertia, oRPC, Storefront context) mounts through a shared `mountPanel()` helper, not a naive `dom:panel:mounted` listener. The dock's `@devframes/hub-ui` runtime switches to a panel entry and assigns its DOM element (which internally fires `dom:panel:mounted`) _before_ it `import()`s the panel's renderer module, so a listener registered inside the renderer never sees that event fire. `mountPanel()` checks the panel element synchronously first, falling back to the event listener only if it isn't set yet — the same pattern `@devframes/hub-ui` uses internally for its own iframe entries.
+The dock loads every panel as an `iframe` entry. The package builds one small Vue app for the three storefront panels and serves it, together with the Vue DevTools UI, from `/__storefront-devtools/` on the dev server. The `?view=` query picks the panel the app mounts. Each iframe is its own document, so the panel styles never touch the app, and the panel's own Vue instance stays out of the app's Vue DevTools. The dock keeps a hidden panel's iframe alive while you use another entry, and that panel keeps receiving snapshots.
 
 ## Panels
 
 ### Inertia.js panel
 
-This panel is the reason the package exists. Inertia drives navigation over XHR and swaps page props without a full reload, so the browser network tab shows you raw JSON and nothing about the visit itself. The panel reads the Inertia lifecycle directly and shows you the visit.
+Inertia drives navigation over XHR and swaps page props without a full reload, so the browser Network tab shows you raw JSON and nothing about the visit itself. This panel reads the Inertia lifecycle and shows you the visit. It's the main reason the package exists.
+
+It opens on the **Requests** tab and has a second **Page** tab. A top bar holds **Pause** and **Clear**.
 
-It opens on the **Requests** tab and has a second **Page** tab. A top bar carries **Pause** and **Clear**.
+#### Requests tab
 
-**Requests tab.** The left side lists every visit as it happens: method, URL, visit type, timing, and a badge for any diagnostics. Filter the list by type (full, partial, deferred, prefetch, redirect, client) or type a string into the URL box to narrow it. Deferred reloads nest under the visit that triggered them, so you can see which page kicked off which background load. When the buffer fills past 200 visits a footer tells you how many older ones rolled off. Reload the page and a collapsible **Previous session** block keeps the visits from before the reload, which matters because a full reload normally wipes the list. Use this tab to answer "did that click even fire a visit, and what kind."
+The left side lists each visit as it happens: method, URL, visit type, timing, and a badge for any diagnostics. Filter by type (full, partial, deferred, prefetch, redirect, client), or type into the URL box to narrow the list. Deferred reloads nest under the visit that triggered them, so you can see which page started which background load. Once the list passes 200 visits, a footer tells you how many older ones dropped off. After a reload, a collapsible **Previous session** block keeps the visits from before it, because a full reload would otherwise empty the list. This tab answers "did that click fire a visit, and what kind?"
 
-Select a visit and the right side opens its detail across four tabs:
+Select a visit and the right side shows its detail in four tabs:
 
-- **Response** — the response props actually captured for that visit, each tagged with how it arrived (full, partial, deferred, merged, prepended, or deep-merged), plus a note for any prop you requested via `only` that the response omitted, and a count of props carried over unchanged from the previous page. A **Show changes since last page** toggle switches to a before/after diff instead, marking added keys, removed keys, and changed values. This is where you confirm a partial or deferred reload returned the prop you asked for, or spot a prop that changed when it should not have.
-- **Headers** — the request and response headers actually sent and received for that visit, as a table. Credential-bearing headers (`authorization`, `cookie`, and similar) are redacted before they are ever stored.
-- **Network** — the Inertia protocol view of the request: asset version, the `only` / `except` partial-reload keys, the `errorBag` name, reset keys, plus resource timing and transfer size when the browser recorded them. Use it to verify a partial reload sent the right `only` set, or to see how long a visit actually took on the wire.
-- **Events** — a lifecycle timeline (`before`, `start`, `success`, `finish`, and the rest) with each step's offset in milliseconds from the first event, color-coded by outcome. Below it, every captured event with its full payload as a collapsible tree. This is where you debug a visit that hung, was canceled, or fired events in an order you did not expect.
+- **Response** shows the props captured for that visit, each tagged with how it arrived (full, partial, deferred, merged, prepended, or deep-merged). It notes any prop you asked for with `only` that the response left out, and counts the props carried over unchanged from the previous page. The **Show changes since last page** toggle switches to a before/after diff that marks added keys, removed keys, and changed values. Use it to confirm a partial or deferred reload returned the prop you asked for, or to spot a prop that changed when it shouldn't have.
+- **Headers** shows the request and response headers of that visit as a table. The store redacts credential headers (`authorization`, `cookie`, and similar) before it saves anything.
+- **Network** shows the Inertia protocol side of the request: asset version, the `only` / `except` partial-reload keys, the `errorBag` name, reset keys, and resource timing and transfer size when the browser recorded them. Use it to check that a partial reload sent the right `only` set, or to see how long a visit spent on the network.
+- **Events** shows a lifecycle timeline (`before`, `start`, `success`, `finish`, and the rest) with each step's offset in milliseconds from the first event, colored by outcome. Below the timeline sits every captured event with its full payload as a collapsible tree. Come here to debug a visit that hung, got canceled, or fired events in an order you didn't expect.
 
-The detail header also carries **Copy as Markdown**, which copies the visit (header, features, error, and the raw page JSON) to your clipboard for pasting into an issue or an AI chat.
+The detail header also has **Copy as Markdown**, which copies the visit (header, features, error, and the raw page JSON) for pasting into an issue or an AI chat.
 
-Above the tabs, the detail shows an overview (method, URL, type, status, component, duration, and the redirect URL on a 409), the active **feature badges**, and any **diagnostics**.
+Above the tabs, the detail shows an overview (method, URL, type, status, component, duration, and the redirect URL on a 409), the active feature badges, and any diagnostics.
 
-**Feature badges** mark the Inertia features active on a visit: partial reload, deferred props, the merge / deep-merge / prepend strategies, scroll regions, once props, prefetch, cached (a prefetch hit that skipped the network), flash data, remembered state, encrypted history, and clear-history. Click a badge to expand its description and a link to the matching Inertia docs, so you do not need to remember what each one means.
+#### Feature badges
 
-**Diagnostics** flag common mistakes on a visit: an asset-version mismatch that forced a 409 reload, a canceled or interrupted visit, a partial-reload prop you requested but the response omitted, validation errors dropped because an `only` option left out `errors`, deferred props that failed to load, and a same-URL history replace. Each links to the relevant docs.
+Feature badges mark the Inertia features active on a visit: partial reload, deferred props, the merge, deep-merge, and prepend strategies, scroll regions, once props, prefetch, cached (a prefetch hit that skipped the network), flash data, remembered state, encrypted history, and clear-history. Click a badge to see its description and a link to the matching Inertia docs, so you don't have to remember what each one means.
 
-**Page tab.** The current page props as a collapsible tree, with the page-level feature badges. Use it to inspect the props your component is rendering right now, separate from any one visit.
+#### Diagnostics
 
-**Pause** stops capture so a busy page stops flooding the list while you read a visit. Resume picks up new visits from that point. **Clear** empties the list. Your active tab and list filter persist across panel reopens, the URL search does not.
+Diagnostics flag common mistakes on a visit: an asset-version mismatch that forced a 409 reload, a canceled or interrupted visit, a partial-reload prop you requested that the response left out, validation errors lost because an `only` option didn't include `errors`, deferred props that failed to load, and a history replace to the same URL. Each one links to the relevant docs.
+
+#### Page tab
+
+The Page tab shows the current page props as a collapsible tree, with the page-level feature badges. Use it to inspect the props your component renders right now, apart from any single visit.
+
+#### Pausing and clearing
+
+Pause stops capture, so a busy page doesn't flood the list while you read a visit. Resume picks up new visits from that point. Clear empties the list. The panel keeps your active tab and list filter when you reopen it, but not the URL search.
 
 ### oRPC panel
 
-The Storefront Application V3 mutates state through oRPC calls to `/api`: add to basket, toggle wishlist, apply a promotion, run a search. In the browser network tab these all look like identical POSTs to `/api`, with the procedure buried in the request body. This panel reads them as oRPC calls and labels each by its procedure.
+The Storefront Application V3 changes state through oRPC calls to `/api`: add to basket, toggle wishlist, apply a promotion code, run a search. In the browser Network tab they show up as POST requests with a JSON envelope for a body, mixed in with everything else the page loads. This panel shows them as oRPC calls, labeled by procedure.
 
-It opens on the **Calls** tab and has a second **Stats** tab. A top bar carries **Pause** and **Clear**.
+It opens on the **Calls** tab and has a second **Stats** tab. A top bar holds **Pause** and **Clear**.
 
-**Calls tab.** The left side lists every oRPC call as it fires: method, procedure (`basket/add`, `wishlist/remove`, and so on), a status badge colored green for success, amber for a validation error, red for a server or network error, and the duration. Filter the list by domain (the first path segment, `basket`, `wishlist`, `search`) or type a string into the box to match the procedure. A collapsible **Previous session** block keeps the calls from before a reload.
+#### Calls tab
 
-Select a call and the right side opens its detail across two tabs:
+The left side lists each oRPC call as it fires: method, procedure (`basket/add`, `wishlist/remove`, and so on), a status badge, and the duration. The badge is green for success, amber for a validation error, and red for a server or network error. Filter by domain (the first path segment, such as `basket`, `wishlist`, or `search`), or type into the box to match a procedure. A collapsible **Previous session** block keeps the calls from before a reload.
 
-- **Data** — the request input as a collapsible tree, and the success output as a collapsible tree, or, when the call failed, the **Error** with its oRPC code, status, message, and data. A streaming response shows a note instead of a buffered body.
-- **Headers** — the request and response headers actually sent and received for that call, as a table. Credential-bearing headers and sensitive input fields (passwords, tokens, and similar) are redacted before they are ever stored.
+Select a call and the right side shows its detail in two tabs:
 
-The overview above the tabs shows the procedure, method, URL, status, duration, and the error kind when the call failed.
+- **Data** shows the request input and the success output as collapsible trees. For a failed call it shows the **Error** instead, with its oRPC code, status, message, and data. A streaming response shows a note in place of a buffered body.
+- **Headers** shows the request and response headers of that call as a table. The store redacts credential headers and sensitive input fields (passwords, tokens, and similar) before it saves anything.
 
-The detail header carries **Copy as curl**, which copies the call as a runnable `curl` command with the JSON body, for replaying the request in a terminal or pasting into an issue.
+The overview above the tabs shows the procedure, method, URL, status, duration, and the error kind for a failed call.
 
-**Stats tab.** A table of every procedure with its call count, average duration, and last duration. Sort by count to find the chatty procedure a page fires ten times, or by average to find the slow one. Use it to answer "which call is making this page feel slow."
+The detail header has **Copy as curl**, which copies the call as a runnable `curl` command with its JSON body, for replaying it in a terminal or pasting it into an issue.
 
-**Pause** stops capture while you read a call. **Clear** empties the list.
+#### Stats tab
 
-### Storefront context panel
+The Stats tab lists every procedure with its call count, average duration, and last duration. Sort by count to find the chatty procedure a page fires ten times, or by average to find the slow one.
+
+#### Pausing and clearing
 
-A read-only view of the resolved shop, country, locale, and session for the current page, plus the config public fields the SDK exposes to the client. It never renders secrets or the full session token, only what the Inertia page props already contain. Use it to confirm which shop/country/locale the app resolved for a request without hunting through page props by hand.
+Pause stops capture while you read a call. Clear empties the list.
 
-### Resource Center
+### Storefront context panel
 
-A plain iframe that embeds the Storefront documentation in the dock, so you can look something up without leaving the app or hunting for a tab.
+A read-only view of the resolved shop, country, locale, and session for the current page, plus the config public fields the SDK sends to the client. It shows only what the Inertia page props already contain, so it never renders secrets or the full session token. Use it to check which shop, country, and locale the app resolved for a request without digging through page props.
 
 ### Vue
 
-The Vue DevTools component tree and timeline, in a **Vue** dock group alongside the SCAYLE Storefront group. It runs as a standalone iframe app (not a custom-render panel like the others) connected to the host page over a `BroadcastChannel` RPC bridge, so it works without the dock owning an `<iframe>` element the applet controls directly. Replaces a separate `vite-plugin-vue-devtools` install.
+The Vue DevTools component tree and timeline, in a **Vue** dock group next to the SCAYLE Storefront group. It replaces a separate `vite-plugin-vue-devtools` install. Every panel in this package runs as an iframe app. The Vue panels load the `@vue/devtools-applet` UI, which reaches the app page over a `BroadcastChannel` RPC bridge. The storefront panels use the package's own panel app.
 
-Click-to-inspect (clicking a rendered element to jump to its component in the tree) is not included: it needs `vite-plugin-vue-inspector` wired into the app's own Vite config, which this package does not add.
+Click-to-inspect, where you click a rendered element to jump to its component in the tree, isn't included. It needs `vite-plugin-vue-inspector` in the app's own Vite config, and this package doesn't add it.
 
 ## Architecture notes
 
-Each panel that captures live app state (Inertia, oRPC) separates a framework-agnostic core (plain TypeScript, no Vue) from its Vue panel. The Inertia panel lives in `src/inertia/core` and `src/inertia/panel`. The oRPC panel mirrors it in `src/orpc/core` and `src/orpc/panel`. Both reuse shared panel UI (`TreeView`, the clipboard helper, panel styles) and shared capture-side generics (a `window`-store polling hook, a `sessionStorage` persistence helper) from `src/shared/`. The core handles capture, classification, diffing, diagnostics, and persistence, and the panel renders it. The panel styles are dark-mode only and are injected into the dock's shadow root, so they never leak into the host application.
+Each panel that captures live app state (Inertia, oRPC) splits into three parts. `src/<feature>/core/` is plain TypeScript with no Vue import, and handles capture, classification, diffing, diagnostics, and persistence. `src/<feature>/client/` is the page script: it runs the core in the app page and publishes the store over `devframe/in-page-channel`. `src/<feature>/panel/` holds the Vue components that render it. Both features share panel UI (`TreeView`, the clipboard helper, panel styles) and generic building blocks (snapshot pacing, snapshot mirroring, `sessionStorage` persistence) from `src/shared/`.
+
+The storefront panels load from `/__storefront-devtools/panels/`, one iframe per view, and the Vue DevTools UI loads from `/__storefront-devtools/vue/`. The panel styles are dark-mode only. Each panel runs in its own iframe document, so its styles never leak into the host application.
 
 ## Upstream stability
 
-`@vitejs/devtools`, `@vitejs/devtools-kit`, `@devframes/hub`, and `@devframes/hub-ui` are all pre-1.0 (`0.x`) releases. There is no published semver stability guarantee for 0.x versions of these packages — any minor version can carry a breaking change with no deprecation window, and neither project's changelog consistently flags every breaking change as such. If you upgrade any of them:
+`@vitejs/devtools` and `@vitejs/devtools-kit` are still `0.x` releases, so any minor version can ship a breaking change without a deprecation period. `@devframes/hub` and `@devframes/hub-ui` reached 1.0.0 in September 2026. If you upgrade any of them:
 
-- Check `@vitejs/devtools`'s peer range against the Vite version this repository pins — `@vitejs/devtools` 0.6.x and 0.7.x have shipped outside `vite`'s own declared peer range for `@vitejs/devtools` at times, so a newer devtools version is not automatically compatible with an older (or even the current) pinned Vite.
-- `@devframes/hub`/`@devframes/hub-ui` resolve as transitive dependencies of `@vitejs/devtools`, so a routine `pnpm update` (or a fresh install after a range widens) can move them independently of any `@vitejs/devtools` version bump you intended.
-- Re-run `pnpm exec vitest run`, `pnpm run build`, `pnpm run verify-packaging`, and a live check of all five panels in the dock after any bump — the unit tests do not exercise the dock's actual runtime, only this package's own capture/classification logic.
+- Check the peer range `@vitejs/devtools` declares against the Vite version this repository pins. `@vitejs/devtools` 0.6.x and 0.7.x have at times shipped outside the range `vite` itself declares for it, so a newer devtools version doesn't always work with the pinned Vite.
+- `@devframes/hub` and `@devframes/hub-ui` are transitive dependencies of `@vitejs/devtools`. A routine `pnpm update`, or a fresh install after a range widens, can move them without any `@vitejs/devtools` bump.
+- After any bump, run `pnpm exec vitest run`, `pnpm run build`, and `pnpm run verify-packaging` again, then open every panel in the dock. The unit tests cover this package's capture and classification logic, not the dock's runtime.
 
 ## License