[Bug][Windows][Desktop 0.2.0-rc.2] 启动失败：desktop welcome: Web RPC failed（同一套插件在 node 下正常）

[1837zzy-max]

环境

• @deepseek-ai/dsh-desktop 0.2.0-rc.2（Electron 44.0.0 / node 24.18.1 / Windows x64）
• desktop profile：14 个 bundle（dsh-base、dsh-web-app + 12 个第三方插件）

现象

启动即失败，弹窗「The application could not start or stopped unexpectedly.」，crash-*-main.log：

source: main
phase: running
Error: desktop welcome: Web RPC failed
    at invoke (app.asar/lib/main.js:8097)
    at async settingsAndReference (app.asar/lib/main.js:8102)
    at async Object.read (app.asar/lib/main.js:8125)
    at async openInitialWindow (app.asar/lib/main.js:12152)

已发生 4 次：2026-10-06T19:46:42Z、19:59:02Z、20:05:13Z、21:54:32Z。
点「Disable third-party plugins, back up profile patch, and restart」后可正常启动。

关键反证：同一套插件在 node 下完全正常

同一 DSH_HOME、同一 node_modules、同一套 14 个 bundle，改用 dsh web（普通 node 进程）启动完全正常：无 entry 失败、无 pending，插件路由与工具均可用。

→ 指向 Electron 宿主侧的启动握手，而不是插件组合本身。

已排除

• 不是插件组合（见上）。
• 不是配置语法：dsh-composition-doctor@0.4.0 diagnose --profile <dir> --log <crash> 输出 No supported failure signature matched. Cause: unknown.
• 不是后台索引负载：其中一次失败时没有任何索引在跑。

请求

1. settingsAndReference 的 welcome RPC 加超时与重试，并把「宿主慢就绪」与「宿主崩溃」分开报；
2. 宿主进程的启动日志落盘（目前只有崩溃日志，"慢"这一侧完全没有可诊断信息）；
3. 插件在启动阶段阻塞宿主就绪时给出告警或超时隔离。

[1837zzy-max]

已定位根因并验证（本机独立复现）

不是插件组合、不是配置语法，也不是宿主慢就绪 —— 是一个插件把 Config 导出成了 null：

dsh-skill-store@0.1.1  lib/index.js:19   const Config = null

  ↓  SettingsForms.schema()   packages/settings/settings/src/index.ts:427
     const schema = entry.fiber?.runtime?.Config
     return schema !== undefined && 'toJSON' in schema ? schema as z : undefined
     ↑ 只挡了 undefined：对 null 求 'toJSON' in schema 直接抛 TypeError

  ↓  settings.describe() 整体失败（不是某一个命名空间失败）

  ↓  桌面端欢迎流程的第一步就是它：main.js:8102 settingsAndReference → settings/describe
     → result.ok = false
     → main.js:8097 丢弃 result，只抛 "desktop welcome: Web RPC failed"

触发规律（本机实测）

• 14 个 bundle 全量冷启动 → 必崩
• 不加载第三方插件 → 正常
• 启动后逐个手动启用插件 → 完全正常（该插件的 Config 是否在欢迎查询之前注册，是一个时序竞态）

这也解释了原帖的"同一套插件在 node 下正常"：dsh web 的启动路径不经过 welcome 的 settings/describe。

连带症状（同一根因）：插件设置页的配置卡片显示"读不到该命名空间"；dsh-mnemon 每次启动报两条 settings 错误。

验证方法（不必重启桌面端）

克隆一份 profile（复制 package.json + cordis.patch.yml，node_modules 用 junction 链过去），用应用自带运行时在普通 node 进程里启动，从 stdout 取带 token 的 URL 认证后 POST /api/settings/describe：

• 修复前：result.ok=false，code: gateway/internal，message: Cannot use 'in' operator to search for 'toJSON' in null
• 修复后：result.ok=true，返回 21 个命名空间

建议修复（两处）

1. DSH：schema() 增加 null 判断 —— schema != null && 'toJSON' in schema；
2. dsh-skill-store：不要导出 Config = null（不导出该字段，或导出真正的 schema）。

补充：真实错误一直就在被丢弃的那个 result 里 —— 原帖请求的"把错误详情报出来"是这类问题能被快速定位的前提。

[lemonxiny55]

我是 Composition Doctor 的维护者。感谢你记录 0.4.0 的实际输出，需要澄清一个边界：No supported failure signature matched. Cause: unknown. 只表示这段症状没有匹配到当前支持的模式，不能用来排除配置语法、插件组合或 runtime 故障。

你后续独立定位的 Config = null → Settings schema → welcome RPC 失败，属于 0.4.0 没有建模的 runtime 问题；这个根因是你的验证结果，不是 Doctor 的诊断成果。我会把这次使用记录为 “no-match，范围外，用户独立定位”，并让 README 更明确解释 unknown。无需再上传 profile 或完整日志。