[Bug] 源码启动默认 runtime 解析模式导致 dsh-tools 双实例,所有工具调用报 Cannot read properties of undefined (reading 'prepare')

[lyf2nb]

环境

• WSL2 Ubuntu 22.04 / kernel 6.18.33.2-microsoft-standard-WSL2
• Node v22.22.2(NVM)、pnpm 11.7.0
• HEAD ddefc45fbc(0.1.6-alpha.2)
• 启动方式:pnpm dsh headless "..." 与 pnpm dsh web 均可复现(内置 headless 与自定义 web profile 均受影响)

复现

1. 克隆 ddefc45fbc 并 pnpm install
2. 配置任意可用模型
3. 执行:pnpm dsh headless "用 bash 工具执行 echo hi"(或 pnpm dsh web 后在会话里调用任意工具)
4. 任意工具调用(bash、skill 等)立即失败

无需新写测试,仓库自带的 keyless 回放场景即可复现:

DSH_SNAPSHOT=replay pnpm run test:snapshot -t bash-tool-turn

实际行为

CLI 输出:

dsh: UNKNOWN: Cannot read properties of undefined (reading 'prepare')

会话日志中 tool/call 之后紧跟 turn/end:

{"reason":{"kind":"error","error":{"message":"Cannot read properties of undefined (reading 'prepare')","code":"UNKNOWN"}}}

bash-tool-turn 快照场景在 ddefc45fbc 上直接红:

FAIL snapshots/session/headless.snapshot.ts > headless recorded-session snapshots > replays bash-tool-turn through dsh --profile headless
dsh: UNKNOWN: Cannot read properties of undefined (reading 'prepare')

根因

