dsh-safe-restart

dsh-safe-restart

重启 DeepSeek Harness，并且告诉你它到底成没成。

先说清楚一件事，因为这决定了这个插件是什么：

Windows 上没有"从外部让 Electron 优雅退出"的通道。 给主窗口发 WM_CLOSE 只会让它最小化到托盘，进程根本不退（我实测过，日志在下面）。市场插件里那个"一键重启"能跑通，是因为它在进程内部给自己发 SIGTERM——而在 Windows 上那等价于 TerminateProcess，也就是强杀。

所以这个插件不承诺"优雅"。它承诺的是另一件更实用的事：重启失败是常见且静默的，它会把结果明确告诉你。

它做什么

3 秒后强制结束宿主进程
  → 重新拉起同一个 exe（失败重试 3 次）
  → 轮询宿主端口，确认新进程真的在服务
  → 给你发一条 QQ 消息：成功 / 失败 + 日志路径

结果同时写到 %TEMP%\dsh-safe-restart.result.json，outcome 字段是三种之一：

outcome	含义
restarted-verified	进程回来了，端口也开始服务了
failed-to-come-up	进程拉起来了，但端口一直没响应
failed-to-kill / failed-to-relaunch	连杀/连拉起都没成功

实测证据（2026-11-08，本机）

12:15:57  Stop-Process 已发出（-Force）
12:15:57  进程已退出（0s）
12:15:59  第 1 次拉起成功（子进程 pid=73100）
12:16:10  自检通过：http://127.0.0.1:53820/ 返回 404（用时 10.5s）
12:16:12  已推送重启通知
12:16:12  done outcome=restarted-verified

三个踩出来的设计决定

1. helper 用 WMI 拉起，不能是宿主的子进程。 第一次实现时 helper 是 spawn 出来的子进程，强杀主进程时它被一起结束了（Job 连带），根本活不到"重新拉起"那步——结果就是应用关了、没再打开。现在改成写一个 .cmd 交给 Win32_Process.Create，它就从进程树外活下来了。

2. 端口探测要扫全部 DSH 进程。 HTTP 服务挂在子进程上（实测主窗口 pid 上一个监听都没有）。只看被杀的 pid 会得到"没有候选端口"，自检就退化成"进程活着就算起来"。

3. 通知放在 helper 里，不放在新宿主里。 "没起来"恰恰是最需要通知的情况——新宿主根本没机会说话。

它不做什么

• 不假装优雅（见开头）
• 不在 Linux/macOS 上工作（WMI + exe 路径都是 Windows 专属）
• 不替你决定该不该重启

装

dsh plugin --profile desktop add dsh-safe-restart

已知限制

• 强杀会跳过宿主退出时的一部分收尾（会话写回、bundle 组合）。能重启 ≠ 数据一定安全，重要操作前请自己确认保存。
• 自检判据是"端口返回 2xx-4xx"，只能证明 HTTP 服务活着，不能证明所有插件都正常加载。