[已解决/非产品缺陷][Desktop 0.2.0-rc.2] 设置页保存必失败：dsh: profile reload requires the root Include entry（重装同一版本后恢复）

[Xenon1112]

[Bug][Windows][Desktop 0.2.0-rc.2] 设置页保存任一供应商配置必失败：dsh: profile reload requires the root Include entry

Summary

桌面版 0.2.0-rc.2（Windows，Electron 打包）中，设置 → 模型 保存任何供应商配置都会立即失败并报：

dsh: profile reload requires the root Include entry

原因是 dsh-config-editor 的 ConfigEditor.edit() 在写入 cordis.patch.yml 之前就先调用 reconcileProfilePatches()，而该函数在本进程里恒定抛错。因此这条路径对所有 profile 配置写入都是硬失败：用户无法通过 UI 修改任何供应商 / 模型 / 插件配置。

同一函数还有两个调用点，受同一缺陷影响：

调用方	位置	影响
dsh-config-editor	edit() 内	设置页保存全部失败（本 issue 的主症状）
dsh-hmr	profile 补丁监视器的 refresh()	cordis.patch.yml 热重载失效
dsh-plugin-manager	reload()	插件安装/启用的 apply 失效（降级为 restart-required）

Reproduction

1. Windows 11 全新安装 Desktop 0.2.0-rc.2，启动应用。
2. 打开 设置 → 模型。
3. 对任意供应商做一次保存即可。最小动作例如：只改一条路由的显示名并保存；或新增一条自定义路由（本次现场是新增 OpenRouter 路由）。
4. 保存立刻报错，且配置文件未被写入：

dsh: profile reload requires the root Include entry

复现率 100%（每次保存必失败），与选择哪个供应商、哪个字段无关。

Current behavior

报错点位于 @deepseek-ai/dsh-app-boot@0.2.0-rc.2（打包路径 resources/app.asar/dsh/node_modules/@deepseek-ai/dsh-app-boot/lib/index.js）：

const bootstrapIncludes = 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()，而 mountRootInclude() 的唯一调用点是 boot()：

const includeId = await ctx.loader.create(rootInclude);
const loader = ctx.get("loader");
if (loader === undefined) return void 0;
const entry = loader.resolve(includeId);
bootstrapIncludes.set(ctx, entry);                     // 唯一写入

调用方传入的是 this.ownerContext.root（dsh-config-editor / dsh-hmr / dsh-plugin-manager 三处一致）。

已经排除的两条路径：

• .root 恒等性不是问题。 同一运行时手工 boot() 一个等价树后实测 ctx.root === ctx 为 true（Context 构造器里 this.root = self，extend() 用 Object.create 继承），因此子上下文的 .root 与 boot 的根 Context 是同一对象。
• 不可能存入 undefined。 cordis-plugin-loader@1.0.5 的 EntryTree.resolve() 在条目缺失时是 throw（cannot resolve entry ${id}）而不是返回 undefined，所以 WeakMap.get() 拿到 undefined 只能说明键不存在。

同时具备的旁证：

• 应用本身看起来完全健康：boot() 明明跑过（auditStartupEntries 只用 bootstrapIncludes.get(ctx) 判断 include 是否属于 required，键缺失时不会报错，所以启动照样成功）；include:hmr 处于 active 状态，说明 profile HMR requires application readiness 这条前置检查通过、runProfile() 已经 appReady.commit()。
• 手工构造的等价树不复现：用同版本运行时（ELECTRON_RUN_AS_NODE=1 加载 app.asar/dsh/node_modules/...）手工 boot() 一个等价树后，直接调用 reconcileProfilePatches(ctx, patches, 'dsh') 正常返回 0 warning。只有应用自身组合出的树会失败。
• 附带观察（可能相关）：在同一手工树里通过 ctx.get('configEditor') 取到的 ConfigEditor 实例，其 ownerContext 在访问 loader 时抛 cannot get required service "loader" in inactive context，即可达的 service 实例可能挂在已被替换/失活的 fiber 上。

由此指向的两个分支

