@hachej/boring-workspace 0.1.13 → 0.1.14

package/docs/INTERFACES.md

@@ -35,8 +35,8 @@ commands, and default workspace plugins.
 - Filesystem data: `src/plugins/filesystemPlugin/front/data`
   - Filesystem client, hooks, event stream, and cache invalidation are plugin
     owned.
-- Data catalog: `src/plugins/dataCatalogPlugin/front` and
-  `src/plugins/dataCatalogPlugin/server`
+- Data catalog package: `@hachej/boring-data-catalog/front` and
+  `@hachej/boring-data-catalog/server`
   - Catalog rows are opened through `openSurface`; row-to-panel mapping belongs
     to the plugin resolver.
 - Server plugins: `src/server/plugins`

package/docs/PLUGIN_STRUCTURE.md

@@ -133,7 +133,7 @@ slash commands.
 ## Current Plugins
 
 - `packages/workspace/src/plugins/filesystemPlugin`
-- `packages/workspace/src/plugins/dataCatalogPlugin`
+- Data catalog package: `@hachej/boring-data-catalog` (`plugins/data-catalog/src`)
 - `apps/workspace-playground/src/plugins/playgroundDataCatalog`
 - Macro plugin example: `hachej/boring-macro` (`src/plugins/macro`)
 

package/docs/plans/ASK_USER_QUESTIONS_PLUGIN_SPEC.md

@@ -1,322 +1,190 @@
 # Ask User Questions Plugin Spec
 
-Last updated: 2026-05-08
-
-## Summary
-
-Add a blocking `ask_user` capability for agent sessions that opens a Workspace
-page named **Questions**, renders an agent-generated form, lets the user submit
-answers, and returns those answers to the waiting agent tool call.
-
-The Workspace implementation owns the page/plugin UI, form primitives, and UI
-bridge command handling. The Agent implementation owns the blocking tool runtime
-and session-level waiter. The browser must submit answers through the Workspace
-UI bridge command path, not through ad-hoc form POST semantics.
-
-## Goals
-
-- Provide an agent tool that asks the user for structured input and blocks until
-  the user answers or cancels.
-- Open or focus a Workspace page/panel named `Questions` whenever a question is
-  pending.
-- Render forms from a portable, JSON-serializable schema generated by the agent.
-- Provide primitive React UI components and hooks so app shells can render these
-  forms in a standard way.
-- Persist the single pending question per agent session across browser reloads.
-- Send submitted answers back to the waiting agent through `UiBridge.postCommand`
-  as the single user-dispatch source.
-- Keep Workspace base front/shared code package-neutral; no value imports from
-  `@boring/agent` outside allowed app composition boundaries.
+Status: implemented in `plugins/askUserPlugin`.
 
-## Non-goals
-
-- Multiple simultaneous pending questions per agent session.
-- File upload fields in the first version.
-- Full process-crash restoration of an already-blocked in-memory tool call,
-  unless the current agent session runtime already supports rehydrating waiters.
-- Using chat-stream `data-ui-command` parts as the source of truth for answers.
-- Making `pi-ask-user` the Workspace UX implementation dependency.
-
-## User flow
-
-1. Agent calls `ask_user` with title, optional context, and form schema.
-2. Server creates a pending question record for the current agent session.
-3. Agent tool blocks on an `AskUserCoordinator` waiter.
-4. Workspace receives/loads the pending question and opens or focuses the
-   `Questions` page.
-5. User fills the form and clicks Submit.
-6. Questions page calls `uiBridge.postCommand({ type: "questions.submit", ... })`.
-7. Workspace bridge server handler validates the command and records the answer.
-8. `AskUserCoordinator` resolves the waiter.
-9. Tool returns the structured answer to the agent and the agent continues.
-
-Cancel follows the same path with `type: "questions.cancel"` and returns a
-stable cancelled result to the tool caller.
+## Goal
 
-## Package placement
+Provide a Workspace-owned `ask_user` agent tool that asks the user a blocking,
+structured question in a **Questions** workbench pane and returns the browser
+answer to the waiting agent tool call.
 
-### `@boring/workspace/shared`
+The ask-user domain stays inside the plugin:
 
-Define browser-safe contracts only:
+- shared constants, types, schemas, and error codes
+- server runtime, store, routes, state publisher, and tool wrapper
+- front provider, Questions pane, client, form primitives, and surface resolver
 
