0.1.3-alpha.2 装有 dsh-file-upload 插件时无法启动（duplicate loader entry id: file-upload）

[Fantasymax]

现象

CLI 升级到 0.1.3-alpha.2 后，装有第三方 dsh-file-upload 插件的 web profile 启动即崩（插件树加载失败）。回滚到 0.1.2-rc.1 后同一 profile 一切正常。

Error: dsh: plugin tree failed to load: failed to apply loader entry include (cordis:include): duplicate loader entry id: file-upload
TypeError: duplicate loader entry id: file-upload
    at EntryGroup.update (…/cordis-plugin-loader/lib/index.js)
    at Include._apply (…/dsh-app-boot/lib/index.js)

崩溃发生在任何服务启动之前，Web UI 完全起不来；如果配了看门狗式自动重启，表现就是无声的崩溃循环。

复现步骤

步骤	操作	结果
1	dsh 0.1.2-rc.1 + web profile 装有 dsh-file-upload 0.4.3	正常启动，插件横幅正常打印
2	npm i -g @deepseek-ai/dsh@0.1.3-alpha.2	安装成功
3	dsh --profile web	上面的加载器崩溃，端口无监听

原因推测

0.1.3-alpha.x 里 file-upload 似乎并入了基础 bundle，独立安装的同名插件就注册了重复的 entry id，而新版加载器把重复 id 当致命错误（0.1.2-rc.1 只在 composition lint 里报告过）。

如果确实是这个方向，能否让升级器/加载器在内置版落地时自动禁用或迁移独立插件，避免升级直接把启动打挂？目前的自救只有：留在 0.1.2-rc.1，或在上 alpha 前先卸掉 dsh-file-upload。

另外：应用内更新面板在「跟踪预发布版」开关关闭的情况下，仍然把 0.1.3-alpha.2 作为可用更新推出来——这台机器就是这样踩到 alpha 的。

环境

项	值
系统	Windows 11
dsh	0.1.3-alpha.2（崩）/ 0.1.2-rc.1（正常）
dsh-file-upload	0.4.3
node	v24

[argszero]

Confirmed — this is a real, source-visible reconciliation bug, and you've correctly pinpointed the mechanism. The file-upload entry is now part of the web-app bundle, and the loader changed from tolerant to fatal.

What I verified on master (d347e70390):

1. The duplicate-id collision is real. The web-app bundle mounts it with the same id your third-party plugin uses:
   • packages/bundle/web-app/cordis.patch.yml:173-174 → - id: file-upload / name: '@deepseek-ai/dsh-client-file-upload'
   • The bundle package.json declares it (packages/bundle/web-app/package.json:47 → @deepseek-ai/dsh-client-file-upload": "workspace:^").
   • Your third-party dsh-file-upload registers id file-upload → same id, two sources → collision.
2. The hard-fail is the loader, not the bundle. vendor/loader/src/config/group.ts:64 throws duplicate loader entry id: ${id} from EntryGroup.update when two entries share an id (if (seen.has(id)) throw). This is the cordis:include → EntryGroup.update path behind your stack (app-boot/lib/index.js Include._apply).
3. Why it's new in alpha.2-rc. The file-upload + @deepseek-ai/dsh-client-file-upload extraction landed in bbb2ca7c9b ("refactor(client): extract background file upload service"). That pulled the entry into the web-app bundle, so a profile that had been independently installing dsh-file-upload now double-registers.

Your root-cause guess is right: the bundle gained a first-party file-upload entry without accounting for the installed third-party version, and the loader treats the resulting duplicate as fatal.

What's the right fix shape? There are two sides, and both are worth fixing:

• Loader side (core) — duplicate-id is currently a config-composition error that kills the whole tree. It should be a differential decision, not a blanket throw: if two entries share an id but resolve to the same source identity, that's an idempotent duplicate and should dedupe (the reconcile family has hit this repeatedly — [Bug] plugin install reports success but silently disables an unresolved profile bundle #1377/`dsh plugin add` re-registers plugins already loaded by `cordis.patch.yml`, crashing web boot with `duplicate loader entry id` #2889 dedupe-by-id+clone). If they're genuinely different sources, fail loudly with both source paths so a user can see which two entries collide. That turns "silent crash-loop" into an actionable message (and avoids the watchdog-restart-cliff you correctly call out).

• Upgrade/device side — the transition you describe (0.1.2-rc.1 worked, alpha.2 breaks) is the classic "plugin absorbed into core" regression. On upgrade, a plugin whose function is now first-party should be auto-disabled with a visible reason (the 新版本更新的时候，经常会有跟插件的冲突导致启动不了。所以能不能变成保障本体启动，有冲突的插件自动禁用？ #5869 resilient-boot direction — same "fail-loud is right for dev, catastrophic for end users" tension) rather than silently duplicating an entry. Today the only escape is staying on rc.1 or uninstalling the plugin before upgrading — which is a dead end for a user who's mid-profile.

The app-side update panel caveat you noted (it pushed 0.1.3-alpha.2 with "track prereleases" disabled) is a separate real issue — that's the version-channel/deprecation family; worth its own report if you file one.

For the immediate workaround beyond uninstalling: you can disable just the third-party entry in the profile's cordis.yml (entry.disabled: true), which the loader respects, keeping the first-party bundle mount active. Happy to dig into the exact dedupe-by-source-identity predicate if you want to take a stab at the loader change.