键不存在意味着 mountRootInclude() 那次 set() 不在 reconcileProfilePatches() 读到的那张 WeakMap 里，即二者必居其一：

1. @deepseek-ai/dsh-app-boot 被实例化了两份（例如一份来自 boot() 的静态导入链，另一份来自 PluginPackages / runtime interception 为插件的解析结果）。两份模块各有自己的 bootstrapIncludes。
2. 调用方拿到的是另一棵 Context 树上的 ctx（其根 Context 从未被 mountRootInclude() 记录）。

一行诊断即可定性（建议加在抛错前）

const entry = bootstrapIncludes.get(ctx);
if (entry === void 0) {
  ctx.logger?.error?.("app-boot: bootstrapIncludes miss", {
    has: bootstrapIncludes.has(ctx),   // false → 分支 1（另一份模块实例）；true 在本版本不可能
    ctxIsRoot: ctx === ctx.root,
    moduleUrl: import.meta.url,        // 与 boot 侧的 import.meta.url 对比即可确认双实例
    includeId: ctx.get("loader")?.resolve?.("include")?.id,
  });
  throw new Error(`${binName}: profile reload requires the root Include entry`);
}

建议的加固（无论上面哪个分支）

• 不要在模块级 WeakMap 里保存唯一的“根 Include”事实：可改由 boot() 把 entry 交给 ctx（ctx.provide 或 PluginPackages 之类已随树存活的载体），使 reconcileProfilePatches 与 mountRootInclude 不依赖模块实例同一性。
• auditStartupEntries() 同样用 bootstrapIncludes.get(ctx) 判定 required；键缺失时应显式报错而不是静默退化为“include 非必需”，否则启动会带着一个永久坏掉的 reload 路径继续跑。
• 三处调用点对 ctx 的取法应统一并在 miss 时给出可诊断信息（当前错误文本无法区分“没记录”与“记录了 undefined”）。

Expected behavior

设置页保存成功：完整 config 写入 profile 的 cordis.patch.yml，随后通过 Loader 正常重载；bootstrapIncludes 必须命中 boot() 时记录的根 Include 条目。

Environment

• 产品：DeepSeek Harness Desktop 0.2.0-rc.2（Electron 打包，非源码仓库运行）
• OS：Windows 11，Microsoft Windows NT 10.0.26200.0，x64
• 应用包：D:\DeepSeek Harness\resources\app.asar（121,348,951 bytes，sha256 983CA71114E6DFD353FC79AF5A1F9481A250EE64C2A3C757673029B811B23BC2；运行时未做任何修改）
• 运行时内版本：@deepseek-ai/dsh-app-boot 0.2.0-rc.2、dsh-config-editor 0.2.0-rc.2、dsh-settings 0.2.0-rc.2、dsh-hmr 0.2.0-rc.2、cordis-plugin-loader 1.0.5、cordis 4.0.4
• Profile：desktop（%USERPROFILE%\.dsh\profiles\desktop），DSH_HOME=%USERPROFILE%\.dsh
• 复现率：100%
• 变通可用性：直接编辑 %USERPROFILE%\.dsh\profiles\desktop\cordis.patch.yml 并重启应用有效；同一份 route 配置在设置页之外完全正常（例如新增 OpenRouter 路由后 llm.listProviders() 返回 [{"id":"openrouter","name":"OpenRouter"}]，内置目录解析出 386 个模型）

[Xenon1112]

补充一个可复跑的最小验证脚本，用来说明"手工 boot 的等价树不复现"以及 .root 恒等性。

同一台机器、同一份打包运行时（ELECTRON_RUN_AS_NODE=1，不启动 GUI、不占用端口）：

// probe.mjs —— 用打包运行时手工 boot 一个等价树，并直接调用 reconcileProfilePatches
import { mkdirSync, mkdtempSync, writeFileSync } from 'node:fs'
import { tmpdir } from 'node:os'
import { join } from 'node:path'

const APP = 'D:\\DeepSeek Harness\\resources\\app.asar'          // 按实际安装路径修改
const RUNTIME = `${APP}\\dsh`
const base = `file:///${APP.replace(/\\/g, '/')}/dsh/node_modules/@deepseek-ai`
const ab = await import(`${base}/dsh-app-boot/lib/index.js`)

