[Bug] 浏览器端插件服务名冲突致 UI 白屏，报错无冲突来源信息，服务端日志完全无感知

[xx-1-a]

一句话说明问题

浏览器端插件 provide 一个已被核心占用的服务名（chatFileMentions，由 dsh-client-ui-deliverables 提供）时，Web UI 白屏显示 Failed to load plugins: service "chatFileMentions" has been registered，无任何指引——用户完全无法得知是哪个插件、与哪个核心服务冲突、以及如何处理。

详情

• 复现步骤：

  1. 自定义插件 client 端执行 ctx.provide("chatFileMentions", {...})（该服务名已被核心包 @deepseek-ai/dsh-client-ui-deliverables 占用）
  2. 刷新 Harness Web UI（127.0.0.1:3080）
  3. 页面白屏，仅居中显示：HARNESS / Failed to load plugins / dsh-path-open / failed to apply loader entry <hash> (dsh-path-open): service "chatFileMentions" has been registered at <x6>
  4. 服务端日志完全正常（HTTP 200、client.js 正常下发），错误只发生在浏览器端，且无法在服务端日志中看到

• 实际结果：

  • 报错仅给 entry hash 与对象编号 <x6>，无法知道冲突来源（哪个包先注册了该服务）
  • 服务端与浏览器端错误日志割裂：插件加载错误只有打开浏览器 DevTools 才能看到
  • 建议：
    • 报错中列出已注册者的包名/插件名（如 registered at <dsh-client-ui-deliverables>）
    • 服务注册冲突不应导致整个 UI 白屏，应降级为局部警告
    • 错误详情可附加到服务端日志或提供 dsh doctor 检查

• 预期结果：冲突报错可读、可定位、不白屏

• 环境：Windows 11 Pro / Node.js v24.16.0 / dsh 0.1.0-rc.6 / Chrome

• 备注：服务端 curl http://127.0.0.1:3080 返回正常 HTML，错误仅在浏览器控制台与白屏页可见，排查成本高

[moonquake2004]

Relevant to this bug class — we ship an offline pre-check for exactly this failure (and it would have caught this profile before boot).

Context: dsh-doctor (moonquake2004/dsh-doctor) is an offline diagnostics tool for DSH profiles. A --json run scans the installed profile's bundles; check P13 (added today, commit 17bf38b, v0.3.5) targets precisely the failure you hit here.

What P13 does:

• Scans each installed bundle's client half (the dsh.client entry plus the client/ directory of built artifacts) for ctx.provide("serviceName", ...) registrations.
• Builds the core client-service name set from the installed host's @deepseek-ai/dsh-client-* packages (e.g. dsh-client-ui-deliverables → chatFileMentions; also connection / sessions / workspaces / modules / locale), with a seed list as fallback when the host is unreachable.
• Flags warn when a bundle's client provide collides with a core client service, or when two bundles provide the same name — i.e. the two shapes of "service already registered" that white-screen the UI.

On severity: we made P13 a warn (envelope status warn, does not flip the exit code to 2) precisely because — as you suggest — a service-registration conflict should not hard-fail the whole run; the offline tool reports it as a degraded/local warning and leaves the verdict to the user. This matches the vocabulary we froze in #1719 (pass / warn / fail / skip).

On your three suggestions:

1. Report the registrant package name — agreed, and it is the information an offline check has natively: P13's detail lists the colliding bundle names (e.g. client service name chatFileMentions conflicts with a core client service (dsh-client-ui-deliverables); providers: my-plugin). The runtime should still add the owner name to its own error, but a pre-boot check already tells you which plugin conflicts with which core package.
2. Degrade to a local warning instead of white screen — agreed; this is the same argument we made in the kernel-guard proposal on dsh-testkit #2088: the loader should isolate a failing entry with a log + suggestion rather than hard-crash the whole boot. P13 as warn keeps the diagnosis side consistent with that stance.
3. Attach details to server logs / provide a dsh-doctor check — exactly the offline-diagnostics gap: the failure is browser-side only, and the server logs see a healthy HTTP 200. A pre-boot profile scan (dsh-doctor --json before starting web, or the Doctor panel in the UI) deterministically surfaces these in advance. Happy to iterate on P13's rule set if you have more collision shapes in mind.

Environment note: we verified against the current host packages (dsh-client-ui-deliverables provides chatFileMentions; dsh-client-runtime provides sessions/workspaces, etc.), but the check builds the name set at runtime from the installed host, so it stays correct across dsh versions without a release.

• Tool: https://github.com/moonquake2004/dsh-doctor — Check P13 (profile section), README row + docs/doctor-contract.md
• Tests: 3 new fixtures (core-collision warn / cross-bundle same-name warn / custom name clean); suite 97/97 green

If you'd like, post a sample of your failing env (dsh-doctor --json with the profile) and I can confirm whether P13 catches it verbatim.

[xx-1-a]

感谢详细的说明和 P13 检查的设计思路，三点建议（报告注册者包名、降级为局部警告而非白屏、离线预检）我们都同意。按你的邀请做了实测，但遇到一个问题：

P13 在目前任何可获取的代码中都不存在：

• npm 版 dsh-doctor@0.4.3（2026-08-15 发布）：代码中无任何 P13 / chatFileMentions 相关实现，内置检查只到 P12
• GitHub moonquake2004/dsh-doctor main 分支（最新 commit f075c3f）：同样无 P13；git log --all 中找不到 commit 17bf38b

因此我们暂时无法验证 P13 能否捕获我们遇到的 chatFileMentions 冲突场景。能否确认 P13 的发布渠道（是否在未推送的分支上？npm 是否待发布？）

顺带反馈一个实测有效的结果：npm 版的 LINKED_PLUGIN_RESOLUTION 检查非常准确——它在我们环境中捕获了另一个本地插件（file: 链接、imports @deepseek-ai 包）的同类启动崩溃风险，这个检查对我们的排障帮助很大。

如果 P13 正式发布，我们愿意重跑 dsh-doctor --json 并贴上包含冲突场景的输出样本。