-- `AskUserQuestion`
-- `AskUserFormSchema`
-- `AskUserField`
-- `AskUserAnswer`
-- `QuestionsSubmitCommand`
-- `QuestionsCancelCommand`
-- stable error codes imported from the canonical error-code enum
+Generic Workspace and Agent layers know only generic concepts:
 
-No `node:*`, no `Buffer`, no `@boring/agent` value imports.
+- Workspace attention blockers
+- generic blocker labels/actions
+- generic `openSurface` dispatch from Workspace chrome
+- generic tool execution context with the active agent `sessionId`
 
-### `@boring/workspace/plugins/questionsPlugin`
-
-New default Workspace plugin that owns:
-
-- `front/QuestionsPage.tsx`
-- `front/QuestionsPanel.tsx`
-- `front/usePendingQuestion.ts`
-- `front/primitives/QuestionForm.tsx`
-- `front/primitives/QuestionField.tsx`
-- field primitive components
-- `server/questionsBridge.ts`
-- `shared/types.ts`
-
-Plugin outputs should include at minimum:
+## Non-goals
 
-- a panel/page output for `Questions`
-- a command output or bridge binding for `questions.submit`
-- a command output or bridge binding for `questions.cancel`
-- a surface resolver if the workspace opens the page through `openSurface`
+- No progressive/draft form streaming in this PR.
+- No JSON-Schema `properties` compatibility layer.
+- No heuristic A/B fallback when schema is omitted.
+- No chat-inline form UI; chat only shows generic blocker/status affordances.
+- No ask-user-specific strings or events in `@hachej/boring-agent`.
 
-### `@boring/workspace/app/*`
+Agents must provide the final form schema up front.
 
-App composition may wire the questions plugin to `@boring/agent/server` tool
-registration APIs. This is the allowed boundary for Workspace + Agent product
-composition.
+## Tool contract
 
-### `@boring/agent/server`
+Tool name: `ask_user`
 
-Agent package should expose the blocking `ask_user` tool factory and an adapter
-interface that Workspace can satisfy:
+Input:
 
 ```ts
-interface AskUserRuntime {
-  askUser(request: AskUserRequest): Promise<AskUserToolResult>
+type AskUserToolInput = {
+  title: string
+  context?: string
+  schema: AskUserFormSchema
+  timeoutMs?: number
 }
-```
-
-Workspace app/server composition injects a runtime that stores the pending
-question and resolves through UI bridge answers.
-
-## Form schema
 
-Use a small JSON-schema-lite contract. It is serializable, easy to render in
-React, and avoids forcing Zod or another runtime validator across the shared
-browser/server boundary. A later helper may compile from Zod or JSON Schema into
-this format.
-
-```ts
 type AskUserFormSchema = {
+  wireVersion: 1
   fields: AskUserField[]
   submitLabel?: string
 }
-
-type AskUserField =
-  | {
-      type: "text"
-      name: string
-      label: string
-      required?: boolean
-      placeholder?: string
-      defaultValue?: string
-      helpText?: string
-    }
-  | {
-      type: "textarea"
-      name: string
-      label: string
-      required?: boolean
-      placeholder?: string
-      defaultValue?: string
-      helpText?: string
-    }
-  | {
-      type: "select"
-      name: string
-      label: string
-      required?: boolean
-      options: AskUserOption[]
-      defaultValue?: string
-      helpText?: string
-    }
-  | {
-      type: "multiselect"
-      name: string
-      label: string
-      required?: boolean
-      options: AskUserOption[]
-      defaultValue?: string[]
-      helpText?: string
-    }
-  | {
-      type: "checkbox"
-      name: string
-      label: string
-      defaultValue?: boolean
-      helpText?: string
-    }
-  | {
-      type: "radio"
-      name: string
-      label: string
-      required?: boolean
-      options: AskUserOption[]
-      defaultValue?: string
-      helpText?: string
-    }
-
-type AskUserOption = {
-  value: string
-  label: string
-  description?: string
-}
 ```
 
-Answer shape:
+Supported field types:
 
-```ts
-type AskUserAnswer = {
-  questionId: string
-  sessionId: string
-  values: Record<string, string | string[] | boolean | null>
-  submittedAt: string
-}
-```
+- `text`
+- `textarea`
+- `select`
+- `radio`
+- `multiselect`
+- `checkbox`
+- `number`
+
+The tool prompt explicitly instructs the model to emit this schema shape and not
+JSON Schema `properties`.
 
