[Proposal][附参考实现] 多目录工作区：统一会话归属、主要目录与沙箱写范围

[ornithologist-love]

我们有一套已经在下游使用的多目录工作区底座实现，希望单独整理出来，讨论是否适合进入 DSH。由于UI和使用方式完全参考codex，所以仅供参考。

在我的日常工作中，多目录是典型场景、比如游戏引擎，项目，外围设施等，同一任务需要同时修改它们。

• 参考分支：feature/multi-folder-workspaces
• 与官方 dsh-v0.2.1-rc.2 比较
• 设计说明

使用场景

例如一个项目需要修改 C:/P 和 C:/E。希望它们在侧栏和会话归属上属于同一个工作区，以项目目录作为新会话的起始目录；在 workspace-write 下，同一条 PowerShell 或 bash 命令能写入两个目录，同时维持其他路径原有的限制。

直接授权共同父目录会同时授权无关仓库，两个目录甚至可能在不同盘符。拆成两个独立工作区又不能表达这类跨仓库命令。

这里的“多目录”指一个 Workspace 的多个成员目录，保留一个工作区身份和会话集合。

已有实现

参考分支从官方 dsh-v0.2.1-rc.2 单独提取，整理成一个 feature 提交，包含以下链路：

1. 工作区成员与会话归属。 workspaceRegistry.registerDirectories(source, historical?) 注册成员来源，主要目录在前；directoriesOf(id) 返回当前成员，resolveByPath() 支持按成员查找。历史目录可保留已经记账的会话归属。registerSessionSource() 和 refreshSessionHeaders() 允许组合贡献尚无日志的会话头并刷新索引。
2. 新会话起始目录。 Session controller 从第一个成员目录创建新会话，已有 Session 头和 cwd 保持原值。
3. 统一权限解析。 sandboxPolicy.registerWorkspaceRoots() 为所属会话提供成员集合；策略携带可选 workspaceRoots。同一会话只能由一个来源拥有，空集合会失败，无会话调用保留单根行为。模型可见的策略上下文列出完整成员集合，仍通过既有上下文记录机制保存。
4. 文件工具和进程沙箱。 writableRoots() 统一文件工具的写范围和 Seatbelt 允许列表；bwrap、Landlock 和 Windows ACL runner 使用全部成员。Windows runner 接受重复 --workspace 参数。
5. Windows 成员集合身份。 写 SID 由排序、去重后的成员集合派生；单目录保持原身份。变更集合会给后续进程一个新 SID，已有 ACE 不会把被移除目录授权给使用新集合的进程。

注册接口返回 disposer，便于插件卸载时移除来源。成员集合的持久化、目录校验、注册表与沙箱来源的一致性由组合持有，Workspace 记录、Session 头和事件格式保持不变。

接入边界

这是可供应用接入的通用底座实现。下游产品使用自己的目录编辑器、持久目录表和会话上下文贡献完成接线；这些产品代码不在参考分支中。原生多目录创建界面、多根 @ 文件检索和默认成员存储，需要另行决定由哪个组件持有。

工作区原始路径仍是不可变身份锚点，并保留已有挂接行为；接入方需要根据当前成员集合校验新会话目录，不能把“历史会话还归属本项目”等同于“仍授予目录写权限”。注册来源属于可信配置，公开编辑入口需要自己的认证和提交事务。

运行中的命令保留启动时的权限。修改成员集合不会撤销已有 Windows token，也不会重建持久终端；接入方需要在修改目录前关闭或拒绝仍存活的终端。这一点在下游由产品层处理。

Windows 成员集合写身份和重复参数参考了 Boy-Grid/dsh-multi-folder-workspace，原 MIT 声明保留并随包分发。

与 Low 完整性问题的关系

本分支沿用官方 rc.2 的 Windows ACL 后端，因此也保留其部分强制执行、常驻 ACL 和 Low 标签行为。我们另在 #11835 提了原生 MXC 候选修复。多目录工作区的成员解析和权限表达可以单独评审；这个分支没有将 Low 标签问题标为已解决。

验证

本次独立分支在 Windows 上执行了 pnpm install --frozen-lockfile、pnpm run build 和 pnpm run lint，均通过。完整构建包含产物构建和 Host/Client aggregate 编译检查。11 个功能源码文件与原有下游实现逐一核对一致。

pnpm run doc-sync 为 42 项通过、1 项失败：基线 python/sdk/uv.lock:113 的 wheel 文件大小 6344383 被仓库引用检查当成短提交号；该文件与官方 rc.2 完全相同。pnpm run hygiene 中 publint、NodeNext 消费端类型和依赖检查通过；MIT 声明发布白名单的遗漏已修复，并单独复查 pnpm run constraints 通过。

hygiene 仍有两类基线问题：vendor rescope 在 19 个文件中检测到旧名称残留，这 19 个文件均与官方基线相同；Cordis 配置检查读取的 apps/cli/tests/profiles/acp/cordis.yml 在 Git 中是符号链接，本机检出成了包含目标路径的普通文件，该文件也保持官方基线字节。完整检查日志保留在本地，未将这些检查称为全绿。

文档标准检查仍由 doc-sync 执行。

希望讨论

• DSH 是否接受“一个 Workspace 对应多个显式成员目录”的能力？
• 成员集合是否适合保留为组合贡献，还是应由原生 Workspace 存储和编辑界面直接持有？
• 工作区归属、目录成员和沙箱根是否需要收拢为一个原生来源，以减少组合接线的一致性责任？
• 是否先接受底座 API 与执行链，再补原生 UI、目录编辑期间的终端生命周期，以及各平台行为验证？