[Bug] 浏览器端插件代码错误致 UI 白屏且零可恢复性（FISH_CSS is not defined 实例），建议 client 错误隔离 + 安全模式

[xx-1-a]

一句话说明问题

浏览器端插件代码错误（本次是注释未闭合导致 FISH_CSS is not defined）让整个 Web UI 白屏（Failed to load plugins），服务端日志零感知，错误信息无定位、无恢复手段——单插件故障没有隔离，用户被锁死在白屏页。

复现步骤

1. 自定义插件 client.js 中存在未闭合注释（/** 开启后无 */ 结尾），后续 var FISH_CSS = ... 行被解析为注释内容，变量从未定义
2. 刷新 Web UI → 白屏，仅显示：HARNESS / Failed to load plugins / dsh-ui-tweak / failed to apply loader entry 8b9c5b08 (dsh-ui-tweak): FISH_CSS is not defined
3. 服务端表现：HTTP 200、服务日志完全正常、无任何错误痕迹（与 [Bug] 浏览器端插件服务名冲突致 UI 白屏，报错无冲突来源信息，服务端日志完全无感知 #2752 的 chatFileMentions 案例同款：浏览器侧故障服务端不可见）

实际结果

• 单个插件的代码错误导致整个 UI 不可用，且无法在 UI 内恢复（只能命令行 dsh plugin remove）
• 错误信息无定位：无文件路径、无行号、无插件源码上下文
• 该 bug 从 8-17 起就存在于已安装插件中（期间 dsh-doctor 多次运行未检出——P13 只查服务名冲突，不查 JS 语法）
• 排查只能靠用户截图肉眼分析，本次为确认根因读取了插件全部源码

平台策略建议

1. client 加载器错误隔离：单个插件加载失败不应阻断整个 UI 启动——降级为该插件功能不可用 + 局部警告，其余 UI 正常（呼应 [Bug] 浏览器端插件服务名冲突致 UI 白屏，报错无冲突来源信息，服务端日志完全无感知 #2752 讨论与 dsh-testkit Proposal: add real-host release lifecycle validation to the plugin-development Skill / 建议增加真实宿主发布门禁 #2088 kernel-guard 提案立场，浏览器端同样适用）
2. 浏览器端错误上报服务端：client 插件加载/运行时错误应通过现有连接回传服务端日志，终结"服务端日志健康、页面白屏"的排障黑洞
3. 错误定位增强：ModuleLoader 包装错误时附插件名 + 文件 URL + 行列号
4. client 代码预检：dsh-doctor（或 dsh web 启动前）增加 client 端 JS 语法/静态检查（node --check 或 esbuild parse 级别），boot 前捕获此类低级错误
5. 安全模式：boot 检测到失败插件时提供"跳过失败插件进入 UI"的选项，UI 内展示失败插件列表与禁用按钮，避免命令行依赖

环境

Windows 11 Pro / Node.js v24.16.0 / dsh 0.1.0-rc.6 / Electron 客户端窗口（127.0.0.1:3080）

[denial123789]

I traced this against rc.8 and agree that the failure is browser-owned even when the Host stays healthy. The current boot path is intentionally fail-loud: the framework-free BootPage remains available, each Loader entry is created, loader.await() settles, and a final sweep rejects any import/apply failure or unresolved service dependency. rc.8 does not expose a supported per-entry safe-mode skip, and Client HMR explicitly has no failure rollback.

For recovery today, preserve the first browser exception and exact /plugins/<id>/client.js?rev=... response, distinguish arrival → registration → materialization → apply → dependency settlement, map the entry to its real package/overlay owner, and remove or rebuild only that owner. An HTTP 200 or syntactically valid bundle is not enough: factory execution and Cordis apply happen later in the browser.

A safe mode should not simply catch and continue. It needs entry criticality and dependency data so identity, transport, authorization, settings, or runtime providers cannot be silently skipped; it should also show package ownership and source-map location and keep any browser-to-Host diagnostics bounded and redacted.

I published the complete rc.8 runbook and acceptance matrix here: canonical guide · visual browser pipeline.

Disclosure: I maintain the independent SandBase DeepSeek Harness Handbook.

[moonquake2004]

Thanks for the thorough write-up — and for naming the doctor explicitly in ④. That half is now covered.

On ④ (offline client pre-check): dsh-security v0.1.2 ships SP7, surfaced through dsh-doctor's security integration:

npx @moonquake2004/dsh-doctor@latest --json --envelope --security

It runs node --check (ESM/CJS auto-detected on Node ≥22) against every installed DSH plugin's client entry points — client/*.js|mjs, lib/client.js, root-level client.js — gated by each package's dsh field so ordinary dependencies are never scanned. A parse failure reports HIGH with file + syntax diagnostic; an unclosed /** in a client.js comes back as:

<pkg>/client.js:1 — SyntaxError: Unexpected end of input

i.e., your exact repro class, caught before any browser ever loads the bundle. On our live profile it currently validates 17 plugin packages / 10 client artifacts. One honest scope note: this runs at diagnosis time, not inside dsh web startup — wiring a syntax gate into boot itself stays upstream territory (where it would compose naturally with your ③).

On ①②③⑤: agreed those need platform-level answers — @denial123789's rc.8 trace matches our reading that fail-loud boot is currently intentional. For what it's worth, our own tooling chose warn-first semantics for exactly the reason in your ① (a single finding shouldn't take down the whole report). If/when ModuleLoader gains error localization (③), we'd happily align SP7's output format — plugin + file + line — so offline findings and runtime errors cross-reference cleanly.