-Tool result shape:
+Output:
 
 ```ts
 type AskUserToolResult =
   | { status: "answered"; answer: AskUserAnswer }
-  | { status: "cancelled"; questionId: string; sessionId: string }
+  | { status: "cancelled"; questionId: string; sessionId: string; reason: AskUserCancelReason }
 ```
 
-## Persistence
+Tool errors are returned as normal tool errors when input validation fails,
+runtime limits reject the request, timeout/abort occurs, or the user cancels.
 
-Only one pending question is allowed per agent session. Creating a new pending
-question for a session that already has one should fail with a stable error code
-or replace only if an explicit future `replacePending` option is added.
+## Runtime flow
 
-Store interface:
+1. Agent calls `ask_user` with complete schema.
+2. Tool execution context provides active chat/session id when available.
+3. `AskUserRuntime.ask()` validates schema and creates one ready pending question.
+4. Store persists the question and transcript events.
+5. State publisher writes `questions.pending` into Workspace UI state.
+6. Runtime best-effort posts `openSurface { kind: "questions" }`.
+7. Questions pane renders the form from command metadata or persisted UI state.
+8. User submits/cancels through `/api/v1/questions/commands`.
+9. Server validates session/principal/token/schema and resolves the in-process waiter.
+10. Agent receives answered/cancelled result.
 
-```ts
-interface AskUserStore {
-  getPending(sessionId: string): Promise<AskUserQuestion | null>
-  createPending(question: AskUserQuestion): Promise<void>
-  answer(questionId: string, answer: AskUserAnswer): Promise<void>
-  cancel(questionId: string): Promise<void>
-  clearPending(sessionId: string): Promise<void>
-}
-```
+Missed UI open acks or failed `openSurface` dispatch do not cancel the pending
+question. The persisted state lets browser refresh/reconnect recover.
 
-Initial implementation should provide a file-backed or existing workspace-store
-adapter. Core/cloud can later inject a DB-backed implementation.
+## Store contract
 
-Persistence requirement for v1: pending question survives browser reload and the
-Questions page can re-render it. Full server-process crash resumption of the
-blocked tool waiter is a later concern unless already provided by the current
-agent session runtime.
+`AskUserStore` owns persisted pending questions, answers, and transcript events.
+The file-backed default store is suitable for standalone/dev use and can be
+replaced by app/core/cloud storage later.
 
-## UI bridge commands
+Important invariants:
 
-The browser submits through `UiBridge.postCommand`:
+- one pending ready question per session
+- terminal states are guarded (`answered`, `cancelled`, `abandoned`)
+- writes are serialized
+- listener failures do not roll back mutations
+- transcript events never contain browser-supplied schema
 
-```ts
-uiBridge.postCommand({
-  type: "questions.submit",
-  questionId,
-  sessionId,
-  values,
-})
-```
+## Browser command security
 
-Cancel:
+Browser commands include the question id, session id, and answer token. The
+bridge validates:
 
-```ts
-uiBridge.postCommand({
-  type: "questions.cancel",
-  questionId,
-  sessionId,
-})
-```
+- command payload shape
+- stored question exists
+- session id matches
+- auth context/principal matches when configured
+- answer token matches using constant-time comparison
+- answer values match the server-stored schema
 
-Server bridge handlers must:
+Duplicate submit after answered is idempotent. Submit after cancel is rejected.
+If the runtime waiter is gone, submit abandons and returns conflict instead of
+falsely reporting answered.
 
-- validate `sessionId` and `questionId`
-- validate submitted values against the form schema
-- persist answer/cancel state
-- resolve the matching `AskUserCoordinator` waiter
-- emit/update Workspace state so the Questions page leaves pending mode
+## UI state and recovery
 
-No direct browser form route should be treated as the conceptual API. If an HTTP
-route exists underneath, it is only transport for the UI bridge.
+The plugin owns `ASK_USER_UI_STATE_SLOTS.PENDING` (`questions.pending`). Server
+plugins declare preserved UI state keys so generic Workspace routes do not import
+ask-user constants.
 
-## Questions page behavior
+Pending state shape:
 
