profile 清单缺 version 时，经官方适配器发出的每一次请求都在 HTTP 之前失败

[YOUKNOWWHOOO]

环境

操作系统：Windows 11 家庭版，版本 10.0.26200，64 位，AMD64。

运行时：Node.js v26.9.0（fnm 管理）、PowerShell 7.6.6。

软件：@deepseek-ai/dsh 0.1.7-rc.2（经 npx 安装，以 dsh web 启动）；profile 组合为 @deepseek-ai/dsh-base + @deepseek-ai/dsh-web-app；dsh-plugin-package-inventory-deepseek、dsh-llm-deepseek、dsh-app-boot 与 dsh 同版本。

观测时间：2026-09-29（CST，UTC+8）。

现象

部署的预设含有相对路径插件行（name: './…' 形态）时，如果该插件行解析落点的 profile 清单（profiles/<profile>/package.json）缺少 version 字段，则经 DeepSeek 官方适配器发出的每一次请求都在 HTTP 之前失败，错误为 DeepSeek request extension preparation failed（REQUEST_EXTENSION）。失败独立于请求内容：一个用户消息只有单个字符、此后未做任何操作的最短会话，也一样连续 5 次尝试全部失败、一轮未完成。同一进程、同一预设、同一时段，经第三方兼容适配器发出的请求不受影响。

触发链（0.1.7-rc.2 安装树回读，行号为包内产物行号）

1. 抛错点：dsh-plugin-package-inventory-deepseek/lib/index.js:34 的 identityFromManifest 要求清单的 name 与 version 都是非空字符串，否则抛 plugin-package-inventory-deepseek: <路径> must declare non-empty name and version。判据具有组合性：清单无 name 时按松散模块返回 undefined（同文件 :33），而有 name、缺 version 恰好落入抛错分支。
2. 清单定位：同文件 :53-62 的 nearestManifest 从插件模块所在目录向上取最近的 package.json；相对路径插件行经 :89-92 走到该函数。
3. 调用方：同文件 :73-96 的 PackageIdentityResolver.resolve 与 :110-127 的 collectActivePluginPackages，后者在每次请求时枚举宿主 Loader 树与发起请求的会话预设树的全部活动条目。
4. 包装方：dsh-llm-deepseek/lib/index.js:1341-1350 的 prepareRequestExtensions 把 prepare 的错误包成 LlmError("DeepSeek request extension preparation failed", "REQUEST_EXTENSION", { cause })，因此失败发生在每一次 HTTP 请求发出之前。
5. 清单生成方：dsh-app-boot/lib/index.js:575-586 的 initProfile 只在清单不存在时写出 name、private、dependencies、dsh.profile.bundles 四项，不含 version。也就是说 profile 目录一旦被重建、或清单被删除，下一次启动就会自动生成一个必然触发本失败的清单。

静态复现

对同预设的 3 条相对路径插件行求值：清单缺 version 时 3 条全部抛 must declare non-empty name and version；写入 version 后 3 条全部返回包身份；对照形态（清单无 name）不抛错。

影响

受影响面主要是「自定义预设 + 官方适配器」的部署，失败后官方通道完全不可用，且报错文本不指向清单文件。由 initProfile 生成的清单天然缺 version，任何导致清单被删或 profile 重建的操作都会让官方通道在下次启动后再次全灭。「相对路径插件行的最近清单必须含非空 name 与 version」在任何文档里都没有说明。

建议

1. initProfile 写出的清单补上 version（取当前 dsh 版本或由调用方传入）。
2. 或放宽解析判据：对有 name 无 version 的情形采用与无 name 一致的宽松处理，两者都不构成可归因的包身份。
3. 无论哪种修复，都建议把该隐式契约写入文档；profile 清单如有 schema 校验，建议在启动阶段报出，而不是等到每一次请求失败。

[argszero]

Confirmed at source, with two refinements that make the trigger sharper than the report states.

1. The tolerance rule is narrower than "loose handling for a manifest without an identity". identityFromManifest (packages/llm/plugin-package-inventory-deepseek/src/index.ts:62-69) is called with allowAnonymous: packageName === undefined (:131), and its first line is if (allowAnonymous && manifest.name === undefined) return undefined. So the tolerated case is exactly "no name". A manifest that has name and lacks version falls through to the throw. The two halves are not two strengths of one rule; they are "no name ⇒ not a package identity" versus "a name is a claim of identity, so a missing version is an inconsistency".

2. The generated manifest is not merely "one of the ways in" — it is the shape that triggers it. initProfile (packages/boot/app-boot/src/profile.ts:250-256) writes { name: 'dsh-profile-<dir>', private: true, dependencies: {}, dsh: { profile: { bundles: [...] } } }. That is a manifest with a name and no version, i.e. the failing case by construction, and it is only written when the file does not exist — so deleting or rebuilding a profile re-arms it. Your reading that this is self-triggering is right, and it is why the failure returns rather than being a one-off.

I also confirmed the wrap point is unchanged on the current tree: packages/llm/llm-deepseek/src/request-extensions.ts:28 re-throws the whole prepare in one LlmError('DeepSeek request extension preparation failed', 'REQUEST_EXTENSION', { cause: error }), so one contributor's failure takes the whole request before any HTTP, as you describe.

On your three suggestions, I agree with all of them, and I would rank them: (1) is the smallest and removes the self-trigger for everyone; (2) alone leaves initProfile's output silently identity-less for other consumers of the same resolver; (3) is what turns the next occurrence from a five-package source read into a one-line pointer — your own write-up is evidence for that, since locating it took reading plugin-package-inventory-deepseek, llm-deepseek, app-boot and the built adapter.

While the core side decides, the operational half is available today as a plugin:

@argszero/cordis-plugin-request-extension-guard@0.1.0

• npm — https://www.npmjs.com/package/@argszero/cordis-plugin-request-extension-guard
• source — https://github.com/argszero/cordis-plugin-request-extension-guard

One insert: entry in the profile patch (the package declares dsh.bundle.patch). It wraps the extension providers inside the registry the adapter reads on each request, so it needs no core change. It has three halves, and only the third writes anything:

1. isolate (on by default) — a provider whose prepare throws is skipped instead of taking every other field with it;
2. diagnose — the failing field is named and its producer message quoted verbatim (deduplicated per (field, message), budgeted per field), so the host log says which contributor failed and with what;
3. repair (opt-in, repairProfileManifest: true) — for exactly the manifest you found: name present, version absent. It adds "version": "0.0.0" to that one file as a text edit (indentation and key order untouched, an existing version is never overwritten) and retries the field within the same request, so the field comes back rather than merely surviving.

Verified against the build you are running: 0.1.7-rc.2 → 29/29, and 0.2.0-rc.2 → 29/29, each in a clean tree with the registry package pinned to that line and the resolved version read back before the suite ran. The suite's own file contains a fixture matching your case ({ name: 'dsh-profile-web', private: true, dependencies: {}, dsh: { profile: {} } }) and asserts the "version": "0.0.0" line appears. A mutation harness (11 arms) confirms the suite is load-bearing — each arm breaks one claim and the suite is required to go red; none is silent.

Two boundaries worth stating, because they are the difference between this and your suggestion 1:

• The repair is an operational workaround, not the fix. It changes a file the deployment owns; initProfile still generates manifests without version, so a rebuild re-creates the condition and the guard repairs it again. Your suggestion 1 is still the thing to do upstream.
• It is off by default. Writing into a profile manifest on a request path is a side effect, and a guard that silently edits configuration is worse than the failure it hides. Nothing is written unless the option is set.