@hachej/boring-workspace 0.1.13 → 0.1.16

package/docs/plans/MACRO_PLUGIN_GENERIC_HELPERS_AUDIT.md

@@ -320,7 +320,7 @@ createDataCatalogPreset({
 });
 ```
 
-Owner: `dataCatalogPlugin`, not macro.
+Owner: the `@hachej/boring-data-catalog` package, not macro.
 
 2. **Drag payload helper**
 
@@ -328,7 +328,7 @@ Owner: `dataCatalogPlugin`, not macro.
 getDragPayload: createTextDragPayload("text/series-id", (row) => row.id);
 ```
 
-Owner: future `explorerPlugin` or `DataExplorer/adapters`.
+Owner: the future `@hachej/boring-data-explorer` package or `DataExplorer/adapters`.
 
 3. **Facet config helper**
 
@@ -406,8 +406,8 @@ Also extract generic query helper:
 toQueryString(params: Record<string, string | number | string[] | undefined>): string
 ```
 
-Owner: `explorerPlugin/adapters.ts` once created. Temporary owner can be
-`front/components/DataExplorer/adapters.ts`.
+Owner: `@hachej/boring-data-explorer/adapters.ts` once created. Temporary owner can be
+`@hachej/boring-data-explorer/front` adapter helpers.
 
 Risk: don't overfit response shape. Keep mapper hooks explicit.
 
@@ -563,7 +563,7 @@ surfaceResolverOutputs(resolvers): PluginOutput[]
 ```
 
 Owner: `front/registry/surfaceResolverHelpers.ts` or future
-`plugins/explorerPlugin/surface.ts`. Since these helpers are not explorer-only,
+`@hachej/boring-data-explorer` surface helpers. Since these helpers are not explorer-only,
 prefer `front/registry` or a new `front/surface` module.
 
 ### `data/macroSeriesData.ts`
@@ -662,7 +662,7 @@ createOpenSurfacePrompt({
 });
 ```
 
-Owner: workspace server UI-control or dataCatalogPlugin server utilities.
+Owner: workspace server UI-control or data catalog package server utilities.
 
 3. **Provisioning type**
 
@@ -851,16 +851,16 @@ Better integration opportunities:
    plugin composition.
 3. `createRestExplorerAdapter()` for `/catalog` + `/facets` endpoints.
 4. `createOpenSurfaceRowHandler()` for catalog row activation.
-5. Future `explorerPlugin` owns explorer primitives and adapter helpers;
-   `dataCatalogPlugin` composes them.
+5. The future `@hachej/boring-data-explorer` package owns explorer primitives and adapter helpers;
+   the `@hachej/boring-data-catalog` package composes them.
 
-Do not make macro depend directly on a future `explorerPlugin` if
-`dataCatalogPlugin` can provide the right data-catalog specialization. Macro
+Do not make macro depend directly on a future `@hachej/boring-data-explorer` package if
+the `@hachej/boring-data-catalog` package can provide the right data-catalog specialization. Macro
 should depend on the highest-level appropriate abstraction:
 
 ```txt
