【Bug】plugin-package-inventory 身份解析对「有 name 无 version 的 manifest」硬失败，桌面端每一轮 DeepSeek 请求返回 REQUEST_EXTENSION

[Linicc]

先查重：同一缺陷已由 #4950 报告（复现于 alpha.1 源码检出）。本贴补充桌面分发构建上的最小复现、契约矛盾证据与修复方案。

摘要

@deepseek-ai/dsh-plugin-package-inventory-deepseek 在请求期解析每个活跃 Loader 行的包身份。
当该行 name 是路径、且最近的 package.json 有 name 但无 version 时，它 throw；
异常被 dsh-llm-deepseek 包成 REQUEST_EXTENSION，每一轮 DeepSeek 请求全部失败。

被命中的 manifest 是 DSH 自己生成的：profiles/<name>/package.json 内容为
{ "name": "dsh-profile-desktop" }——默认就没有 version。
因此任何在 profile 中挂载、而自身目录没有 package.json 的本地插件都会触发。

环境

• DSH Desktop 44.0.0（channel: nightly，Windows 10.0.26200）；dsh 0.1.0-rc.6
• 缺陷组件 0.2.0-rc.2（从 app.asar 提取核对）；cordis 4.0.1
• provider / model：deepseek-official / deepseek-flash
• Provider 请求是否发出：否（错误发生在 prepareRequestExtensions 阶段）
• 同一 prompt 禁用该扩展：恢复正常
• 影响范围：master 分支同源代码仍存在此问题
  （已核对 packages/llm/plugin-package-inventory-deepseek/src/index.ts，
  identityFromManifest 与另一处 cannot resolve active package 的抛出逻辑均未加降级）——
  即这不是已修复的旧版残留

最小复现

mkdir -p $DSH_HOME/profiles/<profile>/plugins/myplugin
echo 'export function apply() {}' > $DSH_HOME/profiles/<profile>/plugins/myplugin/index.ts

# $DSH_HOME/profiles/<profile>/cordis.patch.yml
- insert:
    - id: myplugin
      name: "C:/Users/<user>/.dsh/profiles/<profile>/plugins/myplugin/index.ts"

重启后任意一次 DeepSeek 请求即失败，且此后每一轮都失败，与 prompt 内容无关。
在该插件目录补上 { "name": "x", "version": "0.0.0" } 立刻恢复
（注意这是用户侧临时规避，不是修复；且 PackageIdentityResolver 带进程内缓存，
运行期补完 manifest 需重启才生效）。

根因

identityFromManifest()（已编译产物等价代码）：

if (allowAnonymous && manifest.name === void 0) return void 0;        // ← 只容忍缺 name
if (typeof manifest.name !== "string" || manifest.name.length === 0
 || typeof manifest.version !== "string" || manifest.version.length === 0)
  throw new Error(`... ${path} must declare non-empty name and version`);

路径型行使 packageName === undefined，于是 allowAnonymous = true；
但该逃逸口只检查 name——「有 name、无 version」的 manifest 逃不掉，直落 throw。

这是缺陷，不是配置错误

调用方本来就允许解析失败：

const identity = resolver.resolve(activeEntry);
if (identity === void 0) continue;          // 契约：undefined = 跳过该条目

resolve() 的返回类型也声明为 … | undefined。抛出与调用契约自相矛盾。

该扩展的产物是尽力而为的诊断性元数据（README：对模型 token 影响为 0），
同一函数内序列化失败路径已做优雅降级——唯独身份解析 fail-closed 并具备请求级否决权，
属错误分级失当。架构笔记 2026-09-10-public-package-manifest.zh.md 亦写明
「App-boot 通过 Partial 适配无需发布身份的本地 profile」。

---

建议修复

改动 1（根因，必需）：身份不可解析时按调用方契约降级

当前 identityFromManifest() 把「manifest 不完整」与「manifest 损坏」混为一谈，
两者一律 throw。但如果 manifest 能被 JSON.parse 出来，它就不是损坏，
只是不足以构成发布身份——这类条目本来就该被跳过，而调用方也确实准备好了出口。

 function identityFromManifest(path: string, allowAnonymous: boolean)
     : DeepSeekPluginPackageIdentity | undefined {
   const manifest = JSON.parse(readFileSync(path, 'utf8')) as PackageManifest
-  if (allowAnonymous && manifest.name === undefined) return undefined
-  if (typeof manifest.name !== 'string' || manifest.name.length === 0
-    || typeof manifest.version !== 'string' || manifest.version.length === 0) {
-    throw new Error(
-      `plugin-package-inventory-deepseek: ${path} must declare non-empty name and version`)
-  }
+  const hasName = typeof manifest.name === 'string' && manifest.name.length > 0
+  const hasVersion = typeof manifest.version === 'string' && manifest.version.length > 0
+  if (!hasName || !hasVersion) {
+    // 身份不可解析属于「元数据缺失」，不是请求级错误。
+    // allowAnonymous 的语义是「这是没有发布身份的松散模块」，本应同时覆盖缺 name 与缺 version。
+    if (allowAnonymous) return undefined
+    throw new Error(
+      `plugin-package-inventory-deepseek: ${path} must declare non-empty name and version`)
+  }
   return { name: manifest.name, version: manifest.version }
 }

