提案：为插件提供工作区域与唯一原生会话伴随栏

[guanzhenxing]

一些插件需要一个完整的主工作区域，例如编辑器、笔记本、终端仪表盘、产物预览或数据分析视图；同时，用户仍应能继续使用 DSH 原生会话。

目前下游插件通常只能：

• 用 shell.overlay 覆盖页面；
• 自行实现一套缩减版聊天界面；
• 复制或深层导入 ui-conversation 的私有实现。

这些都不是稳定的扩展路径。

特别是，增加第二份 conversation 并不只是多渲染一个 React 组件。它会立即引入两个 composer、审批和提问的响应归属、附件 hub、快捷键和 document 监听、滚动状态、以及 tool details 目标等所有权问题。因此，我认为这不应作为解决“插件需要主工作区”的第一步。

现状核查：frame 层没有可追加的布局 slot

上游 ui-layout 在 root 下声明且仅声明四个子 slot，源码注释原话即 “these four are the frame's children”：

slot	kind	scope	现状
sidebar	single	root	被 ui-sidebar 的 SidebarRoot 占据；注释明言在此注册是整体替换导航列，而非追加
conversation	single	session-maybe	被 ui-conversation 的 ConversationRoot 占据
details	single	session	被 ui-conversation 的 DetailsPanel 占据
shell.overlay	list	root	唯一可追加的，但按设计是浮层（toast、badge、modal），不是布局参与者

也就是说，三个布局位全部是 single（注册即替换），唯一 additive 的 shell.overlay 不参与布局。frame 层在契约上不存在“追加式的布局 slot”——“插件占据主工作区域、原生会话退居伴随栏”不是没人做过，而是当前 slot 表里没有这个位置。

另一个容易混淆的既有 slot 是 conversation.view：ui-conversation 拥有的视图 tab 环（chat 在此，trajectory 等视图来自 ui-trajectory），插件今天就能往会话列里加一个并列 tab。但 tab 始终渲染在会话列内部，无法重排 frame 本身。它与本提案是两个层级的能力，互补而非替代。

提案

在 ui-layout 中新增三个 root-scope list slot：shell.workArea、shell.workArea.companionHeader 与 shell.workArea.footer。

当某个工作区域激活时，AppFrame 将已有的、唯一的原生 conversation 布局为工作区域旁的伴随栏；没有活动工作区域时，现有 DSH 页面和布局保持不变。

建议的公开接口：

interface ILayout {
  openWorkArea(id: string, options?: {
    conversationVisible?: boolean  // 伴随栏初始是否可见，默认 true
    sidebarVisible?: boolean       // 侧栏初始是否可见，默认 true；false 时侧栏完全收起
  }): void
  closeWorkArea(id: string): void
  setWorkAreaConversationVisible(id: string, visible: boolean): void
  setWorkAreaSidebarVisible(id: string, visible: boolean): void
  setWorkAreaCompanionWidth(id: string, px: number): void  // 伴随栏程序化调宽，等效于拖动手柄
  setWorkAreaReserve(id: string, px: number): void  // 声明工作区域实际需要的最小宽度；未声明为契约默认 400px
}

建议的行为语义：

