initProfile() 生成的 profile manifest 缺少 version，导致 DeepSeek 官方线路所有请求失败（REQUEST_EXTENSION）

[yaoqian139]

环境

• DSH 0.1.7-rc.1（全局 npm 安装）
• Node v22.23.2
• Ubuntu on WSL2，dsh web 由 systemd user service 托管

现象

在 profile 里使用 DeepSeek 官方线路（deepseek-official/*）时，每一轮对话都失败：

本轮运行失败
DeepSeek request extension preparation failed

同一 profile 下切到 pi-ai 承载的路由（例如 opencode-go）则完全正常。

根因

1. profile manifest 本身缺 version

@deepseek-ai/dsh-app-boot 的 initProfile()（lib/index.js 约 561–572 行）创建 profile 时写的是：

const manifest = {
    name: `dsh-profile-${basename(dir)}`,
    private: true,
    dependencies: {},
    dsh: { profile: { bundles: [...bundles] } }
};
writeFileSync(manifestPath, JSON.stringify(manifest, void 0, 2) + "\n");

没有 version 字段。

2. 采集器对「有 name 无 version」的 manifest 直接抛错

@deepseek-ai/dsh-plugin-package-inventory-deepseek 在每次请求前重新采集 dsh_plugin_packages，对每个活跃入口解析「最近的 manifest」，并要求有 name 的 manifest 必须同时声明非空 version：

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`);

其 README 也写明："A named package manifest must also declare a non-empty version, and malformed package metadata fails request preparation."

3. 相对路径模块入口会命中这条校验

profile 里的相对路径入口（例如 - insert: [{ id: x, name: './x.mjs' }]）会「向上找到最近的 manifest」，也就是这个 profile 自己的 package.json —— 于是直接命中第 2 步的校验。

4. 异常被包装成顶层错误

@deepseek-ai/dsh-llm-deepseek 里：

throw new LlmError("DeepSeek request extension preparation failed", "REQUEST_EXTENSION", { cause: error });

最小复现

# 1. 初始化一个全新 profile —— initProfile() 写出的 manifest 就没有 version
dsh headless --help
cat ~/.dsh/profiles/headless/package.json
# => { "name": "dsh-profile-headless", "private": true, ... }   没有 version

# 2. 在该 profile 的 cordis.patch.yml 里加一个相对路径模块入口，例如：
#    - insert:
#        - id: my-plugin
#          name: './my-plugin.mjs'

# 3. 用该 profile 的 DeepSeek 官方线路发一条消息
#    => 本轮运行失败 / DeepSeek request extension preparation failed

任何由 initProfile() 创建、且含相对路径模块入口的 profile 都会中招 —— 新用户第一次用官方线路就会遇到。

影响

• 该 profile 下 DeepSeek 官方线路完全不可用（每一轮请求都失败）。
• 只影响官方线路；pi-ai 承载的路由不受影响。
• 尤其不合理的是：dsh_plugin_packages 只是请求诊断用的元数据，却让整轮请求硬失败。

建议修法

1. initProfile() 写入 version: "0.0.0"（一行的事）。
2. 采集器把「有 name 但缺 version」按 loose module 处理（不贡献 package identity），而不是让请求准备失败 —— 一个诊断字段不该让整轮对话失败。
3. 或把该贡献的失败降级为告警，不阻塞请求。

本地绕过方式（供遇到同样问题的人参考）

给 profile 的 package.json 补上版本号：

{
  "name": "dsh-profile-web",
  "version": "0.0.0",
  "private": true
}

或者在 profile 的 cordis.patch.yml 里关掉该采集器：

- id: plugin-package-inventory-deepseek
  name: '@deepseek-ai/dsh-plugin-package-inventory-deepseek'
  config:
    enabled: false

---

另一个观察（可选，单独讨论）

用户 patch 层（cordis.patch.yml）对已存在入口的 config 是整体替换，而不是深合并。

实测：基础 bundle 里 permission 入口带有完整的 presets 表，用户层只写

- id: permission
  name: '@deepseek-ai/dsh-permission-presets'
  config:
    defaultPreset: danger-full-access

则 dsh --profile web --dump-config 显示组合结果里 presets 表整张消失（必须把整份 config 重写一遍才正确）。如果这是有意设计，能否在文档里明确写出来？目前 cordis.patch.yml 顶部的注释只说「id-targeted config overrides」，容易让人以为会合并。

[argszero]

Confirmed — your chain is exactly right, and it is the newest member of a family with eight reports. Two links your write-up does not name are worth having, because they decide what a fix has to look like; and there is a stopgap you can mount today.

The chain, anchored at 46a7f68b09

1. initProfile() writes { name, private, dependencies, dsh } — packages/boot/app-boot/src/profile.ts:227, the manifest literal — and nothing later adds a version.
2. The collector's identity check is asymmetric in a way that matters here: identityFromManifest(manifest, allowAnonymous) tolerates a manifest that declares no name — that is the anonymous case, and it returns undefined = no identity — while a manifest that declares a name and no version is rejected (packages/llm/plugin-package-inventory-deepseek/src/index.ts:62). allowAnonymous: true is passed on exactly the loose-module branch (src/index.ts:131, packageName === undefined), which is the branch your './x.mjs' entry takes, so the one manifest your profile actually has is the one manifest the tolerance does not cover. The function itself is at src/index.ts:62, the throw at :67.
3. The throw sits before the cache write (src/index.ts:132) in resolve(), so nothing is memoized: the failure is recomputed on every request. That is why the official route is dead for every turn rather than only the first, and why adding the version by hand starts working immediately without a restart of anything else.
4. deepseek-llm-api-extensions/src/index.ts:111 prepares every registered field under one Promise.all, so that single throw fails every other field too, and llm-deepseek/src/request-extensions.ts:24 wraps the result as REQUEST_EXTENSION.
5. The wrapper does carry the cause — and no surface renders it. The terminal, the session record and the Web UI all show the wrapper sentence, so the path and the package name, the only actionable part of the failure, are exactly the part that is thrown away.
6. Same shape, eight reports, six different causes: a pnpm isolated layout (源码运行 dsh web 时，plugin-package-inventory-deepseek 会让 DeepSeek 官方路由全部请求失败（cannot resolve active package） #5172, REQUEST_EXTENSION 报错把 cause 链完全吞掉：终端、会话日志、Web UI 三处都看不到真实原因 #5173, REQUEST_EXTENSION: plugin-package-inventory cannot resolve workspace packages in source mode (pnpm isolated linker) #5196), a stale fallback symlink (Bug: stale broken fallback symlink (@deepseek-ai/dsh-storage-json) breaks every DeepSeek request after 0.1.2-alpha.3 upgrade #5439), a clean build (ERROR：本轮运行失败DeepSeek request extension preparation failed REQUEST_EXTENSION #5683), an absolute file-path module ([Bug] Local file plugins in a profile make every official DeepSeek request fail with REQUEST_EXTENSION (profile package.json must declare non-empty name and version) #5844), a relative-directory module (Bug: directory-specifier loader rows fail every DeepSeek request with REQUEST_EXTENSION #6064) — and now the manifest initProfile() writes, which promotes all of those from history residue to an out-of-the-box first-run path. That is the new information in your report.

A stopgap that can be mounted today

I published a cordis plugin for this seam — 0.1.0, MIT:

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

- insert:
    - id: request-extension-guard
      name: '@argszero/cordis-plugin-request-extension-guard'

It wraps each registered provider's prepare — the object the registry stores, not the registry's own method, which is left untouched — so the fan-out becomes a per-field decision:

• a field whose prepare throws is skipped for that request, its producer message is logged verbatim once per distinct cause, and every other field is delivered normally;
• a cause it recognizes earns the actionable paragraph; for yours, that is the manifest path plus the one line to add, or the config: { enabled: false } alternative you already found;
• opt-in repairProfileManifest: true adds the absent version (additive only, edited as text so key order and indentation survive, never overwriting an existing version) and retries the field inside the same request, so the field comes back rather than merely surviving.

Providers registered after the plugin mounts are covered too, through the registry's own map, with no polling.

What it does not claim, stated rather than hidden: a skipped field really is absent from that request. This turns "no request at all" into "a request missing dsh_plugin_packages", which is the trade your last paragraph asks for — but it is a trade. Cancellation is never turned into a skip, strictFields names the fields for which the trade is unacceptable, and mode: 'report' changes nothing at all and only names the cause. The durable fix is still in the harness, and the plugin's own log says so.

Evidence: the suite mounts a real cordis context, the real registry and the adapter's own ctx.get('deepseekLlmApiExtensions').prepare(request) expression, and asserts on the words a user will read, including the producer's message verbatim; a defect-injection run mutates the plugin's claims one at a time and requires the suite to catch each one (11/11 caught, 0 silent).

The core fix, ranked

Your (2) is the one that closes the family: tolerate one entry inside the collector — warn, skip that entry, do not throw — because every cause above shares a single root, which is that one unresolvable or malformed entry is allowed to veto the whole request. Your (1) is the right companion and should land with it, but note it only helps profiles created after it ships; every existing profile already has the version-less manifest on disk, which is why (2) is the part users actually need.

If a regression case is wanted: mount a relative-path module entry in a profile whose manifest declares a name and no version, and assert that prepare resolves with the other fields present instead of rejecting.

On your second observation (the patch layer's config)

That is real, and it is documented in the code as designed rather than accidental. The shared implementation is applyEntryPatches in vendor/include/src/index.ts — the one function used by both mounting and dsh --dump-config, so the dump cannot drift from what boots. For a non-insert patch it does:

for (const [key, value] of Object.entries(overrides)) {
  if (key === 'id') continue
  target[key] = value
}

so a row's config replaces the target entry's config object wholesale; there is no deep merge anywhere in that path. What misleads is the wording — the cordis.patch.yml header says "id-targeted config overrides", which reads like a merge. A deep merge would be a behavior change for rows that deliberately replace a config, so the cheap fix is a sentence in that header (and in the docs) saying that a patch row replaces the whole config object, and that composing partial configs is a --patch overlay / bundle-layer job. Worth its own thread if you want it changed rather than documented.

[zwrong]

同样中招，补充一个桌面端 / rc.2 的数据点，并附上源码级修复。

环境

• DSH 桌面端 0.1.7-rc.2（primary runtime 0.1.7-alpha.2）
• macOS arm64

命中的是同一条链

与 @yaoqian139 的分析完全一致，但触发者是桌面 profile 自己的 manifest：

• ~/.dsh/profiles/desktop/package.json（创建时由 initProfile() 生成）只有 name，没有 version；

• 现象完全相同：

  本轮运行失败
  DeepSeek request extension preparation failed
  

  （错误码 REQUEST_EXTENSION）

• 说明这并非「只有相对路径模块才中招」的偶发情况：只要 profile 目录里存在任何 loose module / 相对入口，采集器解析「最近的 manifest」时就会命中 profile 自己的 package.json，于是新建的 desktop profile 一上来就是坏的。

源码级修复（已在本地验证）

1. packages/boot/app-boot/src/profile.ts：ProfileManifest 增加 version?: string，initProfile() 生成 manifest 时写入 version: '0.0.0'：

   const manifest: ProfileManifest & { private: boolean } = {
     name: `dsh-profile-${basename(dir)}`,
   + version: '0.0.0',
     private: true,
     dependencies: {},
     dsh: { profile: { bundles: [...bundles] } },
   }

2. 对应测试加断言：expect(manifest.version).toBe('0.0.0')（packages/boot/app-boot/tests/profile.spec.ts，14 passed）。

3. 已经生成的 profile：直接补一行即可，改完立即生效：

   {
     "name": "dsh-profile-desktop",
     "version": "0.0.0",
     "private": true,
     "dsh": { "profile": { "bundles": ["@deepseek-ai/dsh-base", "@deepseek-ai/dsh-web-app"] } }
   }

4. 同意维护者的后续建议：plugin-package-inventory-deepseek 应把「有 name 但缺 version」按 loose module（不贡献 identity）处理，或至少把该贡献的失败降级为告警——一个请求诊断字段不该让整轮对话硬失败。

附带一点

DeepSeek request extension preparation failed 在包装 REQUEST_EXTENSION 时丢掉了 cause，而 cause 里才有真正可操作的 path / package name。这直接导致大家只能靠猜来定位；建议各 surface 把 cause 渲染出来（TUI / session 记录 / Web UI 目前都只显示最外层那句）。

[zwrong]

补一组「对照组」数据点，以及三点在本机桌面端源码里验证过的细节。

对照组：同一台机器上的两个 profile

profile	manifest	相对路径入口	结果
~/.dsh/profiles/web	有 "version": "0.0.0"（09-23 创建）	./eli-host2.mjs（command-eli-host，08-30 起）	不触发
~/.dsh/profiles/desktop	无 version（09-24 由桌面端 initProfile() 生成）	新加一个本地 ./x.mjs	加完立刻每轮 REQUEST_EXTENSION

两者喂给 identityFromManifest() 的唯一差别就是 version：有则返回 identity，无则走 allowAnonymous === true 分支后落到 throw。补上 version 后不需要重启，下一个请求就恢复 —— throw 位于 cache.set 之前，失败的 key 从未被缓存。

另一个旁证：web 的 manifest 还带 patchReload: "live"，这个 key 在本机 0.1.7-rc.2 的 app.asar 里出现 0 次，说明它不是本 App 的 initProfile() 写的。也就是说，initProfile() 写出来的 desktop manifest 就是坏的那一份，不是历史残留。

三点验证

1. 桌面端不会自愈。 DesktopProjectManager.applyRelease() → createPluginProfile() → initProfile()，而 initProfile() 只在 !existsSync(manifestPath) 时才写 manifest，整条路径没有任何补 version 的迁移。所以只改 initProfile() 只能救以后新建的 profile，存量 desktop profile 必须用户手改 —— 支持把楼主建议的 (2)（采集器容忍 + 告警）排在 (1) 之前。

2. 桌面端拿不到 cause 是结构性的，不是渲染遗漏。 lib/main.js 的 DesktopHostProcess 对 Host stderr 只做 slice(-65536) 累积，并且只在 Host 退出/失败时随 fail() 上报。即使这条错误进了那段尾巴，请求级失败也不会触发上报。所以「把 cause 渲染出来」只能落在 session / Web UI 侧，Host stderr 不是可用通道。

3. 改成绝对路径不能绕过。 barePackageName() 对 ./x.mjs 和 /abs/x.mjs 都返回 undefined，两者都进 nearestManifest(fileURLToPath(moduleUrl))，从入口自身所在目录向上找最近的 package.json。

附带一个当前可用的落点：nearestManifest() 第一步就看入口所在目录，所以把本地插件放进自己的子目录、并给它一份带 name + version 的 package.json（例如 profiles/desktop/my-plugin/{package.json,index.mjs}，入口写 ./my-plugin/index.mjs），就不会落到 profile manifest 上。这只是绕开解析器；给 profile manifest 补 version 仍然是更正确的做法。

---

EN — a control case, plus three desktop-side details verified locally on 0.1.7-rc.2.

Control: two profiles on one machine.

profile	manifest	relative entry	result
~/.dsh/profiles/web	has "version": "0.0.0" (created 09-23)	./eli-host2.mjs (command-eli-host, since 08-30)	no failure
~/.dsh/profiles/desktop	no version (created 09-24 by the desktop app's initProfile())	one freshly added local ./x.mjs	every turn is REQUEST_EXTENSION right after

The only differing input at identityFromManifest() is version: present -> returns an identity; absent -> falls through the allowAnonymous === true branch into the throw. Adding version takes effect on the next request with no restart, because the throw sits before cache.set and the failing key was never memoized.

Side note: the web manifest also carries patchReload: "live", a key with 0 occurrences in this build's app.asar — so that manifest was not written by this app's initProfile(). The version-less desktop manifest is exactly what initProfile() produces, not legacy residue.

1. The desktop app never heals an existing profile. DesktopProjectManager.applyRelease() -> createPluginProfile() -> initProfile(), and initProfile() writes the manifest only if (!existsSync(manifestPath)). Nothing on that path adds a version. So fixing initProfile() alone only helps profiles created afterwards; every existing desktop profile needs a manual edit — which argues for landing the collector-side tolerance (OP's 2) ahead of (1).

2. The missing cause on desktop is structural, not a rendering gap. DesktopHostProcess in lib/main.js accumulates Host stderr with slice(-65536) and reports that tail only from fail(), i.e. when the Host exits or fails. Even if this error reaches that tail, a per-request failure never triggers the report. Whatever surface renders the cause, it has to be the session / Web UI side; Host stderr is not an available channel.

3. An absolute path does not help. barePackageName() returns undefined for both ./x.mjs and /abs/x.mjs, and both go through nearestManifest(fileURLToPath(moduleUrl)), which walks up from the entry's own directory.

One placement that works today: nearestManifest() checks the entry's own directory first, so putting the local plugin in its own subdirectory with a name + version package.json (e.g. profiles/desktop/my-plugin/{package.json,index.mjs}, entry ./my-plugin/index.mjs) never reaches the profile manifest. That only routes around the resolver; giving the profile manifest a version is still the correct fix.