const home = mkdtempSync(join(tmpdir(), 'dsh-probe-'))
process.env.DSH_HOME = home
const dir = join(home, 'profiles', 'probe')                       // 必须位于 profiles 树下，才会命中 runtime interception
mkdirSync(dir, { recursive: true })
writeFileSync(join(dir, 'cordis.yml'), '[]\n')
writeFileSync(join(dir, 'cordis.patch.yml'), '[]\n')
writeFileSync(join(dir, 'package.json'), JSON.stringify({ name: 'dsh-profile-probe', private: true, dsh: { profile: { bundles: [] } } }))

const installAnchor = join(RUNTIME, 'package.json')
const resolution = await ab.createRuntimeResolution({ installAnchor, home })
const profileContext = {
  name: 'probe', dir, patchPath: join(dir, 'cordis.patch.yml'), installAnchor,
  startedBundles: [], cwd: dir, home, overlays: [], telemetryDisabledEnv: undefined,
}

const ctx = await ab.boot('dsh', join(dir, 'cordis.yml'), [{
  insert: [
    { id: 'llm', name: '@deepseek-ai/dsh-llm' },
    { id: 'llm-pi-ai', name: '@deepseek-ai/dsh-llm-pi-ai', config: { providers: { openrouter: { apiKeyEnv: 'OPENROUTER_API_KEY' } } } },
  ],
}], async (hostCtx) => {
  hostCtx.provide('profileContext', profileContext)
  await hostCtx.plugin(ab.PluginPackages, { resolution })
})

console.log('ctx.root === ctx ?', ctx.root === ctx)                 // true
console.log('reconcile:', (await ab.reconcileProfilePatches(ctx, [], 'dsh')).length, 'warnings')  // 0 warnings，正常返回
await ctx.fiber.dispose()

观察结果：

• ctx.root === ctx 为 true，所以「调用方拿到的 .root 不是 boot 的根 Context」在本版本里只能来自另一棵 Context 树，不能来自 extend() 的继承语义。
• 手工树上 reconcileProfilePatches() 正常返回，说明 bootstrapIncludes 的机制本身没问题，缺陷出在应用自身组合出的树上。
• 若在同一手工树里通过 ctx.get('configEditor') 取 ConfigEditor 实例并调用 edit()，会看到 cannot get required service "loader" in inactive context——即可达的 service 实例可能挂在已被替换/失活的 fiber 上。这一点和主问题可能同源，供参考。

bootstrapIncludes.has(ctx) 是关键判据：本版本里 EntryTree.resolve() 是 throw 而非返回 undefined，所以 get() 得到 undefined 必然等价于 has() 为 false，也就是那张 WeakMap 里从来没有这个 ctx。

[Xenon1112]

补充：影响面比首帖更大 —— 所有设置页都无法保存，不只是模型页

现场追加：设置 → 模型 之外的其他设置页（通用、账号、Subagent、Shell、Web 搜索、Agent 循环、会话日志、插件等）保存同样失败，报错文本完全一致。

代码链路（0.2.0-rc.2 打包运行时）：只有一个设置后端，且唯一的写入路径无条件经过 configEditor.edit()。

1. Client 侧：所有设置页共用同一个写入面

dsh-client-ui-settings 的共享 store：

const response = await this.ctx.remote.settings.mutate(this.spec.namespace, ownedOps, revision)

使用它的客户端插件包括：ui-settings-general、-models、-account、-agent-loop、-subagent、-shell、-web-search、-session-log、-plugins。

2. Host 侧：dsh-settings（SettingsForms）只有一条写入路径

async write(ns, change, expected, paths = []) {
  const entry = this.ownerContext.configEditor.entries().find((row) => row.options.id === ns);
  ...
  await this.ownerContext.configEditor.edit(entry, (raw, inherited) => { ... });   // ← 进入 reconcileProfilePatches()
}