-- Register/open a page or panel titled `Questions`.
-- Auto-open or focus when a new pending question appears.
-- Show title, context, form fields, submit button, and cancel affordance.
-- Disable submit while validation fails or command is in flight.
-- After submit, show a short answered state and return focus behavior to the
-  workspace shell if appropriate.
-- If no pending question exists, show an empty state: "No questions right now."
+```ts
+type AskUserPendingState = {
+  question: AskUserQuestion | null
+}
+```
+
+The front provider refreshes pending state on mount, window focus, visibility
+restore, and UI-command events. It does not poll continuously.
+
+## Composer blocking
 
-## Primitive UI package
+Pending ready questions add a `WorkspaceAttentionBlocker` with generic actions:
+
+```ts
+{
+  reason: "waiting_for_user_input",
+  label: "Answer the question in Questions to continue",
+  actions: [{ id: "open", label: "Open Questions" }]
+}
+```
 
-Expose primitives from Workspace front code so apps can customize the page while
-keeping standard schema behavior:
+`@hachej/boring-agent` receives only generic blocker shape/actions. Workspace
+chrome handles action ids against its richer workspace blocker metadata.
 
-- `<QuestionForm schema values onValuesChange onSubmit onCancel />`
-- `<QuestionField field value onChange error />`
-- `<QuestionSubmitButton />`
-- `<QuestionCancelButton />`
-- `useQuestionForm(schema, initialValues?)`
-- `validateQuestionValues(schema, values)`
+Policy:
 
-Primitives should be headless-enough to style, but the default Questions page
-should provide a polished complete UI.
+- normal busy chat blocks send unless native follow-up is supported
+- pending ask-user always blocks composer, even with native follow-up support
+- Stop remains clickable while blocked
+- Stop cancels the pending question for that session and closes Questions pane
 
-## `pi-ask-user` evaluation
+## App wiring
 
-`pi-ask-user` provides a native Pi `ask_user` tool with TUI overlay/inline UI,
-selection lists, freeform input, multi-select, timeout, and a useful bundled
-skill. It is good prior art and may be useful as a standalone CLI fallback.
+The ask-user plugin is not hard-wired into `createWorkspaceAgentServer()` or
+`WorkspaceAgentFront()`. Host apps install both halves explicitly:
 
-Do not make it the primary Workspace implementation because it does not provide:
+- front: pass `askUserPlugin` through the workspace `plugins` prop
+- server: pass a plugin factory that creates `createAskUserPluginBundle({ workspaceRoot, bridge })`
 
-- Workspace page/panel integration
-- generated rich React form rendering
-- Workspace persistence semantics
-- answer dispatch through `UiBridge.postCommand`
-- app-shell primitive components
+Ask-user server plugin contributes:
 
-Recommended stance:
+- `ask_user` agent tool
+- Questions routes
+- system prompt snippet
+- preserved UI state key
 
-- Use `pi-ask-user` as reference for prompt/tool ergonomics.
-- Consider optional CLI/TUI fallback for standalone `@boring/agent` mode.
-- Keep Workspace Questions plugin implementation first-party.
+The state publisher is started only when the host app installs the server plugin
+and is disposed on Fastify close.
 
-## Acceptance criteria for implementation bead
+## Tests to keep
 
-- Shared schema/types exist and are browser-safe.
-- Questions plugin registers a `Questions` page/panel.
-- Agent/session can create one pending question and block for the answer.
-- Pending question persists across browser reload.
-- Default page renders text, textarea, select, multiselect, checkbox, and radio.
-- Submit uses `UiBridge.postCommand`, not direct conceptual route dispatch.
-- Submitted values resolve the blocking tool call.
-- Cancel resolves the tool call with `status: "cancelled"`.
-- Primitive form components/hooks are exported for app-shell reuse.
-- Unit tests cover schema validation and one-pending-question enforcement.
-- Integration test or harness test covers ask -> render -> submit -> tool result.
+- schema validation limits and command payloads
+- store persistence and terminal guards
+- runtime answer/cancel/timeout/abort/orphan behavior
+- bridge auth/session/token/answer validation
+- front Questions pane submit/cancel/stop behavior
+- generic ChatPanelHost blocker action behavior
+- host app front/server plugin installation symmetry

package/docs/plans/GENERIC_EXPLORER_PLUGIN_PLAN.md

