按来源渠道/插件对会话分类展示：session header 增加 channel 标记 + GUI 渠道视图 | Group sessions by source channel/plugin: channel marker in session header + GUI channel view

[RGarvel]

需求

多插件并存时（例如 IM bot 插件 + web GUI 同时运行），用户无法在前端分辨哪些会话来自哪个插件/渠道，也没有一个视图能回答："哪些插件有对话记录、各有多少可用对话"。

希望：前端能按来源渠道/插件对会话分类展示，且不影响各插件自己的内存回收策略（例如 IM 插件的闲置会话回收应照常工作）。

现状（代码查证）

链路上目前完全没有"来源插件"信息，三个环节都缺：

1. 会话头没有来源标记。对比真实样本——IM 插件创建的会话与 GUI 创建的会话，磁盘头字段完全一致：

   {"type":"session","version":0,"id":"...","createdAt":...,"cwd":"...","delegationDepth":0}

   插件创建会话时写入的 meta 只有 cwd 等通用字段，没有 channel/source/plugin 之类的标识。
2. API 摘要不带来源。session.list 的 SessionSummary 投影（sessionListFields）只有 parentSessionId / origin / cwd / agentPreset——origin 还是 subagent 专用字面量，不是通用来源字段。
3. 前端只按 Workspace 分组。侧边栏的分组维度是 workspace + "未分组"，没有插件/渠道维度。IM 会话目前只是碰巧落在"未分组"区（因为不属于任何 workspace），并非分类。

与内存回收正交（关键设计约束）

这个功能不需要会话保持 attached，因此不影响任何回收行为：

• 标记持久化在 session header 里，随日志落盘；
• 分类视图基于 session.list，而该列表本来就同时返回活跃会话与冷会话（attached + persistence 合并）；
• 所以 IM 插件的闲置回收（如 sessionIdleTimeout 到期 dispose）照常运行，被回收的会话在渠道视图里依然可见、可点开冷读——顺带解决了"会话被回收后从 GUI 消失"带来的困惑（用户不知道它还在不在）。

建议（三层）

1. 核心：session header 增加标准化的 channel（或 source）字段，并透传到 SessionSummary 与 host/session-added 帧；
2. 插件约定：渠道类插件（IM、邮件等）创建会话时声明自己的 channel id（如 im-qqbot）；未声明的会话归入默认（gui）分组；
3. 前端：侧边栏提供按 channel 的分组/筛选视图；可与已有的 plugin inventory 联动，直接呈现"哪些渠道插件已安装、哪些有会话、各有多少"。

补充

• IM 插件内部其实已有渠道键（如 qqbot:<appId>:<scope>:<peerId>），但仅存于插件内存，未持久化、不外露；把它标准化进 header 成本很低。
• 该字段对排查也有价值：跨进程/跨渠道共享会话时（参见 web 打开其他进程写入的会话时会被接管：显示冻结、F5 无效，并存在双写风险 | Web attaches sessions owned by another process: frozen display, ineffective F5, double-writer risk #3873），可以从 header 直接看出会话的写入来源。

[leenkcool]

我是插件库，我感觉你的想法很好，我想收录，可以提ISSUE。 具体提的方法如下。
#4456

[RGarvel]

谢谢关注！先说明一下：本帖（#3897）是给 DSH 宿主的功能提案（session header 渠道字段 + GUI 渠道视图），尚未成码，目录站收不了提案本身。不过我已把它整理成两个可收录的仓库：

1. QQ 渠道插件 RGarvel/dsh-qqbot：QQ 会话与 DSH Web 双向桥接（提问双端同步、Web 回合镜像、快捷按钮、三级容错投递），含 cordis.patch.yml，已打 dsh-plugin topic。收录 ISSUE 已提交：收录请求：RGarvel/dsh-qqbot leenkcool/Blue-Whale-Harness#93；
2. RFC 规范仓库 RGarvel/dsh-channel-spec：本帖提案的规范化版本（RFC-0001，含字段级设计、插件约定、与内存回收正交性的论证）。若目录也收规范/文档类仓库，欢迎一并提报。

两个仓库均为 MIT 许可。也欢迎你直接在本帖或规范仓库提意见——官方暂不收外部 PR（见宿主仓库 CONTRIBUTING），社区仓库是这个想法目前唯一的正式载体。

[RGarvel]

更新：参考实现已落地为独立插件（不改宿主）——RGarvel/dsh-channel-view。

用官方扩展面走通了 RFC-0001 数据链的最小组合：

1. 插件宿主入口经 ctx.sessionProjections.register() 注册只读投影单元（参考 dsh-tool-todo 的 todos 单元形态）；
2. 值经官方 session/projection 推送帧到达客户端 SessionSummary.projectionValues——全程无私有 RPC（客户端 RPC 面是构建期固化的，这条路也是第三方唯一的实时 host→client 数据通道）；
3. 客户端模块注册 sidebar.footer.action 插槽 + react-dom portal，把「工作区」标题旁做成平行的 Channels tab：按声明渠道跨工作区分组、归档折叠组、迁移链同名去重（cwd 后缀+短 id）、孤儿工作区标注、运行中脉冲点。

两个实测发现，正好是规范该回答的问题：

• 冷会话基线：listProjectionsFor 对冷会话只读持久化投影行、不折日志（设计如此）——意味着 header.channel 这类"创建即知、永不变化"的属性不该走投影折叠，放 session header 让列表行直接携带才是对的（与 RFC-0001 的字段选择一致，这里补一条实证）；
• 第三方插件形态能做到的 UI 上限是"注入式平行 tab"，锚定依赖标题文案与 css-modules 键名，官方大改即失效——这支持 RFC 里 GUI 原生实现的诉求。

下一步会把 QQ 渠道的 peer-map 接成真实渠道声明（qq/c2c、qq/group），届时演示数据就不是 latch 了。

[RGarvel]

第二拍落地（兑现此前的公开承诺）：演示 latch 已被真实渠道声明替换。

QQ 渠道现在不是任何意义上的推断——由发起插件声明：

• 声明端 tencent-connect/dsh-qqbot#39：QQ 入站消息在落盘的 user/message 事件 source 里多带一个字段 channel: 'qq/c2c' | 'qq/group'（宿主 source 校验是 looseObject，额外字段直通；MessageSourceMap 注释本来就写着 merge-extensible、"plugins add their own kinds"）。同时在插件入口经官方 ctx.sessionProjections 注册 qqChannel 投影单元，折叠会话日志时锁存该声明——重放安全、随投影 checkpoint 落盘、冷会话重启后可读，全程零宿主改动。
• 消费端 dsh-channel-view v2.3（npm 0.0.1-spike.3）：qqChannel 真实声明进入最高优先级分组（QQ 私聊 / QQ 群聊），原 latch 演示值降级为"演示渠道"兜底档。
• 本机实证：重启宿主后 QQ 私聊发一条消息，该会话持久化投影行即出现 qqChannel = "qq/c2c"，Channels 视图里行实时归入 QQ 私聊组。

这一实验同时给本 RFC 补了一个边界证据：不经任何宿主改动，第三方已能把"渠道"声明式地传到列表行——但靠的是首条消息到达时才落戳；"创建即知、永不变化"的属性（会话在首条消息前就已出现在列表里，此刻只能显示"未观测"）仍然只能由 session.header.channel 承载。过渡实现与 RFC 目标语义完全同构，header 落地后可无痛替换。