[Web GUI] 侧边栏缺少『视图切换』的官方 seam —— 附纯插件形态的完整实证与提案

[RGarvel]

背景

Web GUI 左侧栏的浏览区（WorkspaceBrowser）目前只有一个内容视图。第三方插件若想提供平行视图（例如按 IM 渠道分组的会话视图，见 discussions/3897 与 RFC-0001），没有任何官方注册面可用——sidebar.footer.action 等 slot 只能追加控件，不能与既有视图并列切换。

我们以纯插件形态做了完整实证（RGarvel/dsh-channel-view，README 有演示截图），不改宿主确实能拼出来，但代价全部落在对宿主实现细节的逆向锚定上。

实证做了什么

• 从 sidebar.footer.action 拿 wide 状态，用 react-dom portal 在 WorkspaceBrowser 的 sectionHeader（官方「工作区」标题处）注入 [工作区 | Channels(n)] tab 对；
• Channels 视图对官方 DOM 做路径剪枝（隐藏非锚点兄弟），实现与官方视图互斥切换；
• 折叠（rail）态收束为单个图标注入 sectionHeader，点击转发到宿主 toggle 按钮展开；rail 图标的 hover 语言（36px 圆底 + --dsw-alias-interactive-bg-hover + 指示点）靠补挂 class 与宿主原生图标对齐。

过程中暴露的具体缺口（每条都是真实踩过的坑）

1. 锚点脆弱：定位依赖 css-modules 类名后缀（[class*="sectionHeader"]、[class*="newSession"]…）与标题文案（「工作区」/Workspaces）。宿主任何 UI 重构（文案换词、组件拆分、rail 改版）都会静默打断注入，插件只能靠 2s 看门狗轮询自救；
2. wide/rail 双态：官方 sectionLabel 是 wide && 条件渲染，折叠↔展开切换中标题元素整体重挂载，注入节点会以孤儿子树残活在 sectionHeader 里，产生双标题/双 tab——需要自行实现 isConnected 判活重装（宿主内部无此压力，外部必踩）；
3. 折叠无归宿：宿主 rail 的图标列没有给「插件视图」预留任何位置或约定（图标、tooltip、计数徽标、互斥点亮），插件只能抢注 sectionHeader 首位；
4. 展开无 API：footer 视图槽只下发 wide，不给上抛「请展开侧边栏」的回调（WorkspaceBrowser 内部的 expandSidebar 未对外暴露），插件只能 querySelector 伪造点击宿主 toggle 按钮；
5. 窄栏文本挤压：容器宽度自适应未考虑注入内容，CJK 标签会逐字竖排（我们已加 nowrap 自救，但这是宿主该提供的约束）。

提案：两个最小 seam

A. 侧边栏视图注册（核心诉求）：

ctx.slots.register("sidebar.views", {
  id: "channels",
  label: () => t("…"),           // 支持 i18n
  icon: <Svg | component>,        // rail 态单图标呈现由宿主统一渲染
  order: 100,
  render: (props: { wide: boolean; requestExpand: () => void }) => …
});

宿主负责：展开态 tab 条、折叠态图标列、hover/选中语言（本次对齐的 --dsw-alias-interactive-bg-hover 等 token 直接复用）、互斥剪枝（插件只提供自己的内容，不再碰别人 DOM）。

B. requestExpand 上抛（A 的子集，若先做 A 可并入）：即便暂不开放视图注册，仅把 sidebar.footer.action 等既有槽位的 props 补一个 requestExpand()，插件就能告别 toggle 伪点击。

为什么值得宿主收编

以上 5 个坑全部源于「视图并列」这一宿主没有表达过的意图被外部实现。官方 seam 落地后，这些脆弱锚定可整体删除，第三方渠道视图（QQ/Slack/邮件……）才有稳定演进空间——这正是 discussions/3897（RFC-0001，session.header.channel 数据面）的 GUI 半边：数据面已有投影单元机制可复用，缺的就是这个展示位。

实证代码可指读：dsh-channel-view/lib/client.js（约 470 行，含全部规避手法与注释），欢迎以任何形式吸收进宿主。

[argszero]

Verified the seam gap against the alpha.1 tree (HEAD cd5ef81) — the proposal is accurate at source, and the two-seam design fits the host's existing slot conventions. First-hand plugin-ecosystem experience also supports it.

The gap is real (confirmed at source). The sidebar slot family declared in packages/client/ui-sidebar/src/client/contract/slots.ts is exactly: sidebar.brand.mark, sidebar.brand.name, sidebar.workspaces (single), sidebar.settings (single), sidebar.footer.action (list). There is no view-parallelism slot — a plugin cannot declare a sibling view that renders beside the workspace browser and switches with it. sidebar.footer.action owner props carry only wide (slots.ts:78-79): no expansion callback, so the "querySelector fake-click on the host toggle" workaround in the write-up is unavoidable today. Note expandSidebar exists only in the sidebar.workspaces owner share (slots.ts:67-69) — it is region-internal, not exposed to arbitrary plugins.

The proposal maps cleanly onto existing conventions. The host's slot shape is ctx.slots.register({ name, id, order, label }, Component) (slot-catalog.ts:2031 example for sidebar.footer.action). A sidebar.views slot adding icon (rail-state rendering — the host already owns rail geometry for brand/settings, so it can render the icon column uniformly) and a requestExpand callback (the exact expandSidebar mechanic the workspaces region already receives) is a natural generalization: the host keeps owning tab bar / rail / tooltips, the plugin supplies only its view content. That matches the existing invariant that shell-owned geometry never crosses the slot boundary.

From a plugin-author's perspective, this is the right adoption shape. I published @argszero/cordis-plugin-subagent-effort for a capability gap (tool-subagent dropping per-call reasoning effort) and upstream absorbed the whole surface natively by 0.1.2-alpha.1 — the harness demonstrably adopts plugin-validated gaps once they are proven. The proof-first pattern here (pure-plugin demo + five documented DOM-anchoring pitfalls) is the strongest form of evidence a seam request can carry: each pitfall is a concrete constraint the host would otherwise have to rediscover the hard way, and the pitfalls list reads as the acceptance test for the seam (no css-modules suffix matching, no isConnected re-mount hack, no fake clicks, no label-text coupling). Seam B (requestExpand on sidebar.footer.action) is a two-line props addition reusing the existing expand mechanic and can land independently; seam A then gives the third-party channel views (RFC-0001) a stable display seat.

One suggestion for the seam spec: the host convention takes the component as the second register argument rather than a render prop — aligning sidebar.views with that shape (register({ id, label, icon, order, ... }, Component), with { wide, requestExpand } in the owner props) would let it reuse the exact ctx.slots.inject('sidebar.views', () => ctx.slots.register(...)) lifecycle the catalog already documents, instead of introducing a parallel registration vocabulary.

[denial123789]

I incorporated the sidebar seam analysis into an independent multi-Session presentation guide: https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/architecture/multi-session-presentation-contract.md

It keeps the claim boundary explicit: current sidebar.footer.action is not a public parallel-view slot, so DOM anchors and simulated host clicks are unsupported compatibility layers. The proposed Host-owned rail/expansion contract is documented as design, not shipped behavior.