update() 同样转到 write()；describe() 也读 this.ownerContext.configEditor.configuration()。没有第二条后端。

3. 不存在"换个后端就能保存"的旁路

dsh-settings-file 在 0.2.0-rc.2 运行时里已经不存在（resources/app.asar/dsh/node_modules/@deepseek-ai/ 下没有该包；0.1.0-rc.5 还有它）。也就是说 0.2.0-rc.2 把设置完全收敛到了 profile patch 上的 config-editor 路径。

结论：任何走 settings 命名空间表单的写入都必然抛 dsh: profile reload requires the root Include entry，与 namespace、字段、页面无关。

一个加重感知的细节：writable 是硬编码的

/** Whether the active profile accepts form edits. */
get writable() {
  return true;
}

界面不会降级为只读（前端也不会把表单禁用），用户必须点到"保存"才拿到报错。这大概就是它容易被感知成"所有设置都点不动"的原因 —— 而如果 writable 能反映真实可写性，本缺陷至少会表现为"表单只读"而不是一排报错。

对修复的影响

• 首帖里的根因分析、诊断代码和加固建议不变，但修复优先级更高：这不是某个页面的问题，而是 0.2.0-rc.2 中全部 UI 配置面（9 个设置页 + 插件管理 apply + cordis.patch.yml 热重载）共用的一条路径。
• 在修复前，profile 配置只能手工编辑 %USERPROFILE%\.dsh\profiles\desktop\cordis.patch.yml 并重启应用。

（这是本缺陷的不同表现面，不是新问题，因此续在本帖，未另开新帖。）

[Xenon1112]

更正 + 两条排除结果（均为本机实测）

更正：这条缺陷是"被事件触发"，不是"装上 rc.2 就必然如此"

首帖我写的是"每次保存必失败、与状态无关"。补充事实：报障用户反馈今天早些时候设置还能正常保存并生效，之后才开始失败。所以它更像是由某个事件触发的状态问题，而不是该版本自带的恒定行为。请据此调整判断。

排除 1：路径残留与权限（不是环境脏）

• %USERPROFILE%\.dsh\profiles\node_modules\@deepseek-ai 下有 196 个 junction，全部指向一个旧 dev checkout（0.1.0-rc.5），其中 1 条还是失效链接（指向不存在的路径）；这类残留正是能造出"同一模块两份实例"的东西。
• 先确认本 profile 不依赖它（依赖都在 profiles\desktop\node_modules，其中 .pnpm 只有 lock.yaml；desktop\node_modules 下不存在任何 @deepseek-ai 目录或指向该 farm 的链接），再把整个 scope 目录移出 node_modules（可逆），然后完整重启应用。
• 复查：…\profiles\node_modules\@deepseek-ai\dsh-app-boot\package.json 读不到（not found），备份侧可读 → farm 确实已移除且未被应用重建。
• 结果：设置保存仍然失败，报错文本相同。 另外以管理员身份运行同样无效（缺陷发生在进程内的对象身份断言上，与文件权限无关）。

排除 2：第三方/实验组合包与 Plugin Manager 安装的插件（在最小组合包 + 全新进程下仍复现）

• 把 profile 的 dsh.profile.bundles 收成最小集合 ["@deepseek-ai/dsh-base","@deepseek-ai/dsh-web-app"]（原列表还含 @deepseek-ai/dsh-experimental-agent-team-profile、@deepseek-ai/dsh-experimental-auto-review、第三方 dsh-whale-widget，以及一个经 Plugin Manager 持久化安装的插件包），随后完整重启应用。
• 确认最小组合确实已生效：实时 Config 目录按包名查询 dsh-whale-widget 得到 0 个条目。
• 结果：设置保存仍然失败，报错文本相同。

附带确认：profile 补丁文件的热重载路径同样是坏的

configEditor.edit() 之外，dsh-hmr 的 profile 补丁监视器也调用同一个函数，这条路径可以独立观测：