提交 9ddef327a4(随 0.1.6-alpha.2 发布)把非 packaged 启动的默认解析模式从 link 改为 runtime(profile-boot.ts#L263)。

在 tsx 源码启动下:

1. tsconfig paths 把裸导入 @deepseek-ai/dsh-tools 映射到 packages/core/tools/src
2. runtime 模式的 profile resolution generation 按 package.json exports 加载插件入口 → lib/
3. 同一进程出现两份 dsh-tools;TOOL_RUNTIME_SCHEDULER 是 unique symbol,两份各有一个描述相同但对象不同的 symbol
4. tool-calls.ts#L170 的 ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(...) 取到 undefined,所有工具调用崩溃

插桩证据:

import.meta.resolve('@deepseek-ai/dsh-tools') → packages/core/tools/src/index.ts   # tsx paths
ctx.tools 实例来自 lib/index.js
sameSymbolObject=false        # 实例身上的 symbol ≠ agent-loop 导入的 symbol
libSymbolSameAsImport=false   # lib 的 symbol ≠ src 的 symbol
实例上存在 scheduler(prepare/dispatch/finalize/finish),但用导入的 symbol 取为 undefined

期望行为

默认源码启动下工具调用正常执行(9ddef32 之前默认 link 时正常)。

建议修复

最小修复:非 packaged 的默认值改回 'link'(本地验证 bash-tool-turn 由红转绿):

--- a/apps/cli/src/profile-boot.ts
+++ b/apps/cli/src/profile-boot.ts
@@ -260,7 +260,7 @@ export async function runProfile(options: RunProfileOptions) {
   const packaged = (process as NodeJS.Process & { pkg?: unknown }).pkg !== undefined
-  const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'runtime'
+  const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'link'

治本方向:让 runtime generation 与 tsx 的 paths 投影落在同一模块平面(源码启动解析到 src),避免同一包在 src/lib 两个平面各实例化一次。

另外建议把 bash-tool-turn(或同类真实工具调用场景)纳入源码启动/发布的必过门禁——本次发布显然漏掉了它。

(注意到 CONTRIBUTING 说明暂不接受外部 PR,故在此附上可复现证据与补丁,供团队参考采纳。)

---

---

Title

[Bug] Source launch defaults to runtime resolution mode, loading dsh-tools twice and breaking every tool call with Cannot read properties of undefined (reading 'prepare')

Environment

• WSL2 Ubuntu 22.04 / kernel 6.18.33.2-microsoft-standard-WSL2
• Node v22.22.2 (NVM), pnpm 11.7.0
• HEAD ddefc45fbc (0.1.6-alpha.2)
• Launch: pnpm dsh headless "..." and pnpm dsh web; both shipped headless and a custom web profile reproduce

Reproduction

1. Clone ddefc45fbc and run pnpm install
2. Configure any working model provider
3. Run pnpm dsh headless "run echo hi via the bash tool" (or pnpm dsh web and call any tool)
4. Every tool call (bash, skill, …) fails immediately

No new test needed — the repo's own keyless replay reproduces it:

DSH_SNAPSHOT=replay pnpm run test:snapshot -t bash-tool-turn

Current behavior

CLI output:

dsh: UNKNOWN: Cannot read properties of undefined (reading 'prepare')

The session log shows tool/call immediately followed by turn/end:

{"reason":{"kind":"error","error":{"message":"Cannot read properties of undefined (reading 'prepare')","code":"UNKNOWN"}}}

The bash-tool-turn snapshot is red on ddefc45fbc:

FAIL snapshots/session/headless.snapshot.ts > headless recorded-session snapshots > replays bash-tool-turn through dsh --profile headless
dsh: UNKNOWN: Cannot read properties of undefined (reading 'prepare')

Root cause

Commit 9ddef327a4 (shipped in 0.1.6-alpha.2) changed the non-packaged default resolution mode from link to runtime (profile-boot.ts#L263).

Under the tsx source launch:

1. tsconfig paths resolves bare @deepseek-ai/dsh-tools to packages/core/tools/src
2. The runtime profile resolution generation loads the plugin entry via package.json exports → lib/
3. Two copies of dsh-tools end up in one process; TOOL_RUNTIME_SCHEDULER is a unique symbol, so each copy has a distinct symbol object with the same description
4. ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(...) at tool-calls.ts#L170 is undefined, crashing every tool call

Instrumentation evidence:

import.meta.resolve('@deepseek-ai/dsh-tools') → packages/core/tools/src/index.ts   # tsx paths
the ctx.tools instance comes from lib/index.js
sameSymbolObject=false        # instance symbol ≠ symbol imported by agent-loop
libSymbolSameAsImport=false   # lib symbol ≠ src symbol
the instance does carry the scheduler (prepare/dispatch/finalize/finish), but lookup with the imported symbol is undefined

Expected behavior

Tool calls succeed under the default source launch (they did with the previous link default, before 9ddef32).

Suggested fix

Minimal fix: restore 'link' as the non-packaged default (verified locally: bash-tool-turn goes red → green):

--- a/apps/cli/src/profile-boot.ts
+++ b/apps/cli/src/profile-boot.ts
@@ -260,7 +260,7 @@ export async function runProfile(options: RunProfileOptions) {
   const packaged = (process as NodeJS.Process & { pkg?: unknown }).pkg !== undefined
-  const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'runtime'
+  const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'link'

Proper fix: keep the runtime generation and the tsx paths projection on a single module plane (source entries for source launches) so a package is never instantiated from both src/ and lib/.

Also suggest gating source launches/releases on bash-tool-turn (or an equivalent real-tool-call scenario) — this release clearly missed it.

(Noted CONTRIBUTING states external PRs are not accepted at the moment; posting the reproduction and patch here for the team to consider.)

[QiaoYang0923]

牛逼啊

[yinquanyy]

试过了，macos 下似乎无效

[BigTianY]

macOS我改了这里之后就可以了,可以试一下
profile-boot.ts (line 263)
原 const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'runtime'
改为 const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'link'

[zhang-guo-wen]

我在 Windows 11、当前 0351164555 上遇到了相同的 prepare 崩溃，但触发方式是 Web 进程运行期间执行 pnpm run typecheck 后的 HMR/模块重载。它和这里的 src/lib 双实例属于同一根因：同一 JS realm 内存在两次 dsh-tools 模块求值，而 Symbol(...) 每次都会产生不同的键。

除恢复源码启动的 link 默认值外，下面这个局部修改可以同时覆盖 src/lib 双实例和 HMR 重载：

export const TOOL_RUNTIME_SCHEDULER: unique symbol = Symbol.for('@deepseek-ai/dsh-tools.scheduler')

我本地增加了：

expect(Symbol.keyFor(TOOL_RUNTIME_SCHEDULER)).toBe('@deepseek-ai/dsh-tools.scheduler')

验证情况：

• packages/core/tools 的聚焦测试通过；
• pnpm exec tsc -b packages/core/tools packages/core/agent-loop --pretty false 通过；
• Web 运行中的下一次工具调用不再在 prepare 崩溃；
• 当前检出上运行 DSH_SNAPSHOT=replay pnpm run test:snapshot -t bash-tool-turn 已越过 scheduler lookup，但随后因当前 profile 未注册 bash 而以独立的 UNKNOWN_TOOL 失败，所以这里不把它记为完整快照通过。

我先前发布的 #7015 描述的是 HMR 触发路径；现确认它与本讨论重复，将其关闭并把后续信息集中在这里。

---

I reproduced the same prepare failure on Windows 11 at 0351164555, triggered by HMR/module re-evaluation after rebuilding packages while the Web process remained live. This and the src/lib duplication reported here share the same failure mode: two evaluations of dsh-tools in one JS realm create different keys when the declaration uses Symbol(...).

Using Symbol.for('@deepseek-ai/dsh-tools.scheduler') locally covers both trigger paths. Focused tools tests and the tools/agent-loop TypeScript build pass. The keyless snapshot now proceeds past scheduler lookup, although this checkout later fails separately with UNKNOWN_TOOL because bash is not registered in the active profile, so I am not claiming a fully green snapshot.

[zhang-guo-wen]

汇总结论与完整修复方案

近期这些报告属于同一故障族，但有三种触发路径：

1. 0.1.6-alpha.2 源码启动回归：pnpm dsh / pnpm dsh web 由 tsx 加载 src，profile 的 runtime resolution 又加载 lib，同一进程出现两份 @deepseek-ai/dsh-tools。
2. profile/插件依赖重复：profile 内的 node_modules 安装了另一份或另一版本的 dsh-tools，遮蔽安装闭包里的副本。
3. HMR/模块重载：旧的 ToolRuntime 实例仍存活，消费端模块重新求值后得到新的本地 symbol。

三者最终都在这里失败：

ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)

TOOL_RUNTIME_SCHEDULER 使用 Symbol(...)。两次模块求值会创建描述相同、对象身份不同的键，因此 lookup 得到 undefined。

用户立即恢复办法

• 源码 checkout：执行过 pnpm run build 后，可以暂时用构建产物启动：

  node apps/cli/lib/bin.js web
  # 或
  node apps/cli/lib/bin.js headless "task"

  这让整个图都从 lib 加载。另一种临时修法是把 apps/cli/src/profile-boot.ts 中非 packaged 默认值恢复为 link。

• npm/桌面安装或装过第三方插件的 profile：检查 $DSH_HOME/profiles/<profile>/node_modules/@deepseek-ai/dsh-tools。如果它和 harness 安装目录中的 dsh-tools 是两个物理副本/版本，移走 profile 内重复的核心包，重新生成 fallback 链接并重启进程。不要只在 UI 中禁用插件；磁盘上的 pnpm/npm 条目仍可能优先解析。

• 重启后新建会话。已经在 tool/call 后崩溃的会话缺少配对的 tool/result，继续发送消息可能触发 DeepSeek Messages tool calls need immediate results。在官方提供会话修复逻辑前，不建议手工编辑 session log。

上游修复 1：源码和产物保持单一模块平面

源码启动应默认 link，构建后的普通 Node 启动和 pkg 仍用 runtime：

const packaged = (process as NodeJS.Process & { pkg?: unknown }).pkg !== undefined
const sourceLaunch = import.meta.url.endsWith('.ts')
const defaultResolutionMode: ProfileResolutionMode = sourceLaunch ? 'link' : 'runtime'
const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? defaultResolutionMode

这比无条件改回 link 更完整：

• pnpm dsh（tsx / .ts）→ link，避免 src/lib 混载；
• node apps/cli/lib/bin.js（.js）→ runtime；
• packaged executable → runtime；
• 显式传入的 resolutionMode 仍优先。

上游修复 2：跨模块实例共享 scheduler 键

export const TOOL_RUNTIME_SCHEDULER: unique symbol
  = Symbol.for('@deepseek-ai/dsh-tools.scheduler')

这项硬化同时覆盖 profile 重复包和 HMR。它不能修复整个重复模块图中所有 instanceof、模块私有 WeakMap 或其他本地 symbol，所以不能替代修复 1 和模块去重，但可以消除当前导致所有工具调用崩溃的直接故障点。

上游修复 3：启动时检测重复核心模块

profile resolution / plugin install 完成后，应从 installation anchor 和每个 profile/plugin resolution anchor 解析关键核心包并比较 realpath 与版本。若同一个 @deepseek-ai/dsh-* 包解析到多个实体，应在启动阶段报错，至少包含：

• 包名；
• 两个实际路径；
• 两个版本；
• 哪个 profile/plugin 引入了副本；
• 清理或重新安装命令。

插件管理器安装完成后也应执行同一检查。autoInstallPeers: false 需要保留，但仅靠它无法处理已经存在的 npm/pnpm 条目。

上游修复 4：在写入 tool/call 前取得 scheduler

当前流程先写 tool/call，再读取 scheduler。scheduler 缺失时会留下无法配对的持久事件并污染会话。应在 appendToolCall(...) 前取得并验证 scheduler，将同一个引用传给整组调用：

const scheduler = ctx.tools[TOOL_RUNTIME_SCHEDULER]
if (scheduler === undefined) {
  throw new ToolRuntimeSchedulerUnavailableError(/* include resolved package paths */)
}

这样至少把错误变成可行动的 typed error，并确保该错误不会产生悬空 tool/call。如果 scheduler 在调用已经记录后发生其他内部失败，则应在关闭 turn 前记录合成的错误 tool/result，维持日志和 provider 消息序列完整。

必须增加的回归门禁

1. Symbol.keyFor(TOOL_RUNTIME_SCHEDULER) 断言全局 registry key。
2. CLI 源码测试断言默认 link；构建产物测试断言默认 runtime。
3. 树中已有 lib/ 时，通过真正的 pnpm dsh --profile headless 源码入口完成一次 keyless 工具调用。
4. 人工加载两份 dsh-tools，验证 provider 与 consumer 使用同一个 scheduler key。
5. provider 实例存活时重新加载 consumer，覆盖 HMR 场景。
6. 缺失 scheduler 的故障注入应在任何 tool/call 写入前失败，并验证会话仍可继续。

本地验证

我在 Windows 11 当前 checkout 上应用了前两项代码修改：

• apps/cli/tests/resolved-profile-boot.spec.ts：16/16 通过；
• pnpm exec tsc -b apps/cli packages/core/tools packages/core/agent-loop --pretty false：通过；
• packages/core/tools 的 scheduler key 聚焦测试：通过；
• Web 进程在构建/HMR 后不再于 .prepare 崩溃；
• 当前 HEAD 的 bash-tool-turn 已越过 scheduler lookup 并产生 tool/result，但因该 checkout 的 headless profile 未注册 bash，随后以独立的 UNKNOWN_TOOL 失败，因此这里不把它记为完整 snapshot 通过。[Bug] 0.1.6-alpha.2 source launch (pnpm dsh) splits @deepseek-ai/dsh-tools across src/lib — every tool call fails with "Cannot read properties of undefined (reading 'prepare')" #6967 / bug: 源码启动（pnpm dsh / pnpm dsh web）首次工具调用必崩 — Cannot read properties of undefined (reading 'prepare') #6994 已在 0.1.6-alpha.2 上验证真实工具调用可由单平面修复恢复。

相关报告包括 #4529、#4601、#6416、#6529、#6967、#6974、#6975、#6992、#6994、#6996 和 #7011。建议把本讨论作为 0.1.6-alpha.2 源码启动回归的集中跟踪入口。

---

English summary: this is one failure family with three triggers: source/artifact plane mixing, profile-local duplicate core packages, and HMR re-evaluation. The complete fix is to (1) default TypeScript source launches to link while keeping built/pkg launches on runtime, (2) use Symbol.for('@deepseek-ai/dsh-tools.scheduler'), (3) reject duplicate core module realpaths during boot/plugin installation with actionable diagnostics, and (4) resolve/validate the scheduler before appending tool/call so the failure cannot poison the session. The first two changes pass focused CLI/tools tests and TypeScript builds locally.

[rob-x-ai]

Thanks for bringing these cases together, Wen. I've extended the patch in my fork in commit 9291d7f66e with the additional protections:

• The scheduler now uses Symbol.for(...). A regression test keeps the provider alive, re-evaluates the consumer, and completes a tool call through the shared scheduler.
• Boot/reload and post-install checks reject distinct physical copies of Cordis, scope, Session, and tools. Errors include both paths, versions, and the manifests introducing them. Same-target symlinks and stale Harness fallback links are handled separately.
• Scheduler lookup is checked before committing assistant/message, since checking only before tool/call would still leave an unanswered assistant tool request. A missing scheduler records the stream as a log-only assistant/attempt and returns TOOL_RUNTIME_SCHEDULER_UNAVAILABLE with module details.
• If the scheduler fails after requests have been committed, the loop drains active work and records ordered error results for pending calls. Recorded calls get TOOL_OUTCOME_UNKNOWN, with guidance to check side effects before retrying; unstarted calls get TOOL_NOT_STARTED. Completed results and the original turn error are preserved.

For resolution, I kept the runtime default with the canonical declaring-path fix. Both source and built bash-tool-turn replays pass, as does the source Web regression. The Python SDK test also goes through the actual Messages serializer with a local mock model: four turns cover missing scheduler → recovery, then a failed two-call batch → recovery with immediately paired error results. The TypeScript SDK event snapshot, module-reload tests, duplicate-package checks, and Web browser replay pass too.

This was tested on macOS arm64 with Node 22.22.3, not Windows. The change protects new turns; it does not repair already-closed broken session logs. The physical-package audit covers declared dependencies, and the shared key does not make arbitrary incompatible module state safe.

---

谢谢你把这些触发路径整理到一起。我已在个人 fork 的补丁中补上相应保护：

• Scheduler 改用 Symbol.for(...)。回归测试保留原 provider、重新求值 consumer，并通过共享 scheduler 完成实际工具调用。
• 启动、重载及安装插件后，检查 Cordis、scope、Session 和 tools 是否存在不同物理副本；错误会列出双方路径、版本及引入依赖的 manifest。指向同一目录的符号链接和旧的 Harness fallback 链接会单独处理。
• 检查前移到提交 assistant/message 之前，因为只挡住 tool/call 仍会留下已提交但未获响应的 assistant 工具请求。Scheduler 缺失时，流仅记录为 assistant/attempt，并返回带模块信息的 TOOL_RUNTIME_SCHEDULER_UNAVAILABLE。
• 如果请求提交后 scheduler 才失败，先等待已开始的工作结束，再按顺序补齐错误结果：已记录调用标记为 TOOL_OUTCOME_UNKNOWN，提醒重试前核实副作用；未开始调用标记为 TOOL_NOT_STARTED。已完成结果和原始轮次错误都会保留。

解析模式这边，我保留了 runtime 默认值，沿用声明包真实路径的修复。源码与构建产物的 bash-tool-turn 回放，以及源码 Web 回归测试均通过。Python SDK 测试使用真实 Messages 序列化器和本地模拟模型，连续验证四个轮次：scheduler 缺失后恢复，再验证一批包含两个工具调用的请求失败后恢复，确认工具请求后立即跟随配对的错误结果。TypeScript SDK 事件快照、模块重载、重复包检查和 Web 浏览器回放也均通过。

验证环境是 macOS arm64、Node 22.22.3，尚未跑 Windows。这次修改保护后续轮次，不会修复已关闭会话中已有的未配对工具调用；物理包检查覆盖声明的依赖，共享 symbol 也不意味着任意不兼容模块状态都能安全互通。

[coldxiangyu163]

我们独立复现并定位了同一问题：profile 的 ESM 后备解析把 pnpm 符号链接下的 node_modules/.../package.json 当作 declaring 锚点，tsx 对含 /node_modules/ 的 importer 不应用 tsconfig paths，于是插件落到 lib/、CLI 落到 src/，同进程出现两份 @deepseek-ai/dsh-tools。

最小修复（把该锚点规范化为真实路径）+ 回归红绿测试 + 有/无构建产物（A/B）与端到端复测见 #7048。该修复不依赖把默认 mode 改回 link，runtime 模式下也不再出现 src/lib 双实例。

[Smalldy]

复制以下文本给Agent用来修复此问题

任务：修复 dsh 源码启动下所有工具调用崩溃（reading 'prepare'）

步骤 0 — 先确认版本，不要直接改（必做）

本问题有明确的引入版本，先判断你所在的树是否仍然是受影响版本，再决定要不要改：

git log --oneline -1
git log --oneline -1 -- apps/cli/src/profile-boot.ts
git log --oneline --all | grep -i "resolution mode"   # 找 9ddef327a4 "feat: resolution mode link to runtime"

判定规则：

• 回归由 9ddef32（随 0.1.6-alpha.2 发布）引入，在 HEAD ddefc45 上可复现。
• 若 git log -- profile-boot.ts 显示该文件的默认模式已经按启动平面分流（例如出现
  import.meta.url.endsWith('.ts') ? 'link' : 'runtime'，或默认值已不是无条件 'runtime'），
  说明问题已修，停止，不要重复修改，改为报告你观察到的现状。
• 只有确认仍是 const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'runtime'
  这类无条件 'runtime' 默认时，才进入步骤 1。
• 用代码文本而不是行号定位（行号会漂移）。

步骤 1 — 复现（30 秒）

DSH_SNAPSHOT=replay pnpm run test:snapshot -t bash-tool-turn

预期（受影响版本）：

dsh: UNKNOWN: Cannot read properties of undefined (reading 'prepare')

无需 API key，无需新写测试。会话日志中 tool/call 后紧跟 turn/end。

步骤 2 — 根因（已验证，勿重新推断）

runtime 解析模式与 tsx 的 paths 投影不在同一模块平面：

1. apps/cli/src/profile-boot.ts 让非 packaged 启动默认走 runtime。
2. runtime 模式把插件条目委派给「声明该条目的 manifest」解析，
   即 apps/cli/node_modules/@deepseek-ai/dsh-*/package.json —— 见
   packages/boot/app-boot/src/profile-resolution/resolver.ts 中
   native(request, routedParent, ...) 的 fallback 分支。
3. tsx 的 resolveTsPathsSync 对 importer 路径含 node_modules 的请求不应用 tsconfig paths。
   而这个委派锚点恰好就在 node_modules 下。
4. 结果：插件条目加载 packages/core/tools/lib/index.js，而源码平面的
   packages/core/agent-loop/lib/index.js 导入同一个包时 importer 不在 node_modules，
   被投影到 packages/core/tools/src/index.ts → 同进程两份 dsh-tools。
5. TOOL_RUNTIME_SCHEDULER 是 Symbol(...)（packages/core/tools/src/index.ts），每份模块实例
   各持一个描述相同、身份不同的 key；packages/core/agent-loop/src/tool-calls.ts
   的 ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec) 取到 undefined。

独立验证方法（建议做，用于证明「单一模块平面」而非猜测）：
用 module.registerHooks 写一个探针，经 NODE_OPTIONS="--import=file://..." 注入，
记录 @deepseek-ai/dsh-tools 的 resolve 来源与所有 /core/tools/ 的 load。修复前会同时看到
loader:<node_modules 下的 manifest> → lib/index.js 和 → src/index.ts 两条路径。

关键判据：委派锚点在 paths 投影的覆盖范围之外，所以这不是「改改配置」能解决的，
必须让源码启动走与源码平面一致的解析路径。

步骤 3 — 正确修法

不要把非 packaged 默认无条件改回 'link' —— 那会让构建产物/普通 Node 启动也退回磁盘链接模式。
应按启动平面分流：

// apps/cli/src/profile-boot.ts，模块作用域
const NON_PACKAGED_RESOLUTION_MODE: ProfileResolutionMode =
 import.meta.url.endsWith('.ts') ? 'link' : 'runtime'
// runProfile 内
const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? NON_PACKAGED_RESOLUTION_MODE

语义：源码启动（tsx 载入 .ts）→ link，条目经 profile 目录解析，与源码平面一致；
构建后的 .js 启动 → runtime；pkg 可执行文件 → runtime；显式传入的 resolutionMode 始终优先。

同步更新：

• 该字段的 JSDoc（默认值语义）；
• apps/cli/tests/resolved-profile-boot.spec.ts 中「default」档的断言
  （该 spec 由 tsx 载入 src，本身就是源码启动，默认应为 link）；
• packages/boot/app-boot/README.md + .zh.md 与
  .agents/notes/implemented/architecture/2026-09-09-profile-resolution-generations.md + .zh.md
  中「launcher 默认 runtime」的表述；改完中英对后按规程
  pnpm run verify-translation-pairing --write 重录。

步骤 4 — 验收

pnpm exec vitest run apps/cli/tests/resolved-profile-boot.spec.ts   # 全绿
pnpm exec tsc -b apps/cli                                          # 通过
pnpm run lint                                                      # 0 error
DSH_SNAPSHOT=replay pnpm run test:snapshot -t bash-tool-turn        # 不再出现 'prepare' 崩溃

bash-tool-turn 的验证判据是「崩溃消失」，不是「快照全绿」：
修复后应看到 tool/result 正常产出。

注意事项 / 反模式

• 不要在 Windows 上把 bash-tool-turn 的残留 UNKNOWN_TOOL 当成本次回归。
  该语料按 Linux 钉死；win32 下 base bundle 主动禁用 tool-bash
  （packages/bundle/base/cordis.patch.yml 中 disabled: !!js process.platform === 'win32'）。
  判定方法：分别以 DSH_EXAMPLE_MODE=lib（runtime 基线）和默认 src 模式跑完整
  snapshots/session/headless.snapshot.ts，失败集合应逐条相同，修复不得引入新失败。
• Symbol.for('@deepseek-ai/dsh-tools.scheduler') 和「提交 tool/call 前先校验 scheduler」是正交加固，
  不能替代本修复。 它们只缓解「双实例已经发生」的症状面（HMR 重载、profile 内重复核心包），
  而本回归的成因是源码启动产生了第二个平面。可以叠加，但先修本因。
• 已崩溃的会话不要手工编辑 session log：缺失配对的 tool/result，后续消息可能触发
  DeepSeek Messages tool calls need immediate results；修复后新建会话。
• 不要用 --force / 不要重写已验证的历史；本修复应为一个独立提交。