-macro series catalog -> dataCatalogPlugin plugin/factory
-macro custom project/tree explorer -> explorerPlugin plugin/factory
+macro series catalog -> data catalog package plugin/factory
+macro custom project/tree explorer -> data explorer package plugin/factory
 macro chart/deck panels -> macro-owned panels
 ```
 

package/docs/plans/PANE_TO_AGENT_CHAT_ACTIONS_SPEC.md

@@ -0,0 +1,366 @@
+# Pane to Agent Chat Actions Spec
+
+Last updated: 2026-05-08
+
+## Summary
+
+Add a first-class way for Workspace panes/plugins to send a message into the
+active visible agent chat without bypassing `ChatPanel` and `useAgentChat()`.
+
+This is separate from the `ask_user` Questions submit path. `ask_user` answers
+resolve a blocked tool through the Questions browser -> server command channel.
+Pane-to-agent chat actions are for user-triggered conversational messages such
+as "Analyze this chart", "Explain this result", or "Ask the agent about this
+pane".
+
+## Problem
+
+Today panes cannot cleanly send a message into the active agent session.
+
+Current flow:
+
+- `ChatPanel` owns `sendMessage` privately through `useAgentChat()`.
+- `useAgentChat()` wraps AI SDK `useChat()` and posts to
+  `POST /api/v1/agent/chat` with `{ sessionId, message, model, thinkingLevel,
+  attachments }`.
+- `ChatPanel.handleSubmit()` delegates to AI SDK `sendMessage()` and does not
+  expose that foreground-chat path to panes.
+- While chat is submitted/streaming, the current composer behavior is owned by
+  `ChatPanel`; this plan does not invent a separate follow-up endpoint.
+- `WorkspaceAgentFront` / `ChatPanelHost` wrap chat for stream data events,
+  artifact opening, and agent -> UI commands.
+- Existing Workspace UI bridge is agent/server -> pane commands. It is not a
+  pane -> active chat message API.
+
+A pane can technically call `/api/v1/agent/chat` directly, but that is the wrong
+integration for foreground chat UX because it bypasses:
+
+- visible user bubble state
+- AI SDK `useChat()` state
+- current session selection
+- model/thinking-level selection
+- request headers
+- attachment handling and composer validation
+- streaming/busy state
+- history/persistence expectations
+
+Direct HTTP is acceptable only for intentionally headless/background agent jobs,
+not for "send this as a message in the current chat".
+
+## Goals
+
+- Let panes/plugins send a message into the active visible agent chat.
+- Preserve `ChatPanel` as the owner of foreground chat send behavior.
+- Preserve current session, model, thinking level, request headers, attachments,
+  visible bubbles, busy-state behavior, and persistence behavior.
+- Expose a stable Workspace-facing hook/helper for panes.
+- Support plugin/module-graph boundaries with an event fallback.
+- Keep Workspace base front/shared code package-neutral where required; app/front
+  composition may import documented `@boring/agent/front` APIs.
+
+## Non-goals
+
+- Replacing `useAgentChat()` or changing the agent chat transport.
+- Making panes call `/api/v1/agent/chat` directly for foreground chat.
+- Implementing a new follow-up queue or `/followup` route in v1.
+- Using this path for `ask_user` form submission.
+- Background/headless agent jobs.
+- Multi-agent routing or sending to arbitrary non-active sessions in v1.
+
+## Architecture
+
+Use both an imperative controller and a browser event helper:
+
+1. `ChatPanel` exposes an `AgentChatController` that wraps its existing visible
+   composer send path.
+2. Workspace app/front composition stores the active controller near
+   `WorkspaceAgentFront`.
+3. Panes call a stable hook/helper such as `useAgentActions().sendMessage(...)`.
+4. Plugins that cannot reliably share React context may call
+   `postAgentMessage(...)`, which dispatches a browser event caught by the same
+   Workspace app/front bridge and forwarded to the active controller.
+
+## Export/API placement
+
+- `AgentChatController`, `AgentChatControllerRegistration`, and
+  `AgentChatMessageInput` should be exported as **types** from
+  `@boring/agent/front`.
+- `useAgentActions()`, `AgentActionsProvider`, and `postAgentMessage()` should be
+  exported from `@boring/workspace/app/front` because they are part of the
+  Workspace + Agent composition layer.
+- Base Workspace front/shared code must not value-import `@boring/agent`.
+- If a package-neutral Workspace type is needed, keep it structurally typed and
+  free of agent value imports.
+
+Intended imports:
+
+```ts
+import type { AgentChatMessageInput } from "@boring/agent/front"
+import { useAgentActions, postAgentMessage } from "@boring/workspace/app/front"
+```
+
+## Contracts
+
+### Agent chat controller
+
+```ts
+export interface AgentChatAttachmentInput {
+  filename?: string
+  mediaType: string
+  url: string
+}
+
+export interface AgentChatMessageInput {
+  text: string
+  files?: AgentChatAttachmentInput[]
+  metadata?: Record<string, unknown>
+  allowSlashCommands?: boolean
+}
+
+export interface AgentChatControllerRegistration {
+  controllerId: string
+  sessionId: string
+  controller: AgentChatController
+}
+
+export interface AgentChatController {
+  sendAgentMessage(input: AgentChatMessageInput): Promise<void>
+  canSendAgentMessage(): boolean
+}
+```
+
+`ChatPanel` owns the implementation. It should expose the controller through a
+prop such as:
+
+```ts
+interface ChatPanelProps {
+  onControllerReady?: (registration: AgentChatControllerRegistration | null) => void
+}
+```
+
+Lifecycle rules:
+
+- `ChatPanel` calls `onControllerReady(registration)` when mounted and ready.
+- `ChatPanel` calls `onControllerReady(null)` on unmount or when the active
+  controller becomes invalid.
+- Workspace stores the active controller by `controllerId` and `sessionId`.
+- Unregister clears the active controller only when `controllerId` matches the
+  currently registered controller. An old unmount must not clear a newer active
+  controller.
+- `ChatPanel` re-registers when `sessionId`, request headers, model,
+  thinking-level, or the underlying send callback changes.
+- The controller method delegates to the same path as user composer submit.
+- If chat is submitted/streaming, default v1 behavior rejects with
+  `AGENT_CHAT_BUSY` and `canSendAgentMessage()` returns false. Runtimes with an
+  explicit native follow-up capability may route busy-time user messages through
+  their documented follow-up path instead of rejecting.
+- Workspace attention blockers override native follow-up. If a pending
+  `ask_user`/Questions blocker exists for the active session,
+  `canSendAgentMessage()` returns false and `sendAgentMessage()` rejects/blocks;
+  the message must not be converted into a hidden follow-up because the active
+  tool expects a structured form answer.
+- It must not create a separate hidden chat stream.
+
+### Promise semantics
+
+`sendAgentMessage()` / `sendMessage()` promises resolve when the message is
+accepted into the visible ChatPanel send path and local user-message handling has
+completed. They do **not** wait for the assistant response stream to finish.
+
+Promise rejection is for immediate failures only:
+
+- invalid input
+- no active controller
+- stale controller
+- chat busy/submitted/streaming
+- synchronous failure while enqueueing/sending
+
+Async model/network failures after the message is accepted surface through the
+existing chat error UI and optional notifications. They are not guaranteed to
+reject the original pane promise.
+
+### Workspace agent actions
+
+Workspace app/front exposes a provider/hook for panes:
+
+```ts
+export interface AgentActions {
+  sendMessage(input: AgentChatMessageInput): Promise<void>
+  canSendMessage(): boolean
+}
+
+export function useAgentActions(): AgentActions
+```
+
+Behavior:
+
+- If no active controller exists, `sendMessage` rejects with
+  `AGENT_CHAT_CONTROLLER_UNAVAILABLE` and may show a workspace notification.
+- If the active controller changes between call start and dispatch,
+  `sendMessage` rejects with `AGENT_CHAT_CONTROLLER_STALE`.
+- If chat is busy/submitted/streaming, `sendMessage` rejects with
+  `AGENT_CHAT_BUSY`.
+- `canSendMessage()` returns false when no active chat controller is registered
+  or when the active controller reports busy/unavailable.
+- The hook sends to the active visible chat session only.
+
+### Event fallback
+
+For plugin/module graph safety, expose a same-window browser event helper:
+
+```ts
+export const AGENT_MESSAGE_EVENT = "boring:agent-message"
+
+export interface PostAgentMessageInput {
+  workspaceId?: string
+  text: string
+  metadata?: Record<string, unknown>
+  allowSlashCommands?: boolean
+}
+
+export function postAgentMessage(input: PostAgentMessageInput): boolean {
+  return globalThis.dispatchEvent(new CustomEvent(AGENT_MESSAGE_EVENT, { detail: input }))
+}
+```
+
+Event fallback is fire-and-forget. The boolean only means the browser event was
+dispatched to at least one same-window listener; it is not delivery confirmation.
+Use `useAgentActions()` when the caller needs promise feedback.
+
+Workspace app/front listens for `AGENT_MESSAGE_EVENT`, validates the payload, and
+forwards it to the active `AgentChatController`.
+
+Event rules:
+
+- Event fallback v1 is text + metadata only. Attachments are allowed through the
+  hook/controller path, not global events.
+- The event is for trusted same-origin plugin code only. It is not a security
+  boundary.
+- The event is same-window only and does not cross tabs by default.
+- `workspaceId` routes events when multiple Workspace shells are mounted in one
+  window. If omitted and more than one active controller exists, Workspace
+  rejects/ignores the event as ambiguous and may show a notification.
+- Invalid payloads are ignored with a developer-facing warning.
+- If no controller is active, Workspace shows a non-fatal notification such as
+  "No active agent chat is available."
+- Event sends are subject to the same busy-state rejection and debounce/rate
+  limiting as hook sends.
+
+## Pane usage
+
+Preferred React usage:
+
+```tsx
+function ChartPane({ chartId }: { chartId: string }) {
+  const agent = useAgentActions()
+
+  return (
+    <Button
+      disabled={!agent.canSendMessage()}
+      onClick={() =>
+        agent.sendMessage({
+          text: `Analyze this chart: ${chartId}`,
+          metadata: { source: "chart-pane", chartId },
+        })
+      }
+    >
+      Ask agent
+    </Button>
+  )
+}
+```
+
+Event fallback:
+
+```ts
+postAgentMessage({
+  text: "Explain the selected result",
+  metadata: { source: "results-pane" },
+})
+```
+
+Do not call `/api/v1/agent/chat` directly from panes for visible chat UX. Use the
+hook or event helper so the visible chat owner remains `ChatPanel`.
+
+## Error handling
+
+Add or reuse stable Workspace/app-front error codes for:
+
+- `AGENT_CHAT_CONTROLLER_UNAVAILABLE`
+- `AGENT_CHAT_CONTROLLER_STALE`
+- `AGENT_CHAT_BUSY`
+- `AGENT_CHAT_MESSAGE_INVALID`
+- `AGENT_CHAT_SEND_FAILED`
+- `AGENT_CHAT_AMBIGUOUS_WORKSPACE`
+
+Errors should be surfaced as non-fatal UI notifications and promise rejections
+from `sendMessage()` when the caller uses the hook/controller path. Event path
+errors are notification/log only.
+
+## Security and validation
+
+- Panes can only send to the active visible chat session in v1.
+- The server remains responsible for authorization on chat requests; this plan
+  does not weaken existing auth.
+- Client-side validation should use exported constants shared with the composer
+  where possible.
+- Suggested v1 limits:
+  - `text.trim().length >= 1` unless files are present
+  - max message length matches server/chat composer limits
+  - max attachments: 20
+  - max attachment size: 5 MiB when size is knowable
+  - allowed attachment URL schemes: `blob:`, `data:`, or same-origin URLs only
+  - max attachment URL/string byte length to prevent giant data-url bypasses
+  - metadata is JSON-serializable, max depth 4, max serialized bytes 4096
+- `metadata` is client-side advisory only in v1. It is not sent to the server or
+  agent unless the caller explicitly includes it in `text`.
+- Event helper payloads must be runtime-validated before forwarding.
+- Pane-originated messages bypass slash-command parsing by default. Set
+  `allowSlashCommands: true` only when the caller intentionally wants composer
+  slash-command behavior.
+
+## Relationship to `ask_user`
+
+This plan does not change `ask_user` answer submission.
+
+- `ask_user` answer path:
+  `Questions pane -> Questions browser/server command -> AskUserCoordinator`
+- pane-to-agent chat action path:
+  `pane -> AgentChatController -> ChatPanel/useAgentChat -> visible chat`
+
+Do not use pane-to-agent chat actions to submit generated form answers. Use it
+only when the user intentionally wants to send a conversational message to the
+agent.
+
+## Acceptance criteria
+
+- `ChatPanel` exposes an `AgentChatController` lifecycle callback or equivalent
+  controller ref.
+- Workspace app/front stores the active controller by `controllerId`/`sessionId`
+  and exposes `useAgentActions()`.
+- `postAgentMessage()` event helper forwards text-only messages to the active
+  controller when unambiguous.
+- Pane calls produce visible user messages in the active chat.
+- Pane calls reject/disable while chat is submitted/streaming with
+  `AGENT_CHAT_BUSY` in v1.
+- Pane calls preserve model/thinking-level/session/request-header behavior by
+  delegating to `ChatPanel` internals.
+- Calling from a pane when no active controller exists fails gracefully with a
+  stable error/notification.
+- Plugin author docs/templates mention: foreground chat uses
+  `useAgentActions()` / `postAgentMessage()`; direct HTTP is only for
+  background/headless jobs.
+- Tests cover:
+  - controller registration/unregistration
+  - old unregister cannot clear newer controller
+  - session switch re-registers and stale controller rejects
+  - hook-based send
+  - event-based send
+  - busy/submitted/streaming rejection
+  - promise resolves on local accept/enqueue, not assistant completion
+  - unavailable controller path
+  - invalid event payload rejection
+  - multiple Workspace shells / ambiguous event routing
+  - attachment count/URL/size validation on hook path
+  - metadata size/depth validation
+  - slash-command bypass by default and opt-in behavior

package/docs/plans/README.md

@@ -2,6 +2,8 @@
 
 Active ownership records live in this folder.
 
+- `ASK_USER_QUESTIONS_PLUGIN_SPEC.md` - blocking ask-user tool + Questions workspace plugin spec.
+- `PANE_TO_AGENT_CHAT_ACTIONS_SPEC.md` - pane/plugin to active agent chat action bridge spec.
 - `GENERIC_EXPLORER_PLUGIN_PLAN.md` - generic explorer plugin shape and front/plugin ownership audit.
 - `MACRO_PLUGIN_GENERIC_HELPERS_AUDIT.md` - macro plugin audit for reusable explorer/surface/event helper extraction.
 - `PLUGIN_OUTPUTS_ISOLATION_PLAN.md` - plugin ownership and isolation plan.

package/docs/plans/archive/PLUGIN_MODEL.md

@@ -11,7 +11,7 @@
 > are superseded by generic `surface-resolver` outputs. Workspace core owns
 > only the resolver registry and `openSurface` dispatch. Filesystem path/glob
 > mapping lives in `plugins/filesystemPlugin/surfaceResolver.ts`; data catalog
-> row-to-visualization mapping lives in `plugins/dataCatalogPlugin`.
+> row-to-visualization mapping now lives in `@hachej/boring-data-catalog`.
 
 Prior status (v7.6): round-5 review patches — Step 0 sequencing (move workspace into v7.5 layout BEFORE Phase 1, not after); split plugin entrypoints (index.ts client + server.ts per plugin); strict type-only imports for cross-folder Plugin refs; cleanup pack (uiBridge dedup, EmptyFilePanel relocation, A/B parallelism tightened, TL;DR scrub, tsconfig excludes, pi-tools-migration catch-up). **Meta-rule: when files move, they go DIRECTLY to final v7.6 destinations — no intermediate placements.**
 
@@ -588,10 +588,10 @@ Use Fastify's `inject()` for in-process testing; no port binding.
 Dropping `data: DataPaneConfig` from `<ChatCenteredShell>` removed
 the one-liner ergonomics for hosts that just want a simple data
 tab with their adapter (gemini P2). Restore them via the reusable
-data catalog plugin factory exported from `@boring/workspace`:
+data catalog plugin factory now exported from `@hachej/boring-data-catalog/front`:
 
 ```ts
