@pstdio/workbench 0.5.0 → 0.7.0

package/README.md

@@ -1,8 +1,8 @@
 # pstdio-workbench
 
-`pstdio-workbench` is the workbench composition layer for Prompt Studio. It provides a typed core for registering contributions and a React workbench for rendering those contributions.
+`pstdio-workbench` is the workbench composition layer for Prompt Studio. It provides a typed core for registering contributions and a React workbench for rendering those contributions. See the [Workbench reference](../../.pstdio/docs/references/workbench/index.md) for the full public API.
 
-## Key Concepts
+## Key concepts
 
 - **Core**: the headless workbench model created by `createWorkbenchCore()`. It owns registries, controllers, and shared state.
 - **Workbench**: the React shell rendered by `Workbench`. It reads the core and turns registered contributions into visible UI.
@@ -17,29 +17,40 @@
 
 Contributions are the workbench extension points. A module contributes capabilities into the core; the React workbench renders the current state from those contributions. Contributions are grouped by role: layout, views, resources, navigation, and supporting plumbing. Ownership metadata is documented in [Contribution Ownership](https://github.com/pufflyai/prompt-studio/blob/main/.pstdio/docs/references/workbench/contribution-ownership.md).
 
-## Public Entry Points
+## Public entry points
 
 - `@pstdio/workbench` exports the headless workbench core, registries, controllers, and contribution types.
 - `@pstdio/workbench/react` exports the React shell, view hosts, shared hooks, and `WorkbenchModuleHost` for syncing a dynamic module list into a core.
 - `@pstdio/workbench/storage` exports local-storage-backed layout and panel persistence adapters for hosts that want browser persistence with a namespace and scope.
+- `@pstdio/workbench/extensions` maps checked extension metadata into workbench contributions.
+- `@pstdio/workbench/testing` exports test fixtures and helpers.
+- `@pstdio/workbench/webview-runtime` exports the runtime used inside extension webviews.
 
-## 🏁 Layout Contributions
+## Layout contributions
 
-Layout contributions are the glue between a region and a view. They declare where a renderer appears in the shell, what config it receives, and how its placements behave — without owning any UI themselves.
+Layout contributions connect regions to views. They declare where a renderer appears, what configuration it receives, and how its placements behave. They do not render UI.
 
 ### Panels
 
-Pin a renderer to a region as a panel, editor, dashboard, inspector, status item, or overlay. Panels declare a `region`, `title`, `rendererId`, optional `resourceKinds`, optional sizing and collapsibility, and renderer-owned `config`. They do not contain render code — the shell looks the `rendererId` up in the renderer registry.
+Pin a renderer to a region as a panel, editor, dashboard, inspector, status item, or overlay. Panels declare a `region`, `title`, `rendererId`, optional `resourceKinds`, optional sizing and collapsibility, and renderer-owned `config`. They do not contain render code. The shell looks up the `rendererId` in the renderer registry.
 
 - Register with `layout.registerPanel()`
 - Set `singleton: true` for one placement total, such as a tree, sidenav, or status view.
 - Non-singleton Panels default to `reuse: "resource"`: one placement per resource URI, with no-resource opens reusing the Panel placement.
 - Set `reuse: "none"` for scratch, untitled, or transient views where every open should create a new placement.
 
+`closable` and `role` belong to an open placement, not to panel registration. Extension composition derives both from `show` and the active mode recipe. Hosts that open a panel directly can set them in `layout.openPanel(...)`.
+
+### Composition
+
+`workbench.composition.panelsFor(region)` returns the open placements, closed optional panels that can be added, and contribution ids that can be closed for `main`, `secondary`, or `side`. Use it to build panel controls that follow the active mode and resource. `sidenav` participates in extension placement but is not a tab-hosting panel region, so it is not accepted by this query.
+
+See the `pstdio-workbench/API` Storybook section for live composition queries and an extension panel that moves between `main` and `sidenav`.
+
 #### Examples
 
-- [`hello-world`](src/examples/hello-world/module.tsx) — minimal Panel pinned to `main`.
-- [`foundation`](src/examples/foundation/module.tsx) — Panels in five different regions all backed by one shared renderer.
+- [`hello-world`](src/examples/hello-world/module.tsx) has a minimal Panel pinned to `main`.
+- [`foundation`](src/examples/foundation/module.tsx) places one shared renderer in five regions.
 
 ### Placeholders
 
@@ -49,7 +60,7 @@ Empty state for regions after every Panel in that region closes. Placeholders re
 
 #### Examples
 
-- [`hello-world`](src/examples/hello-world/module.tsx) — placeholder shown in `main` when the welcome Panel is closed.
+- [`hello-world`](src/examples/hello-world/module.tsx) shows a placeholder in `main` when the welcome Panel is closed.
 
 ### Menu items
 
@@ -59,14 +70,12 @@ Surface commands in the command palette, region headers, tree context menus, or
 
 #### Examples
 
-- [`hello-world`](src/examples/hello-world/module.tsx) — main-header trailing menu item.
-- [`foundation`](src/examples/foundation/module.tsx) — menu items wired into header paths.
-
----
+- [`hello-world`](src/examples/hello-world/module.tsx) adds a trailing menu item to the main header.
+- [`foundation`](src/examples/foundation/module.tsx) adds menu items to header paths.
 
-## 👁️ View Contributions
+## View contributions
 
-View contributions are the UI itself — code that turns a placement, a tree node, or a collection into something a user sees and interacts with.
+View contributions render placements, tree nodes, and collections as interactive UI.
 
 ### Renderers
 
@@ -77,23 +86,23 @@ The React or bridge implementation for a Panel or placeholder. Renderers turn a
 
 #### Examples
 
-- [`hello-world`](src/examples/hello-world/module.tsx) — one renderer per Panel, plus a placeholder renderer.
-- [`foundation`](src/examples/foundation/module.tsx) — one renderer reused across five Panels in different regions via `config`.
-- [`renderer-types`](src/examples/renderer-types/module.tsx) — React and bridge renderers registered side by side.
-- [`keep-alive`](src/examples/keep-alive/module.tsx) — keep-alive renderer shared by attached and floating Side Panel presentations.
+- [`hello-world`](src/examples/hello-world/module.tsx) uses one renderer per Panel and one placeholder renderer.
+- [`foundation`](src/examples/foundation/module.tsx) reuses one renderer across five Panels through `config`.
+- [`renderer-types`](src/examples/renderer-types/module.tsx) registers React and bridge renderers together.
+- [`keep-alive`](src/examples/keep-alive/module.tsx) shares one keep-alive renderer between attached and floating Side Panel presentations.
 
-### Tree Renderers
+### Tree renderers
 
-A tree-shaped renderer for side-panel navigation, outlines, resource lists, and contextual hierarchies. Tree renderers expose body sections (`getBody`), optional footer nodes (`getFooter`), and lazy children (`getChildren`); nodes can carry resources, descriptions, inline actions, context menus, and `contextValue`. Placement is left to Panels — a tree renderer auto-registers a Panel renderer with the same id, so `layout.registerPanel({ rendererId: <tree id> })` plus `layout.openPanel(<tree id>)` puts the tree in any tree-hosting region.
+A tree renderer handles side-panel navigation, outlines, resource lists, and contextual hierarchies. It exposes body sections through `getBody`, optional footer nodes through `getFooter`, and lazy children through `getChildren`. Nodes can carry resources, descriptions, inline actions, context menus, and `contextValue`. A tree renderer registers a Panel renderer with the same id. Use `layout.registerPanel({ rendererId: <tree id> })` and `layout.openPanel(<tree id>)` to place it in a tree-hosting region.
 
 - Register with `renderers.registerTreeRenderer()`
 
 #### Examples
 
-- [`dashboard`](src/examples/dashboard/modules/shell/project-nav.ts) — primary tree with resource-backed nodes, footer entries, and context menus.
-- [`dynamic-modules`](src/examples/dynamic-modules/modules/explorer-module.tsx) — tree contributed by a module that can be added and removed at runtime.
+- [`dashboard`](src/examples/dashboard/modules/shell/project-nav.ts) builds the primary tree with resource-backed nodes, footer entries, and context menus.
+- [`dynamic-modules`](src/examples/dynamic-modules/modules/explorer-module.tsx) adds and removes a tree module at runtime.
 
-### Kanban Renderers
+### Kanban renderers
 
 A Notion/Linear-style data workspace registered as a renderer. Kanban renderers contribute the schema (tag definitions, grouping/ordering/display options, filter categories), the rows via `executeQuery(state)` (which receives current settings + filters so backends can push filter/sort/pagination down), and row-mutation callbacks. Like tree renderers, a kanban renderer auto-registers a Panel renderer with the same id, so the workspace is placed via `layout.registerPanel({ rendererId: <kanban renderer id> })` and opened with `layout.openPanel(...)`.
 
@@ -101,10 +110,10 @@ A Notion/Linear-style data workspace registered as a renderer. Kanban renderers
 
 #### Examples
 
-- [`kanban-renderer`](src/examples/kanban-renderer/module.tsx) — focused showcase: schema, mock rows, and renderer-owned controls.
-- [`dashboard`](src/examples/dashboard/modules/tickets/collections/ticket-data.ts) — ticket workspace integrated into the dashboard shell.
+- [`kanban-renderer`](src/examples/kanban-renderer/module.tsx) shows a schema, mock rows, and renderer-owned controls.
+- [`dashboard`](src/examples/dashboard/modules/tickets/collections/ticket-data.ts) integrates the ticket workspace into the dashboard shell.
 
-### Data Table Renderers
+### Data table renderers
 
 A dense, query-driven table backed by `@pstdio/ui/data-table`. Data table renderers keep row ids and resources outside visible values, support declarative column labels, descriptions, icons, statistics and cell renderers, and use the table's local filtering, sorting, column controls, and pagination. They auto-register a Panel renderer with the same id and can be placed in any workbench region.
 
@@ -114,7 +123,7 @@ A dense, query-driven table backed by `@pstdio/ui/data-table`. Data table render
 
 #### Examples
 
-- [`data-table-renderer`](src/examples/data-table-renderer/module.tsx) — service-health table with statistics, color scales, friendly JSON, navigation, and row actions.
+- [`data-table-renderer`](src/examples/data-table-renderer/module.tsx) builds a service-health table with statistics, color scales, formatted JSON, navigation, and row actions.
 
 ### Breadcrumb (TODO: make it a renderer as well)
 
@@ -126,10 +135,8 @@ A dense, query-driven table backed by `@pstdio/ui/data-table`. Data table render
 
 #### Examples
 
-- [`dashboard`](src/examples/dashboard/modules/shell/components/dashboard-main-header.tsx) — custom Main Panel header that places the view alongside workspace controls.
-- [`onboarding`](src/examples/onboarding/breadcrumb-module.tsx) — three-level trail synchronized with page navigation.
-
----
+- [`dashboard`](src/examples/dashboard/shared/resource-sync.ts) updates the breadcrumb trail when the open resource changes.
+- [`onboarding`](src/examples/onboarding/breadcrumb-module.tsx) keeps a three-level trail in sync with page navigation.
 
 A typical surface combines both layers: a **renderer** supplies the UI, a **Panel** places it in a region with optional `config`, and `layout.openPanel()` creates the placement the user actually sees. Pick the narrowest contribution that matches what you are adding:
 
@@ -138,7 +145,7 @@ A typical surface combines both layers: a **renderer** supplies the UI, a **Pane
 - Add a **tree renderer** for navigable hierarchy and resource discovery, and place it with a Panel.
 - Add a **placeholder** for region-level empty state, not for normal content.
 
-## 🗂️ Resource Contributions
+## Resource contributions
 
 Resource contributions define typed objects the workbench can open, route, or resolve from product data. They keep trees, navigation, and history speaking the same resource language.
 
@@ -151,8 +158,8 @@ Declare typed things the workbench can open. Resource refs carry `kind`, `uri`,
 
 #### Examples
 
-- [`renderer-types`](src/examples/renderer-types/module.tsx) — single-kind module.
-- [`navigation`](src/examples/navigation/module.tsx) — multiple kinds participating in routing.
+- [`renderer-types`](src/examples/renderer-types/module.tsx) defines a module with one resource kind.
+- [`navigation`](src/examples/navigation/module.tsx) uses several resource kinds in routing.
 
 ### Resource presenters
 
@@ -162,8 +169,8 @@ Map a Resource to the Panel instance that presents it. Presenters declare `canOp
 
 #### Examples
 
-- [`renderer-types`](src/examples/renderer-types/module.tsx) — presenter routing one resource kind to one of two Panels.
-- [`navigation`](src/examples/navigation/module.tsx) — presenters used by parsed navigation targets.
+- [`renderer-types`](src/examples/renderer-types/module.tsx) routes one resource kind to one of two Panels.
+- [`navigation`](src/examples/navigation/module.tsx) uses presenters for parsed navigation targets.
 
 ### Resource providers
 
@@ -173,9 +180,9 @@ Look up resources by kind, uri, or search input. Providers let features resolve
 
 #### Examples
 
-- [`dashboard`](src/examples/dashboard/modules/dashboard.tsx) — provider behind the ticket KanbanView.
+- [`dashboard`](src/examples/dashboard/modules/tickets/module.ts) provides ticket resources to the ticket board.
 
-## 🧭 Navigation Contributions
+## Navigation contributions
 
 Navigation contributions turn incoming locations and resolved workbench targets into concrete workbench actions. They keep URL parsing, command dispatch, view opening, and resource routing centralized.
 
@@ -187,7 +194,7 @@ Turn ingress locations into workbench targets. Parsers convert URLs or location
 
 #### Examples
 
-- [`navigation`](src/examples/navigation/module.tsx) — parses URL-like locations into typed targets.
+- [`navigation`](src/examples/navigation/module.tsx) parses URL-like locations into typed targets.
 
 ### Navigation navigators
 
@@ -195,7 +202,7 @@ Custom dispatch behavior for navigation targets. Navigators let modules extend h
 
 - Register with `navigation.registerNavigator()`
 
-## Other Contributions
+## Other contributions
 
 Supporting contributions make view, layout, resource, and navigation contributions useful. They define actions, persistence, scoping, and preferences without directly owning a workbench region.
 
@@ -207,8 +214,8 @@ Any executable workbench action. Commands are the primitive behind menus, keybin
 
 #### Examples
 
-- [`hello-world`](src/examples/hello-world/module.tsx) — command that opens a Panel.
-- [`renderer-types`](src/examples/renderer-types/module.tsx) — commands opening different placements.
+- [`hello-world`](src/examples/hello-world/module.tsx) adds a command that opens a Panel.
+- [`renderer-types`](src/examples/renderer-types/module.tsx) opens different placements with commands.
 
 ### Keybindings
 
@@ -218,8 +225,8 @@ Keyboard access to commands. Keybindings reference command ids and can include a
 
 #### Examples
 
-- [`foundation`](src/examples/foundation/module.tsx) — keybinding gated by a context key.
-- [`random`](src/examples/random/modules/random-workbench.tsx) — keybindings paired with mode-scoped commands.
+- [`foundation`](src/examples/foundation/module.tsx) gates a keybinding with a context key.
+- [`random`](src/examples/random/modules/random-workbench.tsx) pairs keybindings with mode-scoped commands.
 
 ### Context keys
 
@@ -229,8 +236,8 @@ Conditional command, menu, and keybinding behavior. Module contexts create scope
 
 #### Examples
 
-- [`foundation`](src/examples/foundation/module.tsx) — sets `foundation.host` for menu and keybinding gating.
-- [`keep-alive`](src/examples/keep-alive/module.tsx) — context key driving kept-alive subtree visibility.
+- [`foundation`](src/examples/foundation/module.tsx) sets `foundation.host` to gate menus and keybindings.
+- [`keep-alive`](src/examples/keep-alive/module.tsx) uses a context key to control kept-alive subtree visibility.
 
 ### Modes
 
@@ -240,8 +247,8 @@ Temporary bundles of contributions for workspace modes such as project, settings
 
 #### Examples
 
-- [`workbench-modes`](src/examples/workbench-modes/modules/project-mode.tsx) — switching between mode-scoped bundles.
-- [`dashboard`](src/examples/dashboard/modules/project-mode.tsx) — project and settings modes side by side.
+- [`workbench-modes`](src/examples/workbench-modes/modules/project-mode.tsx) switches between mode-scoped bundles.
+- [`dashboard`](src/examples/dashboard/modules/shell/module.tsx) defines the project mode and its navigation surfaces.
 
 ### Preference schemas
 
@@ -251,7 +258,7 @@ Typed settings contributed by a module or runtime extension. Schemas define the
 
 #### Examples
 
-- [`preferences`](src/examples/preferences/module.tsx) — schema registration with user and workspace-scoped preference values.
+- [`preferences`](src/examples/preferences/module.tsx) registers user and workspace-scoped preference values.
 
 ### Notifications
 
@@ -261,8 +268,8 @@ Toast-style messages from modules or extensions. Notifications can include comma
 
 #### Examples
 
-- [`dynamic-modules`](src/examples/dynamic-modules/modules/diagnostics-module.tsx) — diagnostics module emitting toasts.
-- [`navigation`](src/examples/navigation/module.tsx) — notification surfaced from a navigation flow.
+- [`dynamic-modules`](src/examples/dynamic-modules/modules/diagnostics-module.tsx) emits toasts from a diagnostics module.
+- [`navigation`](src/examples/navigation/module.tsx) sends a notification from a navigation flow.
 
 ### Themes
 
@@ -270,39 +277,26 @@ The React workbench owns the shared `@pstdio/ui` theme preference system through
 
 #### Examples
 
-- [`extension-themes`](src/examples/extension-themes/module.tsx) — extensions registered as workbench modules, enabled and disabled at runtime, contributing VS Code-compatible color themes that restyle the workbench chrome.
+- [`extension-themes`](src/examples/extension-themes/module.tsx) registers extensions as workbench modules that add and remove VS Code-compatible color themes at runtime.
 
 ### Terminal
 
-Terminals are a host-owned workbench surface, not extension-composed chrome. `workbench.terminal` (a core controller) owns the session registry; hosts inject how sessions actually open with `workbench.terminal.setSessionOpener(...)` — a real PTY transport in production, `createScriptedTerminalBridge` from `@pstdio/ui/terminal` in stories and the extension testbench. `createWorkbenchTerminalModule()` registers the terminal panel in the `secondary` region plus the `workbench.terminal.open` command; the panel renders the shared `Terminal` component from `@pstdio/ui/terminal`. Closing the panel kills its session; disposing the controller kills every live session.
+Terminals are owned by the host. Extensions do not compose their chrome. The `workbench.terminal` controller owns the session registry. Hosts supply a session opener through `workbench.terminal.setSessionOpener(...)`. Production uses a real PTY transport. Stories and the extension testbench use `createScriptedTerminalBridge` from `@pstdio/ui/terminal`. `createWorkbenchTerminalModule()` registers the terminal Panel in the `secondary` region and the `workbench.terminal.open` command. The Panel renders the shared `Terminal` component from `@pstdio/ui/terminal`. Closing the Panel kills its session. Disposing the controller kills every live session.
 
-Extension webviews never receive PTY handles. A webview that declares the `terminal.session` capability talks to the same session registry through serializable operations (`open`/`write`/`resize`/`kill`/`subscribe`), with output and exit events pushed over the bridge's host-event channel — `createTerminalSessionBridge(host)` from `@pstdio/sdk/extensions` wraps that protocol into a bridge the `Terminal` component accepts.
+Extension webviews never receive PTY handles. A webview with the `terminal.session` capability uses serializable `open`, `write`, `resize`, `kill`, and `subscribe` operations. The host sends output and exit events over the bridge event channel. `createTerminalSessionBridge(host)` from `@pstdio/sdk/extensions` turns that protocol into a bridge accepted by the `Terminal` component.
 
 #### Examples
 
-- [`workbench-modes`](src/examples/workbench-modes/module.tsx) — workspace mode opening the host-owned terminal panel against a scripted backend.
-- [`workbench.stories`](src/examples/workbench.stories.tsx) — `HostTerminal` story with the panel driven by `createScriptedTerminalBridge`.
-
----
+- [`workbench-modes`](src/examples/workbench-modes/module.tsx) opens the host-owned terminal Panel with a scripted backend.
+- [`workbench.stories`](src/examples/workbench.stories.tsx) drives the `HostTerminal` story with `createScriptedTerminalBridge`.
 
 Register related contributions inside one **workbench module** so they share ownership and disposal. For example, a ticket collection module usually contributes a resource kind, resource presenter, Panel, renderer, tree renderer, commands, and menu items together.
 
-## Core
-
-The core is UI-independent. It is the source of truth that modules write to and the React workbench reads from.
-A host normally creates one core, registers modules into it, and renders `<Workbench workbench={workbench} />`.
-
 ## Nomenclature
 
-- **Workbench core**: the headless object created by `createWorkbenchCore()`. It owns the registries, controllers, and shared workbench state.
-- **Registry**: a typed collection of contributions. The workbench has registries for commands, keybindings, resources, layout (Panels, placeholders, menu items), renderers (Panel renderers and tree renderers), modes, navigation, notifications, and preferences.
-- **Controller**: a stateful slice of workbench UX exposed alongside the registries — breadcrumbs, command palette open/close state, focus, history, side-panel open/close state, and session-panel mode.
 - **Contribution**: a declarative unit added to a registry, such as a command, menu item, resource kind, Panel, renderer, tree renderer, mode, or KanbanView.
 - **Workbench module**: contribution owner registered with `workbench.registerModule(module)` and removed with `workbench.unregisterModule(moduleId)`. Module disposables are tracked and disposed together. See [Contribution Ownership](https://github.com/pufflyai/prompt-studio/blob/main/.pstdio/docs/references/workbench/contribution-ownership.md).
 - **Runtime extension**: extension metadata from `pstdio-extensions` that a host maps into workbench modules at the trust boundary.
-- **Workbench**: the React frame rendered by `Workbench`. It arranges the workbench regions, command palette, panels, and session surface from the workbench core only.
-- **Region**: a named layout target. See the Regions Overview table below.
-- **Panel contribution**: a registered view definition in the layout registry. Panels declare a region, a `rendererId`, and optional renderer-owned `config`.
 - **Panel placement**: an opened instance of a Panel contribution in a region. Placements track active Panel, resource URI, title, pinned/closable flags, and placement ownership.
 - **Tree renderer contribution**: a tree-shaped renderer registered under `renderers`. Provides `getBody` (sectioned body), optional `getFooter` (flat footer node list), and `getChildren` (lazy children). Auto-registers a Panel renderer with the same id so Panels place trees through `layout.registerPanel`.
 - **Kanban renderer contribution**: a data-workspace renderer registered under `renderers`. Provides a schema, `executeQuery(state)` rows, and row-mutation callbacks. Auto-registers a Panel renderer with the same id so Panels place the workspace through `layout.registerPanel`. The presentational layer is `<KanbanRenderer>` from `@pstdio/ui`.
@@ -321,7 +315,7 @@ A host normally creates one core, registers modules into it, and renders `<Workb
 - **Notification**: a transient workbench message emitted by workbench modules or extensions. Notifications can include command-backed actions and are rendered as workbench toast chrome.
 - **Side Panel**: the project-owned carry surface controlled by `workbench.sidePanel`. It can be `attached`, `floating`, or `closed` while preserving one live host and its resource binding.
 
-## Regions Overview
+## Regions overview
 
 Workbench regions are named layout targets used by Panel contributions. They describe where a Panel belongs in the workbench; the workbench decides the exact chrome, tabs, resize handles, and visibility behavior.
 
@@ -348,7 +342,7 @@ Panels with tabs are paired with a `<panel>-header` region that the workbench re
 
 The command palette, toast notifications, and resize handles are workbench chrome, not workbench regions. Use the `RegionMap` Storybook story to see the current region placement rendered through the real `Workbench`.
 
-## Header Actions
+## Header actions
 
 Each region header renders command-backed actions from two menu paths derived from `headerLeadingMenuPath(region)` and `headerTrailingMenuPath(region)`. Nav Chrome reuses these paths under `workbenchTopHeaderLeadingMenuPath` and `workbenchTopHeaderTrailingMenuPath`. It keeps history, the breadcrumb trail, the trailing breadcrumb-action slot, and Sidenav/Secondary/Side visibility controls mounted in that order. Workbench modules can register commands and add menu actions to those paths without moving navigation into a Panel Header.
 

package/dist/composition-resolver-types-CWykPyEK.js

@@ -0,0 +1,241 @@
+const v = (e) => [.../* @__PURE__ */ new Set([e.region, ...e.allowedRegions ?? []])], _ = (e) => e.show ? Array.isArray(e.show) ? e.show : [e.show] : [], q = (e, o, s, n) => {
+  if (!o || s.resourceKind !== o.id) return !1;
+  const l = o.slots[s.slot];
+  return l ? s.extensionId !== o.extensionId && (!l.external || s.slot === "primary") ? (n.push({
+    code: "extension_resource_slot_closed",
+    message: `Slot "${s.slot}" is closed to external panels`,
+    panelId: s.panel,
+    slot: s.slot
+  }), !1) : e.composition.panels.some((r) => r.id === s.panel) ? !0 : (n.push({
+    code: "extension_panel_missing",
+    message: `Resource panel "${s.id}" names unknown panel "${s.panel}"`,
+    panelId: s.panel,
+    slot: s.slot
+  }), !1) : (n.push({
+    code: "extension_resource_slot_missing",
+    message: `Resource panel "${s.id}" names unknown slot "${s.slot}"`,
+    panelId: s.panel,
+    slot: s.slot
+  }), !1);
+}, w = (e) => {
+  const o = e.kind?.slots[e.slotName];
+  if (!o)
+    return e.diagnostics.push({
+      code: "extension_resource_slot_missing",
+      message: `Mode "${e.input.mode.id}" places unknown slot "${e.slotName}"`,
+      slot: e.slotName
+    }), [];
+  const s = e.policy.required === !0;
+  return s && o.cardinality === "many" && e.diagnostics.push({
+    code: "extension_placement_required_invalid",
+    message: `Required slot "${e.slotName}" has cardinality many; name a specific panel instead`,
+    slot: e.slotName
+  }), e.validEdges.filter((n) => n.slot === e.slotName && !e.overriddenPanels.has(n.panel)).filter((n) => n.extensionId === e.kind?.extensionId).map((n) => ({
+    panelId: n.panel,
+    slot: e.slotName,
+    policy: e.policy,
+    required: s && o.cardinality === "one"
+  }));
+}, P = (e, o) => {
+  const s = e.composition.resourceKinds.find((r) => r.id === e.context.resourceKind), n = _(o), l = n.find((r) => r.resourceKind === e.context.resourceKind);
+  if (l && o.extensionId === s?.extensionId) return l;
+  if (o.extensionId === e.mode.extensionId)
+    return n.find((r) => r.resourceKind === void 0);
+}, b = (e, o, s) => {
+  const n = e.composition.resourceKinds.find((t) => t.id === e.context.resourceKind), l = [], r = e.composition.resourcePanels.filter((t) => q(e, n, t, s)), a = {
+    ...o?.panels ?? {},
+    ...e.mode.modePanels ?? {}
+  }, i = new Set(Object.keys(a));
+  for (const [t, c] of Object.entries(o?.slots ?? {}))
+    l.push(...w({
+      diagnostics: s,
+      kind: n,
+      input: e,
+      overriddenPanels: i,
+      policy: c,
+      slotName: t,
+      validEdges: r
+    }));
+  for (const t of e.composition.panels) {
+    const c = P(e, t);
+    if (!c) continue;
+    const p = a[t.id] ?? c;
+    l.push({
+      panelId: t.id,
+      policy: p,
+      base: c,
+      required: p.required ?? c.required ?? !1
+    });
+  }
+  const u = new Set(l.map((t) => t.panelId));
+  for (const [t, c] of Object.entries(a)) {
+    if (u.has(t)) continue;
+    const p = r.find((d) => d.panel === t);
+    if (!e.composition.panels.find((d) => d.id === t) || o?.panels?.[t] && !p) {
+      s.push({
+        code: "extension_panel_missing",
+        message: `Mode "${e.mode.id}" places panel "${t}" that is not registered for the resource`,
+        panelId: t
+      });
+      continue;
+    }
+    l.push({
+      panelId: t,
+      slot: p?.slot,
+      policy: c,
+      required: c.required === !0
+    });
+  }
+  return {
+    candidates: l,
+    validEdges: r
+  };
+}, h = (e) => {
+  const o = e.base ? v(e.base) : v(e.policy);
+  return !e.base || !e.policy.allowedRegions ? o : v(e.policy).filter((s) => o.includes(s));
+}, y = (e, o, s) => {
+  if (!e.composition.panels.find((r) => r.id === o.panelId)) return;
+  const l = h(o);
+  if (!l.includes(o.policy.region)) {
+    s.push({
+      code: "extension_panel_placement_unresolvable",
+      message: `Panel "${o.panelId}" cannot be placed in region "${o.policy.region}"`,
+      panelId: o.panelId
+    });
+    return;
+  }
+  return {
+    panelId: o.panelId,
+    region: o.policy.region,
+    slot: o.slot,
+    required: o.required,
+    defaultOpen: o.required || o.policy.defaultOpen !== !1,
+    pinned: o.policy.pinned,
+    allowedRegions: l,
+    origin: o.required ? "required" : "default"
+  };
+}, g = (e, o, s) => {
+  const n = /* @__PURE__ */ new Map();
+  let l;
+  for (const r of o) {
+    const a = y(e, r, s);
+    if (a) {
+      n.has(a.panelId) || n.set(a.panelId, a);
+      continue;
+    }
+    r.required && h(r).includes("main") && (l = {
+      panelId: r.panelId
+    });
+  }
+  return {
+    requiredFallback: l,
+    resolvedByPanel: n
+  };
+}, R = (e) => Object.entries(e.regions).filter((o) => !!o[1]), $ = (e) => {
+  for (const [o, s] of R(e.persisted)) {
+    for (const n of s.order) {
+      const l = e.resolvedByPanel.get(n);
+      l && e.place({
+        ...l,
+        origin: "persisted"
+      }, l.allowedRegions.includes(o) ? o : l.region);
+    }
+    s.activePanelId && e.placed.has(s.activePanelId) && (e.activePanelIds[o] = s.activePanelId);
+  }
+}, K = (e, o) => {
+  const s = [], n = {}, l = {}, r = /* @__PURE__ */ new Set(), a = (i, u) => {
+    r.has(i.panelId) || (r.add(i.panelId), s.push({
+      ...i,
+      region: u
+    }), n[u] = [...n[u] ?? [], i.panelId]);
+  };
+  if (!e.persisted) {
+    for (const i of o.values()) i.defaultOpen && a(i, i.region);
+    return {
+      activePanelIds: l,
+      placed: r,
+      placements: s,
+      regionOrder: n
+    };
+  }
+  $({
+    activePanelIds: l,
+    persisted: e.persisted,
+    place: a,
+    placed: r,
+    resolvedByPanel: o
+  });
+  for (const i of o.values())
+    i.required && !r.has(i.panelId) && a(i, i.region);
+  return {
+    activePanelIds: l,
+    placed: r,
+    placements: s,
+    regionOrder: n
+  };
+}, k = (e) => {
+  const o = [], s = e.context.resourceKind ? e.mode.resources?.[e.context.resourceKind] : void 0;
+  if (e.context.resourceKind && !s)
+    return o.push({
+      code: "extension_mode_resource_unsupported",
+      message: `Mode "${e.mode.id}" does not accept resource kind "${e.context.resourceKind}"`
+    }), {
+      placements: [],
+      regionOrder: {},
+      activePanelIds: {},
+      addablePanels: [],
+      diagnostics: o
+    };
+  const {
+    candidates: n,
+    validEdges: l
+  } = b(e, s, o), {
+    requiredFallback: r,
+    resolvedByPanel: a
+  } = g(e, n, o), {
+    activePanelIds: i,
+    placed: u,
+    placements: t,
+    regionOrder: c
+  } = K(e, a), p = Array.from(a.values()).filter((d) => !d.required && !u.has(d.panelId)).map(({
+    panelId: d,
+    region: m,
+    allowedRegions: f,
+    pinned: x
+  }) => ({
+    panelId: d,
+    region: m,
+    allowedRegions: f,
+    pinned: x
+  })), I = new Set(p.map((d) => d.panelId));
+  for (const d of l) {
+    if (u.has(d.panel) || I.has(d.panel)) continue;
+    const m = s?.panels?.[d.panel] ?? s?.slots?.[d.slot];
+    if (!m) continue;
+    const f = y(e, {
+      panelId: d.panel,
+      slot: d.slot,
+      policy: m,
+      required: !1
+    }, o);
+    f && (p.push({
+      panelId: f.panelId,
+      region: f.region,
+      allowedRegions: f.allowedRegions,
+      pinned: f.pinned
+    }), I.add(f.panelId));
+  }
+  return {
+    placements: t,
+    regionOrder: c,
+    activePanelIds: i,
+    addablePanels: p,
+    diagnostics: o,
+    requiredFallback: r
+  };
+}, O = ["sidenav", "main", "secondary", "side"];
+export {
+  O as d,
+  k as r
+};
+//# sourceMappingURL=composition-resolver-types-CWykPyEK.js.map