REQUEST_EXTENSION: plugin-package-inventory cannot resolve workspace packages in source mode (pnpm isolated linker)

[FranklinZaneDurant]

问题

从源码运行 pnpm dsh web，每次发消息都会失败，报：

错误在真正发 HTTP 请求之前就抛出，所以不会消耗 API 额度。

根因链

同一个解析器还找不到另外 6 个 active 包：
@deepseek-ai/dsh-api-session-controller、dsh-api-settings-controller、dsh-api-workspace-controller、dsh-client-ui-approval、dsh-client-ui-chat、dsh-client-ui-session。

为什么

dsh_plugin_packages 扩展（plugin-package-inventory-deepseek）用
createRequire(anchor).resolve.paths() + existsSync 在顶层 node_modules 搜索路径里找每个插件的 package.json。

在 pnpm 默认 isolated 链接布局下，workspace 包只被链接在 .pnpm/.../node_modules 内部，
没有提升到任何可搜索路径 → 解析抛错 → 整个请求失败。

而 Loader 加载同样的包却没问题（走 tsconfig paths / 源码平面），所以树能正常启动。
也就是说：源码模式 + isolated 布局下，两条解析路径对不上。

复现

• Windows 10，Node 24.14.1，pnpm 11.x，master (0.1.2-alpha.2)
• pnpm dsh web → 发任意消息即失败
• 进程内可确定性复现：boot web profile 后调用 ctx.deepseekLlmApiExtensions.prepare()

期望

解析器应能解析 workspace 包（例如跟随 package exports / workspace 布局），
或者降级——解析不到时记录日志并跳过，而不是抛错导致整个请求失败。

临时绕过

在 profile 的 cordis.patch.yml 里禁用该行即可：

- id: plugin-package-inventory-deepseek
  disabled: true

[argszero]

源码侧全部核实（本地 0.1.2-alpha.1 = cd5ef81，与你 master/alpha.2 的相关文件一致）。你的根因链准确，补几个你没点到的事实——其中两个决定修复形态。

核实结果：

• plugin-package-inventory-deepseek/src/index.ts:71-82——barePackageManifest 用 createRequire(anchor).resolve.paths() + existsSync 在 Node 搜索路径里找每个裸包的 package.json，pnpm isolated 布局下 workspace 包不被提升 → 全部落空。确认。
• throw 点有两个：:116（cannot resolve active package，裸包解析不到）和 :65（identityFromManifest，manifest 缺 name/version）。两者都未经 try/catch，从 collectActivePluginPackages（:170-173 循环）直接向上抛。
• 决定修复形态的事实①——prepare 是全量 fan-out：deepseek-llm-api-extensions/src/index.ts:111 是 Promise.all(entries.map(...))——任意一个扩展的 prepare 抛错，整个 prepareExtensions 就失败，被 adapter.ts:620-628 包成 LlmError('DeepSeek request extension preparation failed', 'REQUEST_EXTENSION', { cause })。所以不是"这个插件自己挂了"，而是它把整条官方路由拖死——你的"降级（解析不到就记录日志并跳过）"期望正是正确的修复方向：per-entry 失败不该让整个请求失败。
• 决定修复形态的事实②——插件形态无法修复：registry register（api-extensions/src/index.ts:91）对重复字段直接 throw（"field X is already registered"）。dsh_plugin_packages 已被 in-tree 插件占用，外部插件无法覆盖注册——唯一插件侧路径是先禁用 in-tree 插件再注册同名扩展，等于把核心修复搬进第三方包，不干净。此缺口属于 in-tree 核心层。

家族映射（三线程同一根因）：

• 源码运行 dsh web 时，plugin-package-inventory-deepseek 会让 DeepSeek 官方路由全部请求失败（cannot resolve active package） #5172（Puwenhui-Me）：同一插件让官方路由全部失败——"打地鼠"式逐包加 devDependencies 绕过，正是你描述的解析路径错位；
• REQUEST_EXTENSION 报错把 cause 链完全吞掉：终端、会话日志、Web UI 三处都看不到真实原因 #5173（同一作者）：REQUEST_EXTENSION cause 链被吞——用户只看到 REQUEST_EXTENSION 看不到真实原因。我在该帖的回复（discussioncomment-18213188）已全链验证：adapter.ts:620-628 包装点无 logger + agent-loop/src/agent.ts 全文件零 logger + LlmError failure 只带 message+code 丢 cause。你之所以在排查时才意识到是 inventory 插件，正是因为这条可观测性缺口——终端、会话日志、Web UI 三处都不显示 cause；
• REQUEST_EXTENSION: plugin-package-inventory cannot resolve workspace packages in source mode (pnpm isolated linker) #5196（本帖）：第二个独立报告，同一解析器缺口。

修复建议（按成本排序）：

1. per-entry 降级（最小改动）：collectActivePluginPackages 循环（:170-173）包 try/catch——单个包解析失败记 warn 并 skip，不抛给 prepare。一处覆盖 :65/:116 两个 throw 点，所有解析失败形态（含 malformed manifest）都变为可恢复。
2. Loader provenance 回退（治本）：抛错前先用 Loader 已有的事实解析——entry.parent.tree.ctx.baseUrl ?? hostBaseUrl（:106-107）就是 Loader 实际解析该条目的锚点；对裸包同样尝试 new URL(packageName + '/package.json', bareBaseUrl)（非裸包路径 :118-123 已有 nearestManifest 回退，裸包路径没有）。源码模式下 Loader 走 tsconfig paths 能解析到，说明该锚点可达——比 node_modules 搜索路径可靠。
3. 扩展点韧性原则：request-extension prepare 失败应按 field 降级（warn + 跳过该 field），只在传输边界 fail-loud——与 REQUEST_EXTENSION 报错把 cause 链完全吞掉：终端、会话日志、Web UI 三处都看不到真实原因 #5173 的可观测性修复（agent-loop catch 加 logger + LlmError failure 带 cause 渲染）配套，两条都改，用户才能既不被拖死、又看得见原因。

这是 in-tree 缺口（plugin-package-inventory-deepseek 是官方包），无插件形态方案；上游恢复 PR 通道后 1+2 可直接提交（约 5 行 + 一个回退分支）。