同一进程两个工作区：第二次挂载 preset 失败，tool:pwsh 等 prompt section 报 already registered（dsh 0.2.2-rc.1）

[shizhan-cloud]

环境

• @deepseek-ai/dsh 0.2.2-rc.1，Windows x64，自定义 profile（非 web）
• profile 的 node_modules 里存在 @deepseek-ai/* 的真实副本（由 dsh plugin add 装入），宿主 asar 内另有一份
• 触发场景：同一进程内有两个工作区——桌面 UI 一个、IM 机器人（@xmanrui/dsh-im）配的是另一个目录

现象

先在一个工作区建过会话之后，第二个工作区首次创建会话即失败：

agent-preset/invalid: tool-pwsh (@deepseek-ai/dsh-tool-pwsh):
prompt section "tool:pwsh" is already registered
(for a per-agent override, register through that agent's `agent.ctx` instead)

后面跟着 tool-fs / tool-fs-search / tool-jobs / tool-goal / tool-ask-user / tool-todo / tool-web / tool-skill / present / tool-plugin-manager / … 一整串，逐条对应 preset 的插件清单。

失败之后，该 preset 在本次进程内永久作废：此后所有新建会话都报同一个错，只能重启恢复（源码注释 "A mount failure is final"）。

读到的机制

1. preset 的 generation 按工作区（scopeOf(ctx) 的父作用域）各建一份，所以第二个工作区会走第二次挂载，而不是复用第一次的 standing mount。
2. 真正的放大器是 进程内存在两份 @deepseek-ai/dsh-scope（profile 一份、宿主 asar 一份）。kScope 是模块私有 Symbol()，两份实例的 Symbol 不相等，scopeOf() 返回 undefined，于是 new ToolLayer(undefined) 把所有 per-agent 注册静默降级成全局层。
3. 因此第二次挂载时撞的不只是某一个 host 单例，而是整套 tool:* prompt section。

这和第 #3557 的分析一致（dsh plugin add 把 @deepseek-ai/* 传递依赖以真实副本装进 profile，破坏"全局唯一拷贝"契约）。

和已有报告的关系

• #1827 / #7147：preset 里的行往宿主平面注册单例（inspect provider / webServer route），二次挂载必失败；tool-cordis registers Host inspect providers globally → any second mount of a preset containing it fails (New Session appears to do nothing) #7147 里已经确认 standing mount 按 preset id 共享，所以冲突来自"两个不同 id"或"同一 id 重新挂载"。
• #4727：prompt section "deployment-persona" is already registered，同一层，已作为重复关闭。

本例的触发面更宽：不需要两个 preset id，只要两个工作区（各自 generation）就会撞；而且报错落在 prompt section 层，而不是 inspect provider 层。这一点在现有讨论里没有记录。

最小复现

1. 单进程启动，在工作区 A 建一个会话（挂载成功）。
2. 让另一个入口在同一进程内、以工作区 B 发起会话（IM 机器人、或直接切到另一个工作区窗口）。
3. 观察 agent-preset/invalid；此后 A 也无法新建会话。

判据补充：如果第二个入口是 IM 机器人，表现是消息被收下（seenMessageIds 增加）但不产生回合，会话文件不再写入——很容易被误判成"机器人没收到"。

期望

• 根因层面：scopeOf() 解析失败时应当显式报错，而不是静默降级到全局层。双实例只是触发条件，静默降级才是把局部问题放大成"整个 preset 作废"的原因。
• 行为层面：同一 preset 在不同工作区的 generation 不应共享全局注册层；或至少让 record.broken 只影响该工作区，不要污染整个进程。
• 体验层面：UI 应把 agent-preset-invalid 显示出来。现在是 console.warn('new session failed:', …)，用户只看到"点新会话没反应"。

目前的绕过

• 全进程只用一个工作区（UI 与机器人工作区对齐），重启恢复；
• 或把 profile 里 @deepseek-ai/* 的副本清掉/指回宿主那份（治标，且部分第三方插件声明了直接依赖，删了会 import 失败）。

如果需要，我可以补一份 profile 的 node_modules 布局和完整报错原文。

[PerryLink]

你读到的三条机制都能在源码里对上，问题在于注册时的 ctx 来自哪份模块图。

报错模板能定位到层：prompt section "<name>" is already registered (for a per-agent override, ...) 只在 global layer 出现（packages/core/system-prompt/src/index.ts:404-415，判据是 scope === undefined）。也就是说，这次注册发生在 scopeOf(ctx) 没解析到 tag 的时候。

挂载失败是终局：catch 把消息写进 record.broken 并 warn，这个 generation 不再重试（packages/preset/agent-preset-registry/src/index.ts:133-143，"A mount failure is final" 的注释在 :143）。所以"本进程永久作废"与代码一致。

Symbol 机制也对：@deepseek-ai/dsh-scope 的 tag 是模块私有 const kScope = Symbol('dsh.scope')（packages/core/scope/src/index.ts:18），scopeOf() 读它（:154）；tools 侧从同一个包导入 scopeOf 并按 scope 分派（packages/core/tools/src/index.ts:4、:106、:163）。两份副本就是两个 Symbol。

要小心的一步：scope 的解析由宿主服务自己做（system-prompt 用 ScopedLayers，packages/core/system-prompt/src/index.ts:9,445；tools 直接 scopeOf，packages/core/tools/src/index.ts:4,163），用的是它们自己那份 scope 包。所以"profile 里多一份 dsh-scope"本身不改变宿主的判断；只有注册时的 ctx 来自第二份模块图（也就是那组插件或服务确实从 profile 副本加载）才成立。你的 profile 里 @deepseek-ai/* 是真实副本，这让后一种情况可能，但还取决于 cordis.patch.yml 里这些行从哪儿解析。

判定方法：数清 profile 与宿主两边 dsh-scope、dsh-tools、dsh-system-prompt 的副本，再看第二个工作区的 ctx 是由哪份代码打 tag 的。修法方向是别让 profile 保留 @deepseek-ai/* 的独立副本（从 installation anchor 解析），与 #12516 同源；清副本前先确认第三方插件没有声明直接依赖，否则会变成 import 失败。