@@ -7,9 +7,9 @@ Status: draft plan. No code has moved yet.
 ## Problem
 
 Workspace currently has a good generic `DataExplorer` primitive under
-`src/front/components/DataExplorer`. The data-catalog-specific legacy wrappers
+`@hachej/boring-data-explorer/front`. The data-catalog-specific legacy wrappers
 under `src/front/components/data-catalog` have been removed; data catalog behavior
-now lives only in `dataCatalogPlugin`. Feret v2 shows the next requirement: not
+now lives only in the `@hachej/boring-data-catalog` package. Feret v2 shows the next requirement: not
 just flat/faceted database rows, but mixed project trees with
 filesystem rows, virtual DB rows, section filters, friendly labels, and domain
 open routing.
@@ -28,7 +28,7 @@ We need a cleaner ownership model:
 Create a dedicated generic explorer plugin/family:
 
 ```txt
-packages/workspace/src/plugins/explorerPlugin/
+plugins/data-explorer/src/
   index.tsx
   constants.ts
   types.ts
@@ -47,13 +47,13 @@ emit panes/outputs and own a feature contract, but they do not encode an app
 domain like files, data catalog, or Feret. Domain plugins compose it:
 
 ```txt
-dataCatalogPlugin    -> uses explorerPlugin for generic explorer rendering
-filesystemPlugin     -> may use explorerPlugin for project/friendly trees later
-Feret app plugin     -> uses explorerPlugin directly for Project Tree and Data/Feret
-future domain plugin -> uses explorerPlugin for symbols/docs/jobs/issues/etc.
+data catalog package    -> uses data explorer package for generic explorer rendering
+filesystemPlugin     -> may use data explorer package for project/friendly trees later
+Feret app plugin     -> uses data explorer package directly for Project Tree and Data/Feret
+future domain plugin -> uses data explorer package for symbols/docs/jobs/issues/etc.
 ```
 
-Do **not** put generic explorer under `dataCatalogPlugin`. That would make other
+Do **not** put generic explorer under the `@hachej/boring-data-catalog` package. That would make other
 domains depend on a data-catalog name and blur ownership.
 
 ## Target Package Shape
@@ -83,9 +83,11 @@ src/front/
   toast/
 
 src/plugins/
-  explorerPlugin/      # generic explorer feature family
-  dataCatalogPlugin/   # data catalog specialization
   filesystemPlugin/    # files/editors/tree specialization
+
+root plugins/
+  data-explorer/       # @hachej/boring-data-explorer
+  data-catalog/        # @hachej/boring-data-catalog
 ```
 
 ## Explorer Plugin API Shape
@@ -282,10 +284,10 @@ Implementation must validate adapter/mode combinations at runtime too:
 
 ## Data Catalog After Refactor
 
