[Feature request] A general per-workspace child slot for the workspace overflow menu (sidebar.workspaces.entry)

[royenheart]

Background

I'm writing a "skills manager" plugin for dsh: enable/disable skills across session > workspace > global scopes (the host side uses a rank-50 skill provider to block disabled entries, the client side reuses the skill.list RPC + a settings scope). The global settings page and the session conversation.view tab both already have existing slots.

Only the workspace scope has no suitable entry point. My approach is: add a "Manage skills" option to each workspace's three-dot overflow menu, and clicking it opens that workspace's skills panel. But after going through the client source I found there is no way for a plugin to do this.

Current state (why plugins can't do it)

1. sidebar.workspaces is a single slot (packages/client/ui-sidebar/src/client/contract/slots.ts):

   'sidebar.workspaces': { kind: 'single'; scope: 'root'; owner: SidebarSectionOwnerProps }

   The entire browse area is rendered exclusively by ui-workspace's WorkspaceBrowser.

2. WorkspaceBrowser declares only one child slot (packages/client/ui-workspace/src/client/contract/slots.ts):

   'sidebar.workspaces.directoryFlow': { kind: 'single'; scope: 'root'; owner: DirectoryFlowOwnerProps }

   It's only the "directory selection" hole, not a per-workspace row/menu extension point.

3. The workspace three-dot menu is hardcoded (ProjectRowItem in packages/client/ui-workspace/src/client/rows/Rows.tsx):

   const workspaceMenuItems = [
     { id: 'rename', label: t('rename'), icon: <IconEditOutline16 /> },
     { id: 'delete', label: t('delete.workspace'), icon: <IconTrashOutline16 />, danger: true },
   ]

   Menu takes a descriptor array (MenuItem[]), not React nodes, and there is no registration point to "append external menu items".

Conclusion: to make the workspace overflow menu extensible, currently you can only change the ui-workspace source.

Proposal: a general sidebar.workspaces.entry (list slot)

Follow dsh's existing mature conversation.view (tabs) and settings.section (settings nav) pattern, and add a list slot for workspaces:

• Plugin-side registration (label comes entirely from the plugin's own locale, zero hardcoding on the dsh side):

  ctx.slots.register({
    name: 'sidebar.workspaces.entry',
    id: 'skills-manager',
    label: t('workspace-entry'),   // the plugin's own i18n
    order: 100,
  }, (props) => <SkillsPanel workspacePath={props.workspacePath} />)

• WorkspaceBrowser side: use slots.entries() to project into menu-item descriptors, render them into the workspace three-dot menu, and on selection renderSlot(key, { workspacePath }, { only: id }) opens a modal rendering only that entry.

This way any plugin can contribute workspace menu items, with id/label/order semantics exactly matching conversation.view / settings.section.

Appendix: full implementation patch

Verified in the local deepseek-harness worktree: tsc -b tsconfig.host.json and tsc -b tsconfig.client.json both 0 errors, and all 121 ui-workspace tests pass.

1. ui-workspace — slot declaration + overflow-menu rendering

packages/client/ui-workspace/src/client/contract/slots.ts:

+/**
+ * Owner share of a per-workspace entry slot: the workspace directory path the
+ * entry's component receives when rendered from the workspace overflow menu.
+ */
+export interface WorkspaceEntryOwnerProps {
+  readonly workspacePath: string
+}
+
 declare module '@deepseek-ai/dsh-client-ui-slots' {
   interface SlotMap {
     'conversation.hero.workspace.directoryFlow': { kind: 'single'; scope: 'root'; owner: DirectoryFlowOwnerProps }
     'sidebar.workspaces.directoryFlow': { kind: 'single'; scope: 'root'; owner: DirectoryFlowOwnerProps }
+    /** Per-workspace menu entries rendered from the workspace overflow menu (declared by the WorkspaceBrowser entry). */
+    'sidebar.workspaces.entry': { kind: 'list'; scope: 'root'; owner: WorkspaceEntryOwnerProps }
   }
 }
 
 export type WorkspaceBrowserInjected = DirectoryPickingInjected & {
   ...
   createWorkspace: (input: { path: string }) => Promise<WorkspaceView>
+  /** Projected per-workspace menu entries (resolved label + id) for the overflow menu. */
+  workspaceEntryItems: () => readonly { id: string; label: string }[]
 }
 
 export type WorkspaceBrowserProps =
   PropsRuntime<'sidebar.workspaces'>
-  & PropsRenderSlots<'sidebar.workspaces.directoryFlow'>
+  & PropsRenderSlots<'sidebar.workspaces.directoryFlow' | 'sidebar.workspaces.entry'>
   ...

packages/client/ui-workspace/src/client/index.ts:

-import type { HostObservable } from '@deepseek-ai/dsh-client-ui-slots'
+import { resolveSlotLabel, type HostObservable } from '@deepseek-ai/dsh-client-ui-slots'
 ...
     createWorkspace: input => ctx.workspaces.create(input),
+    workspaceEntryItems: () => {
+      const items: { id: string; label: string }[] = []
+      for (const entry of ctx.slots.entries('sidebar.workspaces.entry')) {
+        if (entry.options.id === undefined) continue
+        items.push({ id: entry.options.id, label: resolveSlotLabel(entry.options.label) ?? entry.options.id })
+      }
+      return items
+    },
     hooks: { directoryFlow: browserFlowSource },
   })
 ...
       name: 'sidebar.workspaces',
