【Bug】桌面端 desktop profile 无法安装任何插件：dsh: profile reload requires the root Include entry

[TaskerTonyk]

【Bug】桌面端 desktop profile 无法安装任何插件：dsh: profile reload requires the root Include entry

落点：本仓库 Issues 已关闭、Discussions 已开启（has_issues: false / has_discussions: true，经 GitHub API 于 2026-10-15 核实），因此以 Discussion 形式提交。
下文已脱敏：本机用户名、绝对安装路径已移除，保留可复现所需的最小信息。

环境

项	值
DSH 桌面端	0.2.0-rc.2
Electron	44.0.0
操作系统	Windows 11 x64
应用内置 Node	实际 v24.21.0；resources/runtime/versions.json 仍记录 "node": "24.18.1"（疑似版本漂移）
pnpm	v11.7.0
Profile	desktop
入口	Web GUI → 侧边栏「插件」（plugin manager）
目标插件	dsh-cost-meter@1.8.26（npm）

profile 已加载 bundle：@deepseek-ai/dsh-base、@deepseek-ai/dsh-web-app、dshmarket、dsh-office-tools、@weibaohui/skills-management、dsh-skill-hub、@klarkxy/dsh-dev-index、billion-context、dsh-agents-md、@noob-stupid/dsh-plugin-console、dsh-batch-tool-calls、@nonamelego/dsh-catppuccin、dsh-context、dsh-claude-style。

复现步骤

1. 启动桌面端（profile desktop）。
2. 打开插件管理页。
3. 安装任意 registry 插件（实测 dsh-cost-meter，1.8.26 稳定复现）。
4. 观察操作结果。

结果载荷：

{"code":"operation-error","diagnostic":"dsh: profile reload requires the root Include entry"}

pnpm 尾部输出：

✓ Lockfile passes supply-chain policies (verified 9m ago)
Progress: resolved 1, reused 0, downloaded 0, added 0
[WARN] Issues with peer dependencies found. Run "pnpm peers check" to list them.
dependencies:
+ dsh-cost-meter 1.8.26
Packages: -27
---------------------------
Progress: resolved 59, reused 1, downloaded 0, added 0, done
Done in 1.2s using pnpm v11.7.0

注意：pnpm 已经解析并写入依赖（+ dsh-cost-meter 1.8.26），随后操作失败并整体回滚（Packages: -27）。回滚后 profile manifest 不写依赖，但 node_modules/dsh-cost-meter 残留目录不被清理。

期望行为

安装应当完成，并走官方已支持的降级路径：热重载不可用时报告 restart-required（「文件已写入，重启 DSH 后生效」），而不是抛 operation-error 并回滚。

实际行为

desktop profile 上任何管理操作都返回 operation-error 与该 root-Include 诊断，已装上的包又被移除。

代码级分析（基于随应用发布的 asar）

该诊断串在整个应用里只有一个来源：@deepseek-ai/dsh-app-boot 的 lib/index.js。

const bootstrapIncludes = /* @__PURE__ */ new WeakMap();

async function reconcileProfilePatches(ctx, patches, binName, requiredIds = []) {
  const entry = bootstrapIncludes.get(ctx);
  if (entry === void 0)
    throw new Error(`${binName}: profile reload requires the root Include entry`);
  ...
}

bootstrapIncludes 只在 mountRootInclude() 内写入一次，键是 boot 期的根 ctx 对象：

const includeId = await ctx.loader.create(rootInclude);
...
const entry = loader.resolve(includeId);
bootstrapIncludes.set(ctx, entry);   // key = booted root context

同一文件的 boot() 在该 ctx 上挂载 root Include：

async function boot(binName, absoluteConfigPath, patches, prepare, bareModuleBaseUrl) {
  const ctx = new Context();
  ...
  await ctx.plugin(Loader);
  await prepare?.(ctx);
  await mountRootInclude(ctx, absoluteConfigPath, patches, bareModuleBaseUrl, binName);
  ...
  return ctx;
}

失败调用点在 @deepseek-ai/dsh-plugin-manager 的 lib/index.js：

constructor(ctx, config) { super(ctx, "pluginManager"); ...; this.ownerContext = ctx; ... }

async reload(requiredIds = []) {
  if (this.ownerContext.get("hmr") === void 0) return [];
  return reconcileProfilePatches(this.ownerContext.root, readProfilePatches("dsh", this.profile), "dsh", requiredIds);
}

async change(operation, request, reason) {
  ...
  const result = { ..., application: this.ownerContext.get("hmr") !== void 0 ? "applied" : "restart-required" };
  try { result.application = await operation(result) ?? result.application; }
  catch (error) { ...; result.application = "failed"; result.error = managementError(error); }
  ...
}

即：只要 ownerContext.get("hmr") 非空，reload() 就会走到这个必然抛错的调用；而 desktop profile 确实启用了 hmr（base bundle 中该行为 disabled: !!js "!ctx.get('profileContext')"）。于是 bootstrapIncludes.get(this.ownerContext.root) 取不到值——从 plugin manager 能拿到的 ctx 不是 boot 期 mountRootInclude() 注册的那个对象。

同一个抛错入口还被 @deepseek-ai/dsh-hmr 自己的 profile 监听器使用：