1. 向 %USERPROFILE%\.dsh\profiles\desktop\cordis.patch.yml 追加一条新的 insert 行（id: reload-probe、disabled: true，不挂载任何东西，无害）；
2. 等待 7 秒以上（chokidar awaitWriteFinish: true 与 HMR debounce 都已覆盖）；
3. 实时树没有任何变化：Config 目录 total 仍为 187，查询 include:reload-probe 返回 unknown entry id。

dsh-hmr 只在能取到 appReady 时才注册这些监视器，且它的 fiber 处于 active（Config 目录里 include:hmr 为 schema），所以监视器是已注册的。

小结

第三方/实验组合包、Agent 经 Plugin Manager 安装的插件、路径残留、文件权限 —— 都已排除。缺陷位于打包运行时自身的启动/解析路径，并同时影响三条路径：设置保存（configEditor.edit）→ 补丁热重载（dsh-hmr）→ 插件管理器 apply（dsh-plugin-manager.reload）。

最小组合下仍复现，也使"外部 profile 内容"这一整类解释可以搁置：reconcileProfilePatches() 的检查发生在任何补丁内容被使用之前，所以补丁内容本身不可能造成这个 undefined。

仍然建议按首帖那段在抛错前加一行诊断：

if (entry === undefined) {
  ctx.logger?.error?.("app-boot: bootstrapIncludes miss", {
    has: bootstrapIncludes.has(ctx),   // 本版本里 false 是唯一可能（EntryTree.resolve 是 throw）
    ctxIsRoot: ctx === ctx.root,
    moduleUrl: import.meta.url,        // 与 boot 侧对比即可确认是否两份模块实例
    loaderPresent: ctx.get("loader") !== undefined,
  });
  throw new Error(`${binName}: profile reload requires the root Include entry`);
}

[Xenon1112]

最终排除：profile 层面彻底结案

在上一轮"最小组合包"的基础上，再把今天经 Plugin Manager 安装的那个插件的残留一并摘掉：

1. %USERPROFILE%\.dsh\profiles\desktop\node_modules\dsh-official-chat-switch（junction，指向工作区里的插件源码）改名移出 node_modules，使该名字不再可解析；
2. 从 %USERPROFILE%\.dsh\profiles\desktop\package.json 的 dependencies 中删除其 link: 声明。

实验成立性核对（这一步很重要，否则结论无效）：

• 应用在改动之后完整重启（进程启动时间比改动时间晚约 2 分钟）；
• 改动全部在位：原 link 名 Test-Path = False、desktop\node_modules 下无任何活动 link、package.json 中已无该声明。

此时 profile 的组成已经退到最干净的可运行形态：

"dependencies": { "dsh-whale-widget": "0.3.17" },
"dsh": { "profile": { "bundles": ["@deepseek-ai/dsh-base", "@deepseek-ai/dsh-web-app"] } }

即：无第三方/实验组合包、无 Plugin Manager 安装的插件、无 linked root、无插件依赖声明。

结果：设置保存仍然失败，报错文本完全相同。

至此完整排除清单

被排除项	方式
外部路径残留（196 个 junction 指向旧 dev checkout）	整体移出 + 重启，仍复现
文件权限 / 以管理员身份运行	提权运行，仍复现
第三方与实验组合包（agent-team-profile、auto-review、whale-widget）	收成最小组合包 + 重启，仍复现（实测 dsh-whale-widget 条目为 0）
Plugin Manager 安装的插件、link projection、依赖声明	全部摘除 + 重启，仍复现
profile 补丁内容	逻辑上不可能：reconcileProfilePatches() 的 bootstrapIncludes.get(ctx) 发生在任何补丁内容被使用之前
补丁热重载路径	独立探针：插入新行后实时树无任何变化（total 不变、include:reload-probe = unknown entry id）

结论

缺陷稳定存在于打包运行时自身（0.2.0-rc.2，Electron/asar 环境），并同时使三条路径失效：设置保存（configEditor.edit）→ 补丁热重载（dsh-hmr）→ 插件管理器 apply（dsh-plugin-manager.reload）。它不是安装污染、权限、profile 组合或配置内容造成的。

现场：一张几乎全清空的 profile + 全新进程，第一次调用 reconcileProfilePatches() 就命中 entry === undefined。