• 插件以稳定 ID 注册工作区域；同一时刻只显示一个活动工作区域。
• 打开未知 ID 应快速失败。
• 关闭、设置可见性、伴随栏调宽、插件卸载和 HMR 重注册均以 ID 防止陈旧回调影响新注册项。
• AppFrame 统一负责列宽、拖拽、响应式让步、伴随栏显隐、侧栏收起与恢复，以及 details 的显示位置。
• setWorkAreaCompanionWidth 是拖动手柄的程序化等价物：请求值只钳伴随栏下限，没有固定上限；渲染时由 frame 的列宽让步链按视口与工作区域保留宽度收敛，过大请求落到“能放下多宽就是多宽”。
• setWorkAreaReserve 声明活动工作区域实际需要的最小宽度：列宽让步链与伴随栏拖拽上限都以声明值为工作区域保底。未声明时保持 400px 契约默认；打开、关闭与工作区域切换时复位，写入钳为非负整数。动机：工作区把自己收起成一条细边（例如编辑器让位给伴随栏）时，固定 400px 下限会让伴随栏永远到不了全宽，留下一段无法使用的空白。
• conversation 保持单一声明者，并且最多只有一个挂载实例。
• 工作区域激活期间，会话拥有的交互——审批、ask_user_question、附件投放、快捷键与 document 监听、滚动状态、tool details 目标——全部归属此刻作为伴随栏渲染的同一个原生 conversation；工作区域不声明、不复制、不拦截其中任何一项。布局重组不产生这些状态的第二份，这正是坚持单一声明者 / 单挂载的直接收益。
• 隐藏伴随栏时，不保留零宽但仍可交互的 conversation / details DOM 树（两者一并卸载而非挂空）。
• 再次显示时复用同一个原生会话注册项与 session-scope store；会话和草稿继续存在，但纯 DOM 级滚动或焦点可以重置。
• 在普通会话与可见伴随栏之间切换只改变网格布局，不重新挂载 conversation 树。
• 隐藏侧栏时不修改用户已保存的侧栏偏好，关闭工作区域后恢复原状。
• details 始终与唯一的原生 conversation 配对，不能显示在工作区域背后。
• shell.workArea.companionHeader 是伴随栏顶部的一行插件自定义控件区：条目以自己的工作区域 ID 注册，frame 只渲染当前活跃 ID 对应的条目。框架本身不提供任何内置控件；收起、新建会话等按钮由各工作区域自带。没有条目注册时这里不渲染任何内容，界面与上游一致。
• shell.workArea.footer 是工作区域底部的横条插件内容区，横跨工作区域主列与伴随栏；伴随栏隐藏时它仍随工作区域渲染（底条属于工作区域而非对话）。条目同样以工作区域 ID 注册，框架不提供内置内容；没有条目注册时该行为零高度，界面与上游一致。典型用途：插件状态栏铺满工作区与伴随栏整条底部，而不只盖住自己的主列。
• shell.overlay 保持现有语义，仅用于 toast、badge、modal 等真正的浮动内容。

为什么不是第二个 ConversationSurface 或任意 SlotOutlet

本提案不请求：

• 第二个 ConversationSurface；
• 任意 SlotOutlet；
• 导出私有 conversation React 组件；
• 放宽现有 slot 的声明或渲染授权模型。

工作区域需求本质上是宿主布局的组合问题。由 ui-layout 重新安排唯一原生 conversation 的位置，可以保留当前的 one-declarer 和单挂载模型，不必扩张 ui-slots、ui-renderer、ui-conversation 的生命周期语义。companion header 同样只是一个随工作区域激活而显示的普通 list slot，不引入新的授权机制。

如果未来确实出现编辑器、弹窗或多窗口之间可移植 conversation surface 的跨领域需求，应单独设计其生命周期和所有权，而不是由本用例隐式放宽现有约束。

参考实现

我在 fork 中维护着一个不含产品品牌、不含业务逻辑的参考实现。本版更新：采纳评论区 @weijiafu14 的三点建议——frame 层 slot 现状核查、与 conversation.view 的区分、会话交互归属的预先回答；API 先后新增伴随栏程序化调宽 setWorkAreaCompanionWidth、底部横条槽 shell.workArea.footer 与可让渡底线 setWorkAreaReserve，并同步参考实现统计：

• 分支：dsh-work-area/main
• 与上游 master 的完整比较：17 commits · 20 files changed · +1337/−62
• 核心功能与测试位于 packages/client/ui-layout（AppFrame 布局、service 控制 API、stores 状态、columns 列宽分配）；其余提交为契约文档、slot catalog 再生成，以及 fork 自用的制品发布 workflow，均不依赖核心改动之外的新机制。

实现范围包括：

1. ui-layout

   • shell.workArea、shell.workArea.companionHeader、shell.workArea.footer 与 ILayout 六个控制方法；
   • 活动工作区域、伴随栏/侧栏可见性、伴随栏宽度、让渡底线和注册项生命周期的状态管理；
   • AppFrame 的工作区域 / 原生会话伴随栏 / 隐藏侧栏 / 底部横条的布局；
   • 列宽、拖拽、响应式让步和 details 位置。