const patches = readProfilePatches("dsh", profile);
const warnings = await reconcileProfilePatches(this.ownerContext.root, patches, "dsh");

因此手工改 profile 的 package.json / cordis.patch.yml 也会触发同样错误。

已确认 / 尚未确认

已确认（读随包发布代码）：

• 该诊断串唯一来源是 reconcileProfilePatches。
• bootstrapIncludes 是模块级 WeakMap，以 boot 期 ctx 为键。
• plugin manager 只在 ownerContext.get("hmr") 为真时走到该调用；desktop profile 确实启用 hmr 与 plugin-manager。
• @deepseek-ai/dsh-app-boot 在 asar 中只有一份（profile 自身 node_modules/@deepseek-ai 仅有 cosmokit、schemastery），不是两份模块各持一个 WeakMap。

尚未确认（需运行时信息，非静态代码可判）：

• plugin manager 实际挂载在哪个 ctx 上（loader 的 isolate: 子树、host runner 另建的 kernel，还是 ctx 归属错误），以及因此 ownerContext.root 为何不等于 boot 期 root。

修复建议

1. 首选：让 root Include 的登记不依赖 ctx 对象身份（例如改由 loader 解析取得 root Include 条目），避免 WeakMap 按身份查不到。
2. 或者：让 reconcileProfilePatches() / HMR refresh 把「未注册 root Include」当成诊断降级为 restart-required，使 desktop 上不可能成功的热重载不再回滚安装。

另建议：安装失败回滚时清理 node_modules 残留，或在错误文案中明确提示本次为「已回滚」。

已验证的临时规避

在 profile 的 cordis.patch.yml 顶部覆盖 base bundle 的 hmr 行：

- id: hmr
  disabled: true

依据：PluginManager.reload() 本身就有 if (this.ownerContext.get("hmr") === void 0) return [];，change() 也有 restart-required 分支，因此重载被跳过、安装以 restart-required 落地，重启桌面端后生效。代价：该 profile 失去配置/bundle 热重载。

实测结果：有效。 重启后同一安装成功：manifest 写入 dsh-cost-meter: ^1.8.26、dsh.profile.bundles 含 dsh-cost-meter、node_modules 就位，且不再出现该报错。

[PerryLink]

报错本身你抓得准，测试也把它固化了。但你引的那条调用链不对——真正调进来的不是 plugin-manager.reload()。

报错出处

packages/boot/app-boot/src/index.ts:337：

if (entry === undefined) throw new Error(`${binName}: profile reload requires the root Include entry`)

这是唯一来源（binName 就是 dsh，所以你看到的是 dsh: profile reload requires the root Include entry）。packages/boot/app-boot/tests/user-patches.spec.ts:349 和 :352 把它当预期值钉住了。

那个 entry 来自一个 WeakMap：:261 的 const bootstrapIncludes = new WeakMap<Context, Entry>()，在 mountRootInclude()（:743）里 :788 写入，而根 Context 在 :1207 创建、:1232 挂载。所以它的意思是：这个 Context 上没有登记过 root Include。 报错说"profile reload 需要 root Include 条目"，字面就是这个。

你引的链条要改

你写的是 plugin-manager.reload() → reconcileProfilePatches。实际路径是：

• packages/boot/plugin-manager/src/index.ts:887 → const hmr = this.ownerContext.get('hmr')
• :893 → await hmr.reconcileProfile(requiredIds)
• packages/boot/hmr/src/index.ts:925 → reconcileProfile()
• :969 → recomposeProfile(this.ownerContext.root, …)
• → app-boot/src/index.ts:307 → :328 recompose → :336（就是抛错那一行的上一行）

没经过 plugin-manager.reload() → reconcileProfilePatches 那条。 这个区分不是抠字眼：它决定了问题出在 HMR 层的 reconcil，而不是插件管理器的补丁协调。建议改成上面这条链，维护者才不会先花一轮纠正引用。

有一个现成的 workaround，而且源码里写着

plugin-manager/src/index.ts:888-891：当 hmr 取不到时，它只做 composeEntries 然后返回 { warnings: [] }；:907 那边会给出 application: 'restart-required', restartReason: 'no-hmr'。

也就是说 HMR 不在的组合下这条路根本不会走到那个 throw，代价是装完要重启。你可以在 profile 里把 hmr 关掉试试——这能同时验证"是不是 HMR reconcil 这一层的问题"。

一处我没法替你定的

"为什么这个 Context 上取不到 root Include"——静态看代码判不出来。可能是 Context 身份不同（例如重载时换了新的 root），也可能是 dsh-app-boot 出现了两份实例（那 WeakMap 就各存各的）。这两个方向的修法完全不同。

不过如果是后者，你这份报告的价值会大很多——因为那正好跟"profile 里有重复的 dsh 包副本"是同一类问题。建议你在报告里把这两种可能都列出来，并附上你那份 cordis.yml 的最终态和 dsh --version，让维护者能直接判。

边界

我核的是 origin/master = 86a402200d（2026-10-15，alpha.4）。

⚠️ 这里有个版本提醒：packages/boot/app-boot/src/profile.ts 和 plugin-manager/src/* 在上一个 master 到这一版之间有改动（plugin-compatibility.ts 改得最多，+41/−27；profile.ts +4/−3）。所以如果你手上的产物更早，行号可能和上面不同——引用时把版本号带上。