-      children: { 'sidebar.workspaces.directoryFlow': { kind: 'single', scope: 'root' } },
+      children: {
+        'sidebar.workspaces.directoryFlow': { kind: 'single', scope: 'root' },
+        'sidebar.workspaces.entry': { kind: 'list', scope: 'root' },
+      },

packages/client/ui-workspace/src/client/rows/Rows.tsx (ProjectRowItem):

-export function ProjectRowItem({ group, onToggle, onCreate, actions, drag, t }: {
+export function ProjectRowItem({ group, onToggle, onCreate, actions, drag, extraMenuItems, onEntrySelect, t }: {
   group: GroupNode
   onToggle: () => void
   onCreate: () => void
   actions?: { rename: () => void; delete: () => void } | undefined
   drag?: WorkspaceRowDragProps | undefined
+  /** Additional per-workspace menu entries contributed by feature plugins. */
+  extraMenuItems?: readonly { id: string; label: string }[] | undefined
+  /** Select an additional entry (id from extraMenuItems). */
+  onEntrySelect?: (id: string) => void | undefined
   t: RowTranslate
 }) {
   ...
   const workspaceMenuItems = [
     { id: 'rename', label: t('rename'), icon: <IconEditOutline16 /> },
     { id: 'delete', label: t('delete.workspace'), icon: <IconTrashOutline16 />, danger: true },
+    ...(extraMenuItems ?? []).map(item => ({ id: item.id, label: item.label })),
   ]
   ...
             onSelect={(id) => {
               setMenuOpen(false)
-              if (id !== 'rename' && id !== 'delete') return
-              if (id === 'rename') actions.rename()
-              else actions.delete()
+              if (id === 'rename') {
+                actions.rename()
+                return
+              }
+              if (id === 'delete') {
+                actions.delete()
+                return
+              }
+              onEntrySelect?.(id)
             }}

packages/client/ui-workspace/src/client/WorkspaceBrowser.tsx (key spots):

 type SessionTreeProps = Pick<...> & {
   ...
   orderBy: SessionOrderBy
+  /** Projected per-workspace menu entries (resolved label + id). */
+  entryItems: readonly { id: string; label: string }[]
+  /** Open a per-workspace entry (id from entryItems) for a workspace path. */
+  openWorkspaceEntry: (workspacePath: string, id: string) => void
 }
 ...
 function SessionTree({ ..., t, entryItems, openWorkspaceEntry }: SessionTreeProps) {
   ...
               <ProjectRowItem
                 ...
+                extraMenuItems={entryItems}
+                onEntrySelect={(id) => {
+                  if (group.cwd !== undefined) openWorkspaceEntry(group.cwd, id)
+                }}
               />
 ...
 export function WorkspaceBrowser({ ..., renderSlot, workspaceEntryItems, t }: WorkspaceBrowserProps) {
   const workspaces = useWorkspaces(state => state.items)
+  const entryItems = workspaceEntryItems()
   ...
+  const [entryTarget, setEntryTarget] = useState<{ workspacePath: string; entryId: string; title: string } | null>(null)
+  const openWorkspaceEntry = (workspacePath: string, id: string) => {
+    const item = entryItems.find(entry => entry.id === id)
+    if (item === undefined) return
+    setEntryTarget({ workspacePath, entryId: id, title: item.label })
+  }
 ...
               <SessionTree
                 ...
+                entryItems={entryItems}
+                openWorkspaceEntry={openWorkspaceEntry}
 ...
       <Modal
         open={entryTarget !== null}
         onClose={() => { setEntryTarget(null) }}
         closeLabel={t('close')}
         title={entryTarget?.title ?? ''}
       >
         {entryTarget !== null && renderSlot('sidebar.workspaces.entry', { workspacePath: entryTarget.workspacePath }, { only: entryTarget.entryId })}
       </Modal>

2. apiproxy — skill.list exposes source (for scope filtering)

The skills-manager plugin needs to distinguish "global (user-level) skills" from "workspace (project-level) skills", but the existing skill.list wire projection deliberately doesn't expose source (see the original comment "provider/source vocabulary stays host-side"). This is a minimal relaxation, avoiding adding a listing RPC per scope:

--- a/packages/host/apiproxy/src/api/skills.ts
+++ b/packages/host/apiproxy/src/api/skills.ts
-/** Skill catalog row (wire projection of the host SkillSummary; provider/source vocabulary stays host-side). */
+/** Skill catalog row (wire projection of the host SkillSummary). */
 export interface SkillEntry {
   ...
   /** False marks a user-only skill ... */
   readonly modelInvocable: boolean
+  /**
+   * Host discovery source vocabulary (e.g. project-dsh, project-agents,
+   * user-dsh, user-agents, bundled, custom, runtime). Exposed so a feature
+   * plugin can distinguish globally-available skills from workspace-scoped
+   * ones without a second listing RPC.
+   */
+  readonly source: string
 }

--- a/packages/host/apiproxy/src/api/skills.schema.ts
+++ b/packages/host/apiproxy/src/api/skills.schema.ts
   modelInvocable: z.boolean(),
+  source: z.string().min(1),
 }) satisfies z.ZodType<Wire<SkillEntry>>

--- a/packages/host/apiproxy/src/api-proxy.ts
+++ b/packages/host/apiproxy/src/api-proxy.ts
             skills: skills.map(skill => ({
               name: skill.name,
               description: skill.description,
               ...skill.whenToUse === undefined ? {} : { whenToUse: skill.whenToUse },
               modelInvocable: skill.invocation.modelInvocable,
+              source: skill.source,
             })),

Implementation progress (verified locally)

• sidebar.workspaces.entry list slot + slots.entries() projection + modal rendering: landed per the patch above; tsc + 121 tests pass.
• The workspace skills panel modal has been widened (.skillsModal { width: min(760px, 92vw) }) so the toolbar's "Disable selected" etc. no longer wrap/overflow at the default 380px width.
• Skill discovery now uses skill.list's cwd branch (a workspace lists directly by path, no longer depending on an attached session); see the skill-list-source draft.
• Enforcement (disabled skills no longer appear in the model catalog) is fixed via the harness's "hard block wins across layers"; see section B of the skill-list-source draft.

Questions to confirm

1. Does this list slot + slots.entries() projection + modal rendering direction match your plan for "workspace UI extensibility"? Or is there a more suitable seam I've missed?
2. If the direction works, I'd be glad to submit an implementation PR per repo conventions (including the ui-workspace declaration/rendering + a minimal demo plugin + tests).

Related

• Existing discussion Dynamic Cordis plugins registering into list slots always sort before shipped entries (`order` ignored) #1184 "Dynamic Cordis plugins registering into list slots always sort before shipped entries" — list slots + third-party plugin contributions are already an active topic, and this proposal is of the same origin.
• Allow third-party plugins to expose their own settings namespaces to the Web plugin-configuration section #1183 "Allow third-party plugins to expose their own settings namespaces…" — same theme of "give third-party plugins a UI extension surface".

[moonquake2004]

Nice write-up — and the current-state analysis checks out. I verified against the running 0.1.0-rc.6 client bundle (dsh-client-ui-workspace/client.js): sidebar.workspaces has only the sidebar.workspaces.directoryFlow child slot, and ProjectRowItem hardcodes exactly rename / delete — the onSelect even carries a "workspaceMenuItems carries exactly these two rows today" guard, so there is indeed no way for a plugin to contribute a workspace-menu entry today.

On the proposal itself: +1 for following the conversation.view / settings.section pattern with a sidebar.workspaces.entry list slot and plugin-owned labels — it matches existing slot semantics and keeps the dsh side free of hardcoding. Two thoughts:

1. PR reality check: per the repo's CONTRIBUTING.md, external pull requests are not accepted at the moment (and GitHub Issues are disabled) — Discussions is the supported channel. I'd keep the verified patch in a fork/gist and link it here; that's what the team can act on when they allocate resources.

2. Consider splitting the two changes: the sidebar.workspaces.entry slot is a pure UI extension surface and low-risk. Exposing source on the skill.list wire projection is a different class of change — the original code deliberately kept "provider/source vocabulary stays host-side", so that's a wire-contract stability decision that deserves its own discussion and maintainer sign-off rather than riding along with the slot proposal. Separating them makes both easier to evaluate.

Also worth noting your own link to #1184 (list-slot ordering) is directly relevant — third-party entries projecting into the overflow menu will hit the same ordering semantics, so good that you're thinking about it from the start.

Solid proposal — hope the team picks it up.