dsh web 在插件树加载完成前就对外提供 HTTP，外部无法判断“真的起好了”

[Fable-Forge]

TL;DR (EN) — dsh web serves a full HTTP 200 response (complete <div id="root"> page)
while the plugin tree is still loading, and can then die a fraction of a second later.
Any external supervisor (desktop wrapper, container healthcheck, systemd, k8s probe)
that polls the port will report "ready" and then find the process gone.
Please either not serve until boot completes, or expose a real readiness endpoint.

环境

• @deepseek-ai/dsh@0.1.0-rc.6、@deepseek-ai/dsh-app-boot@0.1.0-rc.6
• Node.js v24.19.0，Windows 11 (10.0.26200)，win32 x64
• profile：web

现象

dsh web 会先把 HTTP 服务起起来（返回 200，且返回的是完整页面、含
<div id="root">），插件树还在后台继续加载。如果加载阶段出错，
进程会在“页面已经能访问”之后才退出。

也就是说：「端口通了」「页面能打开」都不等于「启动成功」。

实测证据

证据 1：就绪与崩溃只隔 55 毫秒

外层守护进程的日志（探测方式：HTTP 200 且响应体包含 id="root"）：

02:01:34.550  拉起后端: node.exe ...\dsh\lib\bin.js web --host 127.0.0.1 --port 3080
02:01:37.063  后端就绪                <- 探测到 200 + id="root"
02:01:37.118  后端进程退出: code=1     <- 55ms 后就死了

退出原因是插件树里某个 entry 导入失败（参见 #2920，我在那边补了一份确定性复现）。

证据 2：socket 先 listening，随后进程消失

t=+1s  http=000  listening=1
t=+2s  http=000  listening=0

为什么这是个问题

任何外部编排都会误判：

• 桌面壳 / 启动器：轮询端口 → 判定成功 → 显示窗口 → 用户看到窗口后后端已经死了
• 容器 HEALTHCHECK、k8s readiness probe：标记 Ready → 流量打进来 → 容器重启
• systemd Type=notify / 端口等待脚本：同上

我们在自己的桌面壳里被迫加了这样的变通：

1. 探测到就绪后再额外观察 5 秒，确认进程还活着才算成功；
2. 启动早期失败自动重试 3 次。

这类逻辑本应由被守护的服务提供语义，而不是每个调用方各自猜。

期望行为（任一即可）

1. 加载完成后再对外服务 —— 插件树 ready 之前不 bind / 不接受请求；或
2. 提供明确的 readiness 端点，例如 GET /healthz 返回
   {"status":"starting|ready|degraded","failedPlugins":[...]}，
   并在文档里说明“外部守护应当轮询它，而不是轮询首页”；或
3. 至少保证启动阶段的致命错误发生在 bind 之前（先加载插件树、再监听端口）。

如果实现了方案 2，附带好处是外部可以区分「完全正常」和「起来了但某插件降级」。

相关讨论（不是重复，是不同层面）

Discussions 里已有几贴涉及“就绪”，但都不是这个层面，列在这里方便交叉参考：

• Proposal: Electron desktop client (apps/desktop) + one-click Windows launcher #358 Proposal: Electron desktop client (apps/desktop) + one-click Windows launcher ——
  提案里正是用“匹配 stdout 的 dsh web: http://... 那行”来判断何时加载页面。
  本贴说明的就是这个信号会误判，对该提案有直接影响。
• Recoverable startup mode for incompatible optional plugins #2920 Recoverable startup mode for incompatible optional plugins ——
  讲的是“插件失败后如何降级”，本贴讲的是“失败前已经对外宣称就绪”。
  两者叠加才是完整故障：先宣称就绪 → 再崩 → 外部守护已经把窗口显示出来了。
• SDK runtime: dsh-mcp-client missing from the runtime closure + no plugins-ready
  barrier before session/new、First prompt after boot races async MCP tool
  registration —— 这两贴是 SDK / MCP 层的就绪竞态，和本贴（HTTP 层对外服务时机）
  是同一类问题的不同表现，也许可以用同一个“plugins-ready barrier”一起解决。

备注

--host / --port 已经能满足外部拉起的需要，只差一个可靠的“何时算好了”信号。