[Bug] 插件 id 冲突会让整个宿主崩溃：Cannot read properties of undefined (reading 'prepare')

[ltmroberthk915]

Summary

当同一个 profile 里存在两个 id 相同的插件时，DSH 不会拒绝加载冲突的那一个，而是抛出未捕获异常并把整个宿主打崩——应用完全起不来，必须人工删掉其中一个包才能恢复。

Cannot read properties of undefined (reading 'prepare')

When two plugins with the same id are present in one profile, DSH does not reject the conflicting plugin. The host process crashes with an unhandled error and the whole application becomes unusable until the user manually removes one of the packages.

Environment

• OS / 平台：Windows 11，DSH 桌面版（Electron）
• DSH 版本：UNKNOWN — 应用界面里我找不到版本号（安装目录的 resources/app.asar 是密封包，用户侧读不到内部 package.json）
• Profile：~/.dsh/profiles/desktop
• 宿主日志：没有 — ~/.dsh/logs 不存在，启动日志与崩溃日志都没有，用户侧无法自助取证
• 完整堆栈：没有 — 界面只显示 Cannot read properties of undefined (reading 'prepare')，标注 UNKNOWN

Steps to reproduce / 复现

1. 在同一个 profile 里让两个 id 相同的插件同时可被解析。现实中常见的两种来源：
   • 一个从插件市场 / npm 安装；
   • 另一个是手工放进 node_modules/ 的同名目录（或从别处拷来的同名包）。
2. 重启宿主。

Expected / 期望

装载期就检测到重复 id，并带上下文报错，例如：

duplicate plugin id "X": A=<pathA> declared by <pluginA>, B=<pathB> declared by <pluginB>

然后禁用其中一个、应用照常启动，失败原因在插件管理页可见。

Actual / 实际

• TypeError: Cannot read properties of undefined (reading 'prepare')，发生在装载器的 prepare 阶段；
• 没有任何一层捕获它：整个应用起不来，所有插件与所有会话一起不可用，而不是只坏冲突的那个插件。

Why I believe this is a framework-level gap / 为什么这是框架级缺陷

一个故障里叠了三个独立缺口：

1. 插件 id 没有唯一性校验。 id 在装载器里是主键（用于定位 entry、解析依赖），但没有任何前置检查；冲突一直走到 prepare 才以 undefined 的形式爆出来。
2. 报错不含任何诊断上下文。 reading 'prepare' 既没有冲突的 id，也没有两个来源路径——用户根本无法判断该删哪个包，只能一个个试。
3. 一个 entry 出错 = 整个宿主出错。 prepare 阶段没有 per-entry 的 try/catch 与降级（skip + 标记 error）。

补充证据（同一套装载逻辑上的另一个隐患）：cordis-plugin-include/lib/index.js:69-84 —— 没有 id 的 insert 走 else data.push(...insert)（第 82 行），不去重；而 bundle 层 patch 与 profile 层 patch 会 flatten 进同一份列表，因此同一个 id 被 push 两次是完全可能的，下游却没有任何一层挡得住。

Suggested fixes / 建议修复（按优先级）

1. 在 prepare 之前校验 id 唯一性。 flatten 之后按 id 建索引；冲突时抛带上下文的错误（点名两个来源），并丢弃后出现的那个，让启动继续。
2. prepare 阶段 per-entry try/catch。 失败的 entry 标记为 error（在插件管理页显示原因），不要向顶层抛。
3. 装载期错误必须自解释。 每个装载异常都应带上 id、包名、解析出的绝对路径、profile 名；界面的「本轮运行失败」应可展开看到原始栈，或提供"复制诊断信息"按钮。
4. 可观测性。 桌面版把宿主启动日志落到 ~/.dsh/logs/（或 %APPDATA%），致命错误保留 crash-<时间戳>.log；界面上暴露 DSH 版本号（现在报障连版本都填不出来）。

User-side workaround / 用户侧临时规避

• 装任何插件前，先在 profile 的 node_modules、package.json 的 dependencies 和 dsh.profile.bundles 里搜一遍包名，确认只有一个同 id 的包；
• 不要用"手工拷贝目录 + 手工 insert"和"市场/pnpm 安装"两种方式装同一个插件；
• 已经崩了：删掉冲突包之一（改 Rename-Item 成 .trash-<时间戳> 比直接删更安全）后重启。

---

本报告来自一次真实事故；事实部分来自现场与磁盘上的装载器源码，未能取得的信息（版本号、完整堆栈）已明确标注为 UNKNOWN，未作推测。

[PerryLink]

我在启动路径里没有找到显式的"重复 id 拒绝"——这与你的现象相容

1. 我核到的（如实说明边界）

在 packages/boot/app-boot/src/index.ts 里检索重复 id / "已存在"一类的判定，没有命中显式的拒绝逻辑。⇒ 与你描述的"不拒绝冲突的那一个，而是抛未捕获异常"相容：没有守卫 ⇒ 后加载者与前者的身份冲突未被检测 ⇒ 某处按 id 查表拿到 undefined ⇒ reading 'prepare' 失败并冒泡成未捕获异常。

请补一样把这条钉死：那两个插件的 id（相同值）与它们的包名，以及崩溃栈的第一帧（哪个文件/函数在读 .prepare）。有栈就能指出是"同一 id 被覆盖"还是"两条记录指向同一槽位"。

2. 建议按"坏配置不该打死宿主"这条主题提（这是它真正的分量）

你这句"必须人工删掉其中一个包才能恢复"是这条报告最重的一锤：一个配置冲突让整个应用起不来、且没有自助出口。同一天有多条同主题报告：

帖	坏输入	后果
你这条	两个插件同 id	宿主崩溃，应用起不来
#8817	MCP 输入 schema 未校验	参数静默渲染成 unknown（工具等于没签名）
#8821	后获得 dsh.bundle 的包	永远不被视作 layer，且第二次连警告都没有

⇒ 建议把它们并成一条诉求："配置错误（重复 id / 不可解析 schema / 组合不一致）应当在装配期被明确拒绝并指出冲突双方，而不是崩溃或静默劣化。" 单独一条"请修这个崩溃"很容易被当成个案，写成这一类就变成可验收的原则。

3. 修法方向（供参考）

最直接的是在加载期对 id 做唯一性校验：发现重复 ⇒ 同时报出两个包名与它们的来源文件，然后拒绝其中之一（fail-closed），而不是让冲突流到运行期。

4. 版本口径

你未写版本。⚠️ 当前最新是 0.2.1-alpha.1（latest/next = 0.2.0-rc.2）⇒ 请补上复现版本；0.1.7-rc.2 → 0.2.1-alpha.1 有 714 个提交，插件加载路径改动不小。

一条边界

我确认的是"在 app-boot 里没有找到显式的重复 id 拒绝"这一否定性证据（它支持"未被拒绝"，但不等于证明没有任何守卫——守卫可能在别的包，或用了别的措辞）。第 1 节请你补的栈能把它变成确定结论。