dsh-safety-restart

LIMITATIONS

Known limitations

- **`busy` 只覆盖本进程启动之后的轮次。** 它是按 `session/event` 维护的，更早就在跑的会话不在里面。所以第二道闸是"尽力而为"，不是权威快照。超过 `busyStaleMs` 的记录会被当作过期清掉（防止一条漏掉的 `turn/end` 把闸门永久焊死）。 - **bundle 体检是轻量的**：它只证明"包在、入口文件在"，**不证明它能被 import 成功**，更不证明客户端半在 slot 契约上是对的。要那一层用 [dsh-guardian](https://github.com/) 的 bundle scan。 - **web 健康检查是"端口恢复"，不是"HTTP 200"。** helper 只做 TCP 连接探测（127.0.0.1 上的端口能连上就算恢复）。它证明的是 *web 在监听*，不是 *web 健康* —— 后者需要服务的业务路由（dsh-guardian 探 `/guardian/report` 就是这样）。端口怎么推：`--port <n>` / `--port=<n>` 优先，否则 argv 里有 `web` 子命令默认 3080，推不出来就跳过健康检查退回 10 秒存活检查。**宁可不探测也不探测错误的端口**：新实例其实活着，却因为探错端口误报失败，比不探测更糟。 - **web 端退出是 `process.exit(0)`（非优雅）。** 会话日志是只追加的 jsonl，写到哪算哪；工具结果在 `delayMs` 之前已回传；尾巴真被截了也有续作提示兜。不退就永远重启不成，那才是真的坏。 - **客户端半按 rc 契约写**：`settings.plugin.item` 在 rc.12 是 `list`（要 `id`），更晚的契约是 `keyed`（要 `key`）。所以**两个都传** —— 多传一个用不到的字段不会报错，少传必需的那个才会。整个 `apply` 包在 try/catch 里：契约再漂，结果也只是"没有这张卡片"，不会牵连界面。