为什么只改这一处就够：allowAnonymous 由 packageName === undefined 决定，
即「该行是路径而非裸包名」——正是「本地挂载的松散模块」这一情形。
把判据从「只容忍缺 name」放宽为「缺 name 或 version 任一即容忍」，与调用方
undefined → continue 的契约完全对齐，profiles/<name>/package.json 自然被跳过。

行为变化：此前打死整轮请求的情况，变为「该条目不出现在 dsh_plugin_packages 里」。
这是可观测的降级，不是静默伪造——下游看到的是「目录里没有它」，
而不是「一个看起来完整、实则错误的目录」。这一点很重要：
如果为了止血而返回一个空数组冒充完整目录，就把「元数据缺失」伪装成了「目录为空」。

改动 2（同类缺陷，建议一并修）

resolve() 内还有第二处没有 undefined 出口的抛出，成因相同：

   manifest = barePackageManifest(packageName, anchors, this.packages)
   if (manifest === undefined) {
-    throw new Error(
-      `plugin-package-inventory-deepseek: cannot resolve active package ${JSON.stringify(packageName)}`)
+    // 与 caller 契约一致：裸包名解析不到 = 该条目不可诊断，跳过而非中断请求
+    return undefined
   }

理由同上：调用方已经能处理 undefined，这里抛出同样属于错误分级失当。
若维护者认为裸包名解析失败必须保持可见，可退一步——写入 debug 日志后仍 return undefined，
但不要让它继续上升为请求级失败。

改动 3（防御纵深，建议；可与改动 1、2 解耦）

即使 1、2 落地，未来任何第三方清单扩展出问题仍可能打死请求。
建议在 dsh-llm-deepseek 的 prepareRequestExtensions() 边界，
把「可选扩展准备失败」统一降级为：

• 该可选字段置空（而非伪造）
• 发一条可诊断 warning，并把 error.cause 一并带出
• 不影响 main request 的构造与发送

这与该函数内已有的序列化降级路径（payload 退回 base request、onOmitted 上报）
语义完全一致，属于把同一条策略补齐到身份解析路径，而不是新增机制。

不应采用的做法

做法	为什么不行
吞掉错误、返回空目录	下游会把「不完整」当成「完整」——必须发 warning 让缺失可观测
为本地插件自动生成 package.json	会掩盖真实的打包错误，且清单插件不该写盘（用户侧手动补是临时规避，不是修复）
在 collectActivePluginPackages 外层包一个大 try/catch	能止血，但会一并吞掉真正需要可见的失败；应逐条目降级

测试覆盖建议

用例	期望
最近 manifest 缺 version（本例）	请求成功；条目被跳过；有 warning
最近 manifest 缺 name	同上
完全找不到 manifest	同上
裸包名解析失败（改动 2）	同上
正常可解析条目	出现在 dsh_plugin_packages 中且字段正确
连续多次请求 / 冷启动	结果稳定（注意 PackageIdentityResolver.cache 会记忆 undefined）
无关扩展失败	不得被本降级掩盖

一个相关的小观察

PackageIdentityResolver 的 cache 会把 undefined 一并记住
（源码中已有 TODO：Invalidate manifest identities if in-process package-version replacement
becomes a supported upgrade path）。这意味着运行期补上 package.json 后需重启才生效。
不是本 issue 的根因，但会影响用户按「补 manifest」自救时的预期，值得在文档里提一句。

---

排障提示

遇到 REQUEST_EXTENSION 先看 error.cause——UI 上的
「DeepSeek request extension preparation failed」是被 adapter 覆盖过的文案，
原始错误藏在 cause 里，直接看 UI 会误判为模型或账号问题。

[Linicc]

补充：用户侧预防工具（不替代上游修复）

上游修好之前，用户侧唯一的规避是「给被挂载的插件目录补一个含 name + version 的 package.json」。
为降低踩坑概率，我们另外维护了一个守卫插件：

https://github.com/Linicc/dsh-plugin-guard

它以 DSH 组合包形式发布（声明 dsh.bundle.patch，含编译产物），可直接安装：

dsh plugin --profile add github:Linicc/dsh-plugin-guard

它在 host 启动时（早于任何模型请求）扫描所有 profile 的 patch 层，复刻本贴所述的判定逻辑，
对不合规的装载行就地补齐最小 manifest；并在 profile patch 文件写入后立即复检。

需要说明的是：

1. 这是用户侧预防，不是对 identityFromManifest() 的修复——本贴的根因仍在上游组件；
2. 同一条失败路径的其他触发方式（例如残留软链，见 Bug: stale broken fallback symlink (@deepseek-ai/dsh-storage-json) breaks every DeepSeek request after 0.1.2-alpha.3 upgrade #5439）仍会打死请求；
3. 它只在该插件自己的目录里完全没有 package.json 时才写，且从不修改 profile 根 manifest。