仍然建议按首帖那段在抛错前加一行诊断（bootstrapIncludes.has(ctx) / ctx === ctx.root / import.meta.url），即可区分"两份模块实例"与"调用方拿到了另一棵 Context 树上的 ctx"——在 profile 层面已被彻底排除之后，这两个分支是仅剩的解释。

[Xenon1112]

补一条与修复优先级有关的事实（本机实测）：

桌面端更新源（app-update.yml → https://download.deepseek.com/dsh-desk/feeds/win-x64/，channel: nightly）上唯一的 nightly.yml 声明：

version: 0.2.0-rc.2
releaseDate: '2026-09-29T10:35:27.666Z'
path: .../deepseek-harness-0.2.0-rc.2-win-x64.exe

即报障用户正在运行的正是 feed 上的最新桌面版；同一目录下 alpha.yml / beta.yml / rc.yml / stable.yml / dev.yml 均为 404，没有其它频道可选。

因此用户无法通过升级规避这个缺陷（设置页、补丁热重载、插件管理器 apply 三条路径全断），只能等包含修复的新构建。

[Xenon1112]

已解决：重装同一版本后恢复正常 —— 撤回"打包运行时缺陷"的结论

结论先行：本缺陷不是可复现的产品缺陷，现场是本机安装被改坏；重装同一版本后自動恢复。首帖及后续评论里"缺陷稳定存在于打包运行时自身"的判断，请作废。

关键事实（均为本机实测）

• 桌面更新源上最新就是 0.2.0-rc.2；用户重装的是同一个版本，没有任何版本变化。
• 修复前后 resources/app.asar 的 sha256 完全一致（983CA71114E6DFD353FC79AF5A1F9481A250EE64C2A3C757673029B811B23BC2，121,348,951 字节），mtime 仍是构建时间 2026-09-29 18:34。⇒ 出问题的东西不在 app.asar 里。
• 既然 app.asar 未变，损坏只可能在它之外：resources/app.asar.unpacked/**、Electron 可执行文件、或 resources/runtime/**。这些文件的时间戳由安装包保留为构建时间，无法用 mtime 判断是否被替换过，这是当时"重装无效"判断的盲区。
• 扫描本机 2026-10-05 20:30–23:30 的 33 个会话日志，没有任何一次写操作落在安装目录（覆盖 Copy-Item / Set-Content / Out-File / Move-Item / Remove-Item / New-Item / fs.writeFile* / fs.rm / asar pack 等模式）⇒ 不是某个 Agent 会话改坏的。
• 期间宿主进程有两次以 1073807364（0x40010004，被终止）退出，与"应用被强制结束 / 更新过程中断"一致。该桌面端 channel: nightly、更新会自行重启应用，一次中断的更新是目前最可能的损伤来源，但无法证明。

对维护者仍值得保留的一点（与根因无关，但是设计上的自隐）

@deepseek-ai/dsh-app-boot 中的 bootstrapIncludes 是模块级 WeakMap，mountRootInclude() 是唯一写入点；而 auditStartupEntries() 又用同一张表判断 include 是否属于"必需条目"。一旦该键没有被写入：

• 启动阶段不会报错（include 不被视为必需条目，writable 等前置检查也不会否决）；
• 应用照常启动、界面完全正常；
• 但之后所有配置写入（dsh-config-editor）、补丁热重载（dsh-hmr）、插件 apply（dsh-plugin-manager）都会以 dsh: profile reload requires the root Include entry 失败，且该错误文本无法区分"从未记录"与"记录了 undefined"（本版本里 EntryTree.resolve() 是 throw，故只有前者可能）。

建议：键缺失时在启动阶段显式报错/自检，而不是静默退化——否则一次安装损伤会伪装成一个"设置页坏了"的疑难杂症。

处置建议

• 若维护者认为此讨论不应继续留在讨论区，可以直接删除（报告由我发起，已获知会）。
• 否则建议按「环境/安装损伤，非产品缺陷」关闭；如需保留，仅保留上面那条"启动期自检/静默退化"的加固建议即可。