-import { createDataCatalogPlugin } from "@boring/workspace"
+import { createDataCatalogPlugin } from "@hachej/boring-data-catalog/front"
 import { myAdapter } from "./adapter"
 
 export const dataPlugin = createDataCatalogPlugin({
@@ -746,7 +746,7 @@ type changes. The plan does NOT delete `chatSuggestions` from
 |---|---|---|
 | **`filesystemPlugin`** | UI-only: a Files catalog (cmd palette); FileTree panel registration as `placement: 'left-tab'`; CodeEditor + MarkdownEditor panel registrations (with `filePatterns`). **No `agentTools` field** — file tools are harness substrate (see §"Tools belong with the harness, not the plugin"). | Hosts that want a chat-only UI (no file tree, no code editor opening on file click) can opt out. When excluded: file UI disappears; LLM file tools STAY (controlled separately by `disableDefaultFileTools` on `createAgentApp`). |
 
-**v6 had a `dataCatalogPlugin` second default; v6.2 cuts it.**
+**v6 had a data catalog plugin second default; v6.2 cuts it.**
 Reason (codex round-3 P1): with `recentKind` cut and no other
 filter, a generic "Data" tab couldn't unambiguously pick *which*
 catalog to display when multiple plugins contribute catalogs (e.g.,
@@ -1269,7 +1269,7 @@ agent tools and catalogs but leave a dead Files tab in the UI.
 Phase 1 step 5c retrofits `WorkbenchLeftPane` to query
 `PanelRegistry` for `placement: 'left-tab'`, sorted by
 registration order. `filesystemPlugin` contributes the Files tab;
-`dataCatalogPlugin` contributes the Data tab.
+the data catalog plugin contributes the Data tab.
 `excludeDefaults: ['filesystem']` truly removes the tab.
 
 (`'right-tab'` is reserved in the contract but no Phase 1 component
@@ -1533,7 +1533,7 @@ model**.
    │                @boring/workspace                            │
    │   • Plugin contract (definePlugin, factories)               │
    │   • Registries (Panel / Command / Catalog)                  │
-   │   • Default plugins (filesystemPlugin, dataCatalogPlugin)   │
+   │   • Default plugins (filesystemPlugin; data catalog is now external)   │
    │   • UI bridge core (moved from @boring/agent)               │
    │   • Substrate routes /api/v1/{ui,files,tree,files/search}   │
    │   • Event bus + WorkspaceEventMap                           │
@@ -1655,7 +1655,7 @@ packages/workspace/
 │   │   └── defaults/
 │   │       ├── filesystemPlugin.ts                  (imports filesystemAgentTools
 │   │       │                                         from @boring/agent)
-│   │       └── dataCatalogPlugin.ts
+│   │       └── dataCatalogPlugin.ts (historical; now external package)
 │   ├── registry/
 │   │   ├── PanelRegistry.ts                         [EXISTS — retrofitted:
 │   │   │                                             subscribable, path-aware
@@ -1878,7 +1878,7 @@ restructure; subsequent phases assume the v7.6 layout exists.
 │      registered by createAgentApp via pi-tools-migration's       │
 │      buildFilesystemAgentTools(bundle) — NOT the plugin's job.   │
 │                                                                  │
-│      (v6 had dataCatalogPlugin as a second default; v6.2 cuts    │
+│      (v6 had a data catalog plugin as a second default; v6.2 cuts    │
 │      it — plugins that want a workbench data tab contribute      │
 │      their own left-tab panel.)                                  │
 │                                                                  │
@@ -1930,7 +1930,7 @@ restructure; subsequent phases assume the v7.6 layout exists.
 │        was the original justification for the retrofit.          │
 │      - Drop `data: DataPaneConfig` prop. Hosts that want a       │
 │        workbench data tab register their own left-tab panel      │
-│        or compose the reusable `createDataCatalogPlugin(opts)`   │
+│        or compose `createDataCatalogPlugin(opts)` from `@hachej/boring-data-catalog/front`   │
 │        / `appendDataCatalogOutputs(...)` helpers.                │
 │      - Drop `extraPanels` prop. Panels come from PanelRegistry;  │
 │        new optional `allowedPanels?: string[]` for gating.       │
@@ -2056,7 +2056,7 @@ export const makeMacroServerPlugin = (): Plugin =>
 component is `DataExplorer` configured with macro's adapter and
 `onActivate` that calls `surface.openPanel({ component:
 "chart-canvas", … })`. This replaces the v5 dataPaneConfig wiring
-without needing a default `dataCatalogPlugin`. The catalog
+without needing a default data catalog plugin. The catalog
 (`seriesCatalog`) stays separate — it's what powers the cmd palette
 search; the panel is what shows the workbench browser.
 
@@ -2417,7 +2417,7 @@ apps/boring-macro-v2/src/plugin/     ← macroPlugin lives here
 - `src/components/chat/` (whole folder; Phase A + C + G)
 - Top-level `src/panes/{code-editor, markdown-editor, file-tree}/` — moved INTO
   `src/plugin/defaults/filesystemPlugin/` (panes/sidebar split per role) by j9p7.9
-- `src/panes/data-catalog/` — orphaned (dataCatalogPlugin was cut in v6.2);
+- `src/panes/data-catalog/` — orphaned (the data catalog plugin was cut in v6.2);
   audit during j9p7.30: delete if no consumer, otherwise re-home as a primitive
   in `components/` for plugin authors who want a generic data-tab implementation
 - `src/panes/EmptyPane.tsx` (loose) — moved to `chrome/EmptyPane.tsx`
@@ -3417,7 +3417,7 @@ simple hosts.** A host that just wants "a data tab with my
 adapter" had a one-liner; v6.2's "register your own left-tab
 panel" makes it ~10 lines. **Fix:** use
 `createDataCatalogPlugin` for standalone data catalog plugins, or
-`appendDataCatalogOutputs` when an app plugin needs to install
+`appendDataCatalogOutputs` from `@hachej/boring-data-catalog/front` when an app plugin needs to install
 the data catalog as part of a domain plugin. Macro uses the latter
 so chart/deck behavior stays in the macro app.
 
@@ -3474,7 +3474,7 @@ by `createWorkspaceAgentApp` rather than evaluated at module load.
 `data` prop.** With `recentKind` cut and multiple registered
 catalogs (filesystem's Files + macro's Series), nothing in the
 spec said which one fills the generic Data tab. **Fix:** drop
-`dataCatalogPlugin` from defaults entirely. There is no generic
+the data catalog plugin from defaults entirely. There is no generic
 Data tab; plugins that want a workbench data tab register their
 own `placement: 'left-tab'` panel (e.g., macro's `macroSeriesPanel`
 which internally renders DataExplorer with the macro adapter +
@@ -3516,7 +3516,7 @@ rolled back.
 
 ### Net impact (v6.1 → v6.2)
 
-- One default plugin removed (`dataCatalogPlugin`).
+- One default plugin removed (the data catalog plugin; now external).
 - Two factory shapes formalized (`createFilesystemAgentTools(deps)`
   and `makeFilesystemPlugin(deps)`).
 - Macro example honors client/server split.

package/docs/plans/archive/SRC_FOLDER_REORG_PLAN.md

@@ -87,7 +87,7 @@ src/
 │   │   ├── defaultEditorPanels.ts ← MOVED from panes/ (3 apps consume via barrel — keep)
 │   │   └── __tests__/
 │   │
-│   └── dataCatalogPlugin/      (reusable data catalog outputs + hooks)
+│   └── (moved out) data catalog package: `@hachej/boring-data-catalog`
 │
 ├── server/           (existing)
 └── shared/           (existing)
@@ -108,8 +108,7 @@ plugin with hardcoded data.
 
 `DataCatalog` belongs alongside `DataExplorer` in `front/components/` — both are
 presentational peers. Move `panes/data-catalog/*` → `front/components/data-catalog/*`.
-Apps install data catalog outputs through `createDataCatalogPlugin` or
-`appendDataCatalogOutputs`.
+Apps install data catalog outputs through `@hachej/boring-data-catalog/front` (`createDataCatalogPlugin` or `appendDataCatalogOutputs`).
 
 ---
 

package/docs/plans/archive/WORKSPACE_V2_PLAN.md

@@ -21,7 +21,7 @@ Use this section as the live handoff ledger while executing this plan.
 - Current source uses generic `surface-resolver` plugin outputs plus the
   `openSurface` UI command. Filesystem path matching belongs to
   `plugins/filesystemPlugin/surfaceResolver.ts`; data catalog row opening
-  belongs to `plugins/dataCatalogPlugin`.
+  belongs to the extracted `@hachej/boring-data-catalog` package.
 
 ### Pass 2 — Full milestone verification (2026-04-24)
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hachej/boring-workspace",
-  "version": "0.1.13",
+  "version": "0.1.16",
   "type": "module",
   "license": "MIT",
   "description": "Workspace UI, plugin, and bridge package for composing chat, files, catalogs, editors, and app-specific panes.",
@@ -119,14 +119,12 @@
     "fastify": "^5.3.3",
     "lowlight": "^3.3.0",
     "lucide-react": "^1.8.0",
-    "micromatch": "^4.0.8",
-    "radix-ui": "^1.4.3",
     "react-arborist": "^3.4.0",
     "tailwind-merge": "^2.0.0",
     "zod": "^3.23.0",
     "zustand": "^5.0.0",
-    "@hachej/boring-agent": "0.1.13",
-    "@hachej/boring-ui-kit": "0.1.13"
+    "@hachej/boring-agent": "0.1.16",
+    "@hachej/boring-ui-kit": "0.1.16"
   },
   "devDependencies": {
     "@tailwindcss/postcss": "^4.0.0",
@@ -134,7 +132,6 @@
     "@testing-library/jest-dom": "^6.9.1",
     "@testing-library/react": "^16.3.2",
     "@testing-library/user-event": "^14.6.1",
-    "@types/micromatch": "^4.0.10",
     "@types/node": "^22.15.3",
     "@types/react": "^19.0.0",
     "@types/react-dom": "^19.0.0",