2. 生命周期与行为测试

   • 未知 ID；
   • 打开、关闭、隐藏和重新显示（伴随栏与侧栏分别验证）；
   • 伴随栏宽度与让渡底线（拖拽上限、程序化写入、reserve 声明与生命周期复位、陈旧 ID 忽略）；
   • 工作区域卸载；
   • 同 ID 的 HMR 重注册；
   • 原生 conversation 最多单挂载；
   • 隐藏时不存在可交互的零宽 conversation/details 树；
   • 伴随栏顶部与底部横条都只渲染当前工作区域自己的条目；
   • details 目标与列布局状态。

关键代码入口：

• ui-layout/AppFrame.tsx
• ui-layout/service.ts
• ui-layout/stores.ts

这个分支用于证明 API 和行为边界的可行性，并不要求维护者原样合并。若方向被接受，我愿意按维护者建议拆分提交、调整命名和 API，或移除与核心提案无关的独立改动。

[weijiafu14]

你对"加第二份 conversation 会带来什么"的分析是对的（两个 composer、审批与提问的响应归属、附件 hub、快捷键与 document 监听、滚动状态、tool details 目标），这些正是不该走那条路的理由。

补一份实测的座位清单给你的提案当证据——我为了别的事把 DSH 客户端包里的 SlotMap 声明合并全读了一遍（ui-layout / ui-conversation / ui-settings / ui-input-trigger / ui-sidebar）。frame 这一层的座位一共只有四个：

座位	kind	scope	现状
sidebar	single	root	被 ui-sidebar 的 SidebarRoot 占着
conversation	single	session-maybe	被 ui-conversation 的 ConversationRoot 占着
details	single	session	被 ui-conversation 的 DetailsPanel 占着
shell.overlay	list	root	唯一可加的，但它是浮层——点击穿透、在各列滚动容器之外

也就是说：frame 层没有任何"追加式的布局座位"。三个布局位全是 single，注册进去等于替换（sidebar 的注释原话是"registering here replaces the navigation column outright rather than adding to it, and the seats it declares disappear with it"）；唯一 additive 的 shell.overlay 按设计就是浮层，不是布局参与者。

这正是你提案要填的洞，而且可以说得更硬一点：这不是"没人做过"，是契约上就没有这个位置。

两点可能对提案有用的补充：

1. conversation.view 是个 list 座位（"会话视图环：每个视图 tab 一个 list 条目，chat 在此、trajectory/waterfall 来自 ui-trajectory"）。所以"在会话列里加一个并列的视图 tab"今天就能做——但那是会话列内部的 tab，不是你要的"整页工作区 + 会话作为伴随栏"。值得在提案里点明这个区别，否则会被回成"用 conversation.view 不就行了"。
2. 你的 ILayout 接口里 conversationVisible / sidebarVisible 这两个开关是对的方向。补一个会被追问的点：工作区域激活时，审批弹窗、ask_user_question、附件投放这些"会话拥有"的交互落在哪一侧？你自己已经列出了这些归属问题——在提案里先给出答案（比如"仍然全部归伴随栏的那一份 conversation 所有，工作区域不参与"），会比留给评审去问更顺。

边界：这条得官方开，我们改不了 ui-layout 的座位表。上面全是可以自己 npm pack 那几个包、读 SlotMap 声明复核的事实。

利益相关：我维护 pi2dsh 和一个装了 Web 管理 tab 的插件——我们那个 tab 走的正是"在既有座位里加东西"，恰恰没解决你提的这个问题，所以这条回复里没有任何要你装的东西。

[guanzhenxing]

三点建议都已写入正文：frame 层 slot 现状表（已对源码复核，与你的引述一致）、与 conversation.view 的区分、以及会话交互归属的答复——审批、提问、附件、快捷键、滚动、tool details 全部仍归唯一的原生 conversation。

参考实现也同步了：ILayout 新增 setWorkAreaCompanionWidth（伴随栏程序化调宽），现为 13 commits · +1132/−60。

谢谢这份核查——“契约上就没有这个位置”比我原文的表述准确。