-`dataCatalogPlugin` becomes a specialization that composes explorer outputs:
+the `@hachej/boring-data-catalog` package becomes a specialization that composes explorer outputs:
 
 ```txt
-dataCatalogPlugin/
+@hachej/boring-data-catalog/
   index.tsx             # createDataCatalogPlugin, appendDataCatalogOutputs
   constants.ts
   types.ts
@@ -312,7 +314,7 @@ Non-responsibilities:
 
 Legacy `src/front/components/data-catalog` is removed. Consumers should use
 `createDataCatalogPlugin()` / `appendDataCatalogOutputs()` or compose
-`DataExplorer` directly until it moves to `explorerPlugin`.
+`DataExplorer` directly until it moves to the `@hachej/boring-data-explorer` package.
 
 ## Feret v2 Requirements Driving Explorer Plugin
 
@@ -356,7 +358,7 @@ filters.
 
 | Current location                              | Decision                                                                                          | Rationale                                                                                                                                            |
 | --------------------------------------------- | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `front/components/DataExplorer/*`             | Move to `plugins/explorerPlugin/*`                                                                | Generic feature family, but pane-capable and adapter-owned; multiple plugins depend on it.                                                           |
+| `@hachej/boring-data-explorer/front`       | Extracted to `plugins/data-explorer/src/front/*`                                                                | Generic feature family, but pane-capable and adapter-owned; multiple plugins depend on it.                                                           |
 | `front/components/data-catalog/*`             | Removed                                                                                           | Data-catalog naming is domain-ish; real data catalog behavior is plugin-owned already.                                                               |
 | `front/components/CommandPalette.tsx`         | Keep in `front/components`                                                                        | Generic workspace chrome over command/catalog registries, not a domain plugin.                                                                       |
 | `front/components/recent/*`                   | Keep in `front/components` for now                                                                | Generic command/catalog recent state used by CommandPalette. Could become `commandPalette` subfolder later.                                          |
@@ -374,39 +376,39 @@ filters.
 | `plugins/filesystemPlugin/front/code-editor/*`      | Keep in filesystem plugin                                                                         | File editor domain and file data hooks.                                                                                                              |
 | `plugins/filesystemPlugin/front/markdown-editor/*`  | Keep in filesystem plugin                                                                         | File editor domain and file data hooks.                                                                                                              |
 | `plugins/filesystemPlugin/front/empty-file-panel/*` | Keep in filesystem plugin                                                                   | File-specific empty panel.                                                                                                                           |
-| `plugins/dataCatalogPlugin/front/*`           | Keep plugin-owned, but import explorer from `explorerPlugin`                                      | Domain specialization.                                                                                                                               |
+| `@hachej/boring-data-catalog/front`        | Extracted to `plugins/data-catalog/src/front/*`; imports explorer from `@hachej/boring-data-explorer`                                      | Domain specialization.                                                                                                                               |
 
 ## Public API Migration
 
 Avoid breaking current consumers in the first pass.
 
-1. Add `plugins/explorerPlugin` and re-export explorer APIs from old package
+1. Add `plugins/data-explorer` and re-export explorer APIs from old package
    root names:
    - `DataExplorer` stays exported, but source moves.
    - `ExplorerRow`, `ExplorerAdapter`, `FacetConfig`, etc. stay exported with
      compatibility aliases.
-2. Keep `front/components/DataExplorer/index.ts` as a thin deprecated re-export
-   for one release if internal import churn is high.
+2. Keep any workspace compatibility re-export thin and temporary if internal
+   import churn requires it; the canonical API is `@hachej/boring-data-explorer/front`.
 3. `DataCatalog` and `DataCatalogPane` root exports are removed now; use data catalog plugin helpers instead.
-4. Move app/plugin imports to `plugins/explorerPlugin` or package-root exports.
+4. Move app/plugin imports to `plugins/data-explorer` or package-root exports.
 
 ## Implementation Beads
 
 ### Bead 1 — Explorer plugin skeleton
 
-- Add `src/plugins/explorerPlugin` with current `DataExplorer` code moved mostly
+- Add `plugins/data-explorer/src` with current `DataExplorer` code moved mostly
   intact.
 - Export compatibility aliases.
-- Update internal imports from `front/components/DataExplorer` to
-  `plugins/explorerPlugin`.
+- Update internal imports from `@hachej/boring-data-explorer/front` to
+  `plugins/data-explorer`.
 - Tests: current DataExplorer tests pass unchanged after path update.
 
 ### Bead 2 — Data catalog plugin composition
 
-- Change `dataCatalogPlugin` to import explorer APIs from `explorerPlugin`.
+- Change the `@hachej/boring-data-catalog` package to import explorer APIs from `@hachej/boring-data-explorer`.
 - Split data catalog helpers into `catalogs.ts` if useful.
 - Keep `front/components/data-catalog` removed; do not add compatibility wrappers back.
-- Tests: dataCatalogPlugin tests and public API tests.
+- Tests: data catalog package tests and public API tests.
 
 ### Bead 3 — Tree adapter design
 
@@ -441,9 +443,9 @@ filesystem tree to explorer tree` before the legacy data-catalog removal bead.
 - Do not force filesystem to depend on data catalog.
 - Do not rewrite file tree in the first bead.
 - Do not remove public exports without an explicit breaking cleanup bead.
-- Do not allow reverse imports from `explorerPlugin` into domain plugins. Add or
-  extend invariant lint so allowed direction is domain plugin -> explorerPlugin,
-  never explorerPlugin -> dataCatalogPlugin/filesystemPlugin/app plugins.
+- Do not allow reverse imports from `@hachej/boring-data-explorer` into domain plugins. Add or
+  extend invariant lint so allowed direction is domain plugin -> data explorer package,
+  never data explorer package -> data catalog package, filesystemPlugin, or app plugins.
 
 ## Acceptance Criteria