dsh-self-restart

让 DSH 里的 Agent 能「自己重启自己」，并且重启完自己醒过来接着干。

DSH 桌面版是个常驻进程：改了插件、改了配置、内存涨了、偶尔卡住了，都得关掉再打开。但这里有个死结 —— 关掉 DSH 就等于关掉正在干活的 Agent 自己，它没法一边关自己一边把自己拉起来。

这个插件提供那个「替它做」的东西。

平台：仅 Windows 桌面版。它靠 WMI 创建脱离进程、靠 taskkill / 窗口消息关闭应用，换平台要另写一套。

核心：一次重启，多个会话各自续命

如果只记一件事，记这个：

它把「重启」做成一个可并发复用的动作。 几个会话可以把各自的活挂到同一次重启上，重启完再把它们各自叫醒、各自拿回自己的理由、各自判断要不要接着干。

这不是「A 重启完再轮到 B」，而是并成一趟：

会话 A：restart_self(reason="改完插件要验证")  ┐
会话 B：restart_self(reason="等配置生效")      ├─→ 同一趟车（最多 8 人，谁先来谁先上）
会话 C：restart_self(reason="清理内存")        ┘   ← 还可以在等待途中随时加入
                          ↓
              等**所有人**都不忙 → 关一次 → 拉起一次 → 验证端口
                          ↓
   并发唤醒：A 拿"改完插件要验证" / B 拿"等配置生效" / C 拿"清理内存"
                          ↓
        A、B、C 各自跑起来，互不等待 —— 一台机器上三条活同时重新开始

为什么这是"并发"而不是"排队处理" —— 两个阶段都成立，但要分开说：

阶段	行为	是不是并发
排队	任意时刻、任意会话都可以把自己的活挂到同一趟车上；等待途中也能随时加入	✅ 并发加入
重启	只关一次、只拉一次 —— 不管车上有 1 人还是 8 人	一次动作，不是 N 次
唤醒	逐条投递（一条失败不影响其余，也不用等上一个人跑完）	投递是串行的
醒后	每个会话独立跑自己那一轮，互不等待、互不阻塞	✅ 真并发执行

⚠️ 一个容易写错的点，这里说清楚：唤醒消息是逐条投的，不是同时群发。但那只是投递动作的先后，投完就各自跑了 —— 不是"排队执行"，后醒来的不用等先醒的干完。

这带来五个别处没有的性质：

性质	意味着什么
只关一次、只拉一次	3 个人排队，不是重启 3 次。整台机器只中断一次，中位几十秒
每人各拿各的理由	唤醒消息是按 `成员 × 自己的 reason` 逐条投的，不是群发一句通用话
每人各自决定续不续接	同一趟车里 A 选 `resume: true`、B 选 `resume: false` 都行 —— 逐人判断，不是一刀切
一个失败不拖累其余	逐人记账（`resume:<单号>:<会话id>`）：B 投递失败，A 和 C 照常被叫醒
可以各自下车	名单里永远是"发车之后要叫醒谁"。谁不想被叫醒就摘掉自己，其余人照常 —— 见下

两种退出方式，别用错：

调用	影响范围	什么时候用
`restart_status(leave: true)`	只有你自己	"这车跟我没关系了"——车照开，不叫醒我；我是最后一个人则整趟不发车
`restart_status(cancel: true)`	整趟车所有人	"这趟别开了"——包括别人的重启一起作废

⚠️ 只是自己不想要了，永远该用 leave。用 cancel 会把别人的重启一起打掉。

为什么值得这样设计：多个会话同时要重启是常态（改完插件，几个窗口都在等）；而且重启期间整台机器是停的，每多一次重启就多一次中断。所以正确的模型不是"每个会话各排各的"，而是"一次中断，服务所有人"。

⚠️ 代价也要说清：一趟车里只要还有人没空闲，整趟都会等。人越多，等到空档越难。所以「取消」是整趟取消 —— 这也正是它必须让你先看名单的原因。（只想让自己退出、不想连累别人的，用「下车」，见下面对两者区别的说明。）

什么时候你不需要它

只是想手动重启一次 → 不需要，直接重启 DSH 更快。
不跑长任务、也不在意会话被打断 → 不需要，它解决的是"重启完要接着干"。
不是 Windows 桌面版 → 用不了，见「已知边界」。

它真正省事的是这个场景：你自己不在电脑前，但希望 Agent 把活干完、需要重启时自己排上、重启完自己醒过来继续 —— 而不是第二天回来发现卡在某个报错上。

它提供什么

一句话定位：把「重启宿主」变成一个可被多个会话并发复用的动作。 不是"每个会话各重启一次"，而是"一次中断，服务所有排队的会话"。

工具	干什么
`restart_self`	排一次「延时重启」：等真正空闲后，由一个脱离进程的助手把 DSH 关掉、重新拉起、并验证端口真的回来了
`restart_status`	看有没有待执行的重启、现在忙不忙、上次重启成不成、这台机器重启要多久；也能「下车」或「取消」

① Agent 调 restart_self
② 还可以有别的会话陆续排进来（同一趟车，最多 8 人；等待途中也能随时加入）
③ 助手（脱离进程）等所有人都不忙了 → 关掉 DSH → 重新拉起 → 验证端口
④ 起来后插件按名单**逐条**把唤醒消息投进每个会话（各拿各的理由）
⑤ 每个会话被唤醒后就**各自跑起来**，互不等待 —— 一次重启，N 条活同时续上

几条设计取舍（会影响你怎么用它）

绝不强行打断别人。 有别的会话在忙就排队等，不是作废、也不是硬闯。默认一直等（maxWaitMinutes: 0），超过 notifyAfterMinutes（默认 20 分钟）还没发车会走一次通知钩子（见「外部通知」）。
不想被叫醒就「下车」，不要用「取消」。 这是两个不同的出口：
- restart_status(leave: true) —— 只影响你自己：把你这一个会话从叫醒名单里摘掉。车上还有别人 → 车照开，只是不会叫醒你；摘完没人了 → 这趟本来就没人为它等了，直接不发车。
- restart_status(cancel: true) —— 影响整趟：车上所有人的这次重启一起作废。所以取消之前先调一次 restart_status() 看名单（它会列出每个人 + 各自的理由 + 你在不在里面）。
一句话区分：leave 是"这车跟我没关系了"，cancel 是"这趟别开了"。 只是自己不想要了，永远该用 leave —— 用 cancel 会连累别人。
不弹窗打扰，但有一张不阻塞的状态卡片。 卡片上有三个出口：「不等了，立刻重启」（只跳过"等家务"）、「打断」按钮（取消整趟）、右上角的 ✕。「打断」和 ✕ 写的是同一个取消标记；「不等了」写的是另一个标记（force.flag），只影响"还要不要等家务"。
排队时会在会话标题前挂 ♻️ ，一眼能看出谁在等；上次重启失败的会话挂 ⭕ （2 小时后自动消失）。 ⚠️ 从 IM 通道来的会话，图标排在频道前缀后面（QQ · ♻️ 原标题）。原因：有插件会按「开头是不是 QQ · 」判断要不要补前缀，图标抢到最前面会让它反复补。兼容范围（实测）：认 16 个常见渠道标签，清单内收敛；清单外若对方只加一次也幂等。
一趟车结束就封口。 取消 / 失败 / 成功三条路都会删掉计划文件、清掉取消标记，否则会出现"已取消"和"待执行"同时成立的假状态。
「关掉了却没人拉起来」是唯一不可接受的后果。 所以除了主助手，还有一个保险丝进程：万一主助手在关机途中死了，保险丝负责把 DSH 拉回来。

安装

本插件是一个标准的 DSH bundle（package.json 里带 dsh.bundle.patch，自带 cordis.patch.yml）。

方式一：用 DSH 的插件管理（推荐）

让 Agent 调用它自带的 plugin_manager 工具：

plugin_manager(action="install_bundle", target="<本目录的绝对路径>")

install_bundle 会自己完成「装包 + 选中 bundle」两件事。

⚠️ 不要用 shell 命令模拟这两步（拷目录、手改 profile 的 package.json / cordis.patch.yml、在 profile 目录里跑 pnpm）—— 这是 DSH 官方文档明确禁止的做法。

方式二：本地开发时用 workspace 链接

把本目录登记进 profile 的 package.json：

{
  "dependencies": { "dsh-self-restart": "workspace:*" },
  "dsh": { "profile": { "bundles": [ "dsh-self-restart" ] } }
}

然后在 profile 目录里装一次依赖、重启 DSH。（仓库自带的 deploy.ps1 就是给这种方式配套的：源码 → 实际加载位置的同步 + 对账。）

依赖

Node 内置模块（fs / path / os / child_process / url / crypto）；
@deepseek-ai/schemastery —— 由 DSH 宿主提供（所以同时列为 peerDependencies）。

「重启完自己醒过来」用的是 DSH 自带的正式服务 sessionController （随发行版默认挂载）—— 不需要实验 bundle，也不需要额外安装任何东西。

配置

所有配置项都有默认值，写在 lib/index.js 的 Config schema 里；要改就在自己 profile 的 cordis.patch.yml 里覆盖同名 id 的 config：

- id: self-restart
  config:
    idleSeconds: 12
    notifyAfterMinutes: 20

配置项	默认	说明
`enabled`	`true`	总开关
`port`	`19387`	兜底端口；实际端口每 10 秒从宿主现取
`dshExe`	`''`	DSH 主程序路径；留空 = 自动找
`stateDir`	`''`	状态目录；留空 = `%DSH_HOME%\self-restart`
`idleSeconds`	`12`	「自己这一轮说完了」要连续静默多少秒
`othersWindowSeconds`	`120`	「别人还在忙」的判定窗口
`confirmBufferSeconds`	`5`	排上之后留给回复落盘的缓冲
`confirmSeconds`	`10`	动手前的确认窗（卡片上有倒计时，仍可打断）
`maxWaitMinutes`	`0`	最多等多久；`0` = 一直等（另有 12 小时硬上限）
`checkSeconds`	`10`	助手的轮询间隔
`bootTimeoutSeconds`	`90`	拉起后等端口回来的上限
`maxAttempts`	`3`	拉起失败后的重试次数
`notifyAfterMinutes`	`20`	等这么久还没发车就通知一次；`0` = 不通知
`notifyRepeat`	`false`	要不要重复通知
`notifyRepeatMinutes`	`60`	重复通知的间隔
`noticeCommand`	`''`	外部通知命令（见下节）；空 = 完全不通知
`noticeTimeoutMs`	`30000`	通知命令超时，超时就杀掉
`waitForImDirect`	`true`	IM 私聊算不算「有人在用」
`waitForAllSessions`	`false`	所有会话都 idle 才动手（含群聊）
`queueMaxMembers`	`8`	同一趟车最多几个人
`wakeMessage`	`true`	重启成功后要不要把唤醒消息投回原会话
`wakeMessageMaxChars`	`600`	唤醒消息里原样带回 `reason` 的字数上限
`wakeDelaySeconds`	`3`	起来后等几秒再投唤醒消息（等服务就位）
`resumeHint`	`''`	唤醒消息里附一句自定义提示（留空 = 不提）

外部通知（notice hook）

本插件不内置任何通知渠道。 它只在特定事件发生时，执行你自己配置的一条命令，把事件内容通过环境变量交给它 —— 发不发、发给谁、用什么发，全在那条命令里。

为什么这样设计

通知渠道属于使用者环境，不属于插件。写死某个渠道等于要求每个使用者都装同样的东西；没装就静默失败，那比没有通知更糟。所以这里只留一个接口，默认关闭。

怎么配

- id: self-restart
  config:
    noticeCommand: 'node C:\tools\my-notify.mjs'

命令里用环境变量取内容：

环境变量	内容
`DSH_SR_EVENT`	事件名，见下表
`DSH_SR_TEXT`	一句话正文（已经是单行，可直接发）
`DSH_SR_PLANID`	这趟重启的单号
`DSH_SR_COUNT` / `DSH_SR_ELAPSED` / `DSH_SR_WAITEDMIN` 等	各事件附带的标量字段（字段名大写归一）

`DSH_SR_EVENT`	什么时候触发
`restart-queued-long`	等了 `notifyAfterMinutes` 还没发车
`restart-done`	重启成功且之前发过"还在排队"通知（配对，不刷屏）
`wake-failed`	重启成功，但没能叫醒排队的会话
`restart-failed`	重启失败或被取消

安全边界

插件只执行 noticeCommand 这一条你自己写的命令，不执行 DSH_SR_TEXT 等 payload 里的任何内容 —— payload 只作为环境变量传入，不参与解释。
命令由 shell 执行（所以可以带参数、管道、重定向）。这意味着命令本身有完整权限 —— 只写你信任的命令，别把会话内容拼进去。
有超时（noticeTimeoutMs）、有并发上限（同时最多一条在跑）、失败只记日志。
通知失败绝不影响重启：重启是该做的事，通知是锦上添花。

重启完自己醒过来接着干

重启成功后，插件会把一条消息投进原会话（不是定时提醒、不是系统提示），会话因此被驱动起来跑一轮 —— 带回来的正是你当初写的 reason。

resume: false 的重启（收尾型）不叫醒。
投递是**「至多一次」的：宁可偶尔"这次没叫醒、需要手动开"，也绝不允许同一次重启投出两条 —— 两条一样的「接着干」会让同一件活被干两遍。所以顺序是先记账、再投递、投不进去才回滚**。
消息投出去就撤不回了：restart_status(cancel: true) 只能拦住还没投递的。

「闲下来」是怎么判断的：两段式

第一段：等自己这一轮说完。 连续 idleSeconds 没有新动静。
第二段：等别人。 再看一遍全部会话，othersWindowSeconds 内写过会话的算「在动」。

不是所有"别人"都一样：

来源	算不算"有人在用"	说明
本地窗口	算
IM 私聊	算（`waitForImDirect` 可关）	私聊那头随时可能来人
IM 群聊	不算	那是机器人在跟别人聊，重启中位只有几十秒
查不到	算（保守）	宁可多等

⚠️ 默认值下，"自动找空闲"可能经常等不到：如果你有大量 IM 私聊会话，第一个该考虑调的就是 waitForImDirect。

「不等了，立刻重启」

等家务等到没完时，卡片上的「不等了，立刻重启」只跳过等家务这一段，不是强制关闭别人的对话。它写的是 force.flag，和「打断」（写 cancel.flag）是两回事。

状态文件在哪

%DSH_HOME%\self-restart\（默认 ~\.dsh\self-restart\）：

文件	是什么
`state.json`	插件每 10 秒写的实时状态（端口、在跑的会话、待执行的重启）
`plan.json`	当前这一趟重启的计划；没有待执行重启时不存在
`last-run.json`	上一次重启的结果（助手写）
`history.jsonl`	流水账，一行一次
`reported.json`	插件自己的记账（哪些已汇报、哪些已通知）
`helper.log` / `plugin.log`	助手 / 插件的日志
`notify-<planId>.json`	通知配对用的记账

日志会一直留着，需要时自己清理。

开发

改完怎么让它生效

改了 lib/index.js → 必须重启宿主（Node 侧代码不会热加载）。
改了 bin/*.ps1 → 下次排重启就生效（助手是现读现跑的）。

开发目录和 DSH 实际加载的目录是分开的，用 deploy.ps1 同步 + 对账：

pwsh -NoProfile -File deploy.ps1 -Check     # 只对账（0=一致 / 5=不一致）
pwsh -NoProfile -File deploy.ps1 -DryRun    # 预演会复制哪些文件
pwsh -NoProfile -File deploy.ps1            # 真正同步

跑测试

powershell -NoProfile -ExecutionPolicy Bypass -File test\run-all-tests.ps1
powershell ... -File test\run-all-tests.ps1 -Only 'test-helper','test-two-phase'   # 只跑指定几套

⚠️ 测试全程不碰真 DSH：所有用例都用假目标（假 exe / 假端口 / 假会话目录），每套末尾还有"真 DSH 监听者 PID 没变"的断言兜底。

目录结构

lib/index.js              插件主体（工具注册、状态轮询、唤醒投递、标题标记）
lib/notice-hook.js        外部通知钩子（执行用户配置的命令）
bin/dsh-self-restart.ps1  助手：等待 → 关闭 → 拉起 → 验证 → 写结果
bin/dsh-restart-window.ps1 状态卡片（WPF）
cordis.patch.yml          bundle 补丁（挂载点）
deploy.ps1                开发目录 → 加载目录 的同步 + 对账
test/                     自测（ps1 + mjs）

它内部怎么做的（想改代码再看）

为什么要「脱离进程」的助手：它用 WMI 创建，父级是系统的 WmiPrvSE， 不在 DSH 的进程树里 —— 所以 DSH 被杀掉之后它照样活着，能把 DSH 拉回来。（同一个脚本有三种身份：点火器负责把自己脱离出去，正主动手关/拉，保险丝守「正主死在半路」这一种最坏情况。）

为什么「先确认拉得起来，才允许动手关」：曾经用了一个不存在的主程序路径做自测，助手照样先把 DSH 杀了，杀完才发现没法拉起。所以动手前有一道硬闸：主程序不存在 / 是 0 字节 / 读不到 → 原地退出，DSH 一根汗毛不动。

为什么宽限期只有几秒：taskkill 不带 /F 是给窗口发 WM_CLOSE，而 DSH 的退出条件是 window-all-closed —— 它有多个顶层窗口，可见的只有一个，其余是隐藏的功能窗口，不会被外部关闭请求关掉。所以「礼貌关闭」在结构上就不可能让它退出，等多久都一样。

已知边界

只在 Windows 桌面版上工作。 找不到主程序就明确失败，绝不乱猜路径。
sessionController 服务是自动唤醒的前提（DSH 自带，正常组合下都在）。拿不到 → 不会有「重启完自动叫醒」，但重启本身照常。
唤醒只在 outcome=success 时投递：重启失败 / 被取消 / 没执行（skipped-busy）都不会叫醒 —— 失败时叫醒 Agent 继续干会把故障掩盖掉。
投递是「至多一次」（刻意的），见上文。
通知是「尽力而为」：noticeCommand 失败、超时、没配，都不影响重启本身。

许可

MIT

dsh-self-restart

让 DSH 里的 Agent 能「自己重启自己」，并且重启完自己醒过来接着干。

这个插件提供那个「替它做」的东西。

平台：仅 Windows 桌面版。它靠 WMI 创建脱离进程、靠 taskkill / 窗口消息关闭应用，换平台要另写一套。

核心：一次重启，多个会话各自续命

如果只记一件事，记这个：

它把「重启」做成一个可并发复用的动作。 几个会话可以把各自的活挂到同一次重启上，重启完再把它们各自叫醒、各自拿回自己的理由、各自判断要不要接着干。

这不是「A 重启完再轮到 B」，而是并成一趟：

会话 A：restart_self(reason="改完插件要验证")  ┐
会话 B：restart_self(reason="等配置生效")      ├─→ 同一趟车（最多 8 人，谁先来谁先上）
会话 C：restart_self(reason="清理内存")        ┘   ← 还可以在等待途中随时加入
                          ↓
              等**所有人**都不忙 → 关一次 → 拉起一次 → 验证端口
                          ↓
   并发唤醒：A 拿"改完插件要验证" / B 拿"等配置生效" / C 拿"清理内存"
                          ↓
        A、B、C 各自跑起来，互不等待 —— 一台机器上三条活同时重新开始

为什么这是"并发"而不是"排队处理" —— 两个阶段都成立，但要分开说：

阶段	行为	是不是并发
排队	任意时刻、任意会话都可以把自己的活挂到同一趟车上；等待途中也能随时加入	✅ 并发加入
重启	只关一次、只拉一次 —— 不管车上有 1 人还是 8 人	一次动作，不是 N 次
唤醒	逐条投递（一条失败不影响其余，也不用等上一个人跑完）	投递是串行的
醒后	每个会话独立跑自己那一轮，互不等待、互不阻塞	✅ 真并发执行

这带来五个别处没有的性质：

性质	意味着什么
只关一次、只拉一次	3 个人排队，不是重启 3 次。整台机器只中断一次，中位几十秒
每人各拿各的理由	唤醒消息是按 `成员 × 自己的 reason` 逐条投的，不是群发一句通用话
每人各自决定续不续接	同一趟车里 A 选 `resume: true`、B 选 `resume: false` 都行 —— 逐人判断，不是一刀切
一个失败不拖累其余	逐人记账（`resume:<单号>:<会话id>`）：B 投递失败，A 和 C 照常被叫醒
可以各自下车	名单里永远是"发车之后要叫醒谁"。谁不想被叫醒就摘掉自己，其余人照常 —— 见下

两种退出方式，别用错：

调用	影响范围	什么时候用
`restart_status(leave: true)`	只有你自己	"这车跟我没关系了"——车照开，不叫醒我；我是最后一个人则整趟不发车
`restart_status(cancel: true)`	整趟车所有人	"这趟别开了"——包括别人的重启一起作废

⚠️ 只是自己不想要了，永远该用 leave。用 cancel 会把别人的重启一起打掉。

什么时候你不需要它

只是想手动重启一次 → 不需要，直接重启 DSH 更快。
不跑长任务、也不在意会话被打断 → 不需要，它解决的是"重启完要接着干"。
不是 Windows 桌面版 → 用不了，见「已知边界」。

它提供什么

一句话定位：把「重启宿主」变成一个可被多个会话并发复用的动作。 不是"每个会话各重启一次"，而是"一次中断，服务所有排队的会话"。

工具	干什么
`restart_self`	排一次「延时重启」：等真正空闲后，由一个脱离进程的助手把 DSH 关掉、重新拉起、并验证端口真的回来了
`restart_status`	看有没有待执行的重启、现在忙不忙、上次重启成不成、这台机器重启要多久；也能「下车」或「取消」

① Agent 调 restart_self
② 还可以有别的会话陆续排进来（同一趟车，最多 8 人；等待途中也能随时加入）
③ 助手（脱离进程）等所有人都不忙了 → 关掉 DSH → 重新拉起 → 验证端口
④ 起来后插件按名单**逐条**把唤醒消息投进每个会话（各拿各的理由）
⑤ 每个会话被唤醒后就**各自跑起来**，互不等待 —— 一次重启，N 条活同时续上

几条设计取舍（会影响你怎么用它）

绝不强行打断别人。 有别的会话在忙就排队等，不是作废、也不是硬闯。默认一直等（maxWaitMinutes: 0），超过 notifyAfterMinutes（默认 20 分钟）还没发车会走一次通知钩子（见「外部通知」）。
不想被叫醒就「下车」，不要用「取消」。 这是两个不同的出口：
- restart_status(leave: true) —— 只影响你自己：把你这一个会话从叫醒名单里摘掉。车上还有别人 → 车照开，只是不会叫醒你；摘完没人了 → 这趟本来就没人为它等了，直接不发车。
- restart_status(cancel: true) —— 影响整趟：车上所有人的这次重启一起作废。所以取消之前先调一次 restart_status() 看名单（它会列出每个人 + 各自的理由 + 你在不在里面）。
一句话区分：leave 是"这车跟我没关系了"，cancel 是"这趟别开了"。 只是自己不想要了，永远该用 leave —— 用 cancel 会连累别人。
不弹窗打扰，但有一张不阻塞的状态卡片。 卡片上有三个出口：「不等了，立刻重启」（只跳过"等家务"）、「打断」按钮（取消整趟）、右上角的 ✕。「打断」和 ✕ 写的是同一个取消标记；「不等了」写的是另一个标记（force.flag），只影响"还要不要等家务"。
排队时会在会话标题前挂 ♻️ ，一眼能看出谁在等；上次重启失败的会话挂 ⭕ （2 小时后自动消失）。 ⚠️ 从 IM 通道来的会话，图标排在频道前缀后面（QQ · ♻️ 原标题）。原因：有插件会按「开头是不是 QQ · 」判断要不要补前缀，图标抢到最前面会让它反复补。兼容范围（实测）：认 16 个常见渠道标签，清单内收敛；清单外若对方只加一次也幂等。
一趟车结束就封口。 取消 / 失败 / 成功三条路都会删掉计划文件、清掉取消标记，否则会出现"已取消"和"待执行"同时成立的假状态。
「关掉了却没人拉起来」是唯一不可接受的后果。 所以除了主助手，还有一个保险丝进程：万一主助手在关机途中死了，保险丝负责把 DSH 拉回来。

安装

本插件是一个标准的 DSH bundle（package.json 里带 dsh.bundle.patch，自带 cordis.patch.yml）。

方式一：用 DSH 的插件管理（推荐）

让 Agent 调用它自带的 plugin_manager 工具：

plugin_manager(action="install_bundle", target="<本目录的绝对路径>")

install_bundle 会自己完成「装包 + 选中 bundle」两件事。

⚠️ 不要用 shell 命令模拟这两步（拷目录、手改 profile 的 package.json / cordis.patch.yml、在 profile 目录里跑 pnpm）—— 这是 DSH 官方文档明确禁止的做法。

方式二：本地开发时用 workspace 链接

把本目录登记进 profile 的 package.json：

{
  "dependencies": { "dsh-self-restart": "workspace:*" },
  "dsh": { "profile": { "bundles": [ "dsh-self-restart" ] } }
}

然后在 profile 目录里装一次依赖、重启 DSH。（仓库自带的 deploy.ps1 就是给这种方式配套的：源码 → 实际加载位置的同步 + 对账。）

依赖

Node 内置模块（fs / path / os / child_process / url / crypto）；
@deepseek-ai/schemastery —— 由 DSH 宿主提供（所以同时列为 peerDependencies）。

「重启完自己醒过来」用的是 DSH 自带的正式服务 sessionController （随发行版默认挂载）—— 不需要实验 bundle，也不需要额外安装任何东西。

配置

所有配置项都有默认值，写在 lib/index.js 的 Config schema 里；要改就在自己 profile 的 cordis.patch.yml 里覆盖同名 id 的 config：

- id: self-restart
  config:
    idleSeconds: 12
    notifyAfterMinutes: 20

配置项	默认	说明
`enabled`	`true`	总开关
`port`	`19387`	兜底端口；实际端口每 10 秒从宿主现取
`dshExe`	`''`	DSH 主程序路径；留空 = 自动找
`stateDir`	`''`	状态目录；留空 = `%DSH_HOME%\self-restart`
`idleSeconds`	`12`	「自己这一轮说完了」要连续静默多少秒
`othersWindowSeconds`	`120`	「别人还在忙」的判定窗口
`confirmBufferSeconds`	`5`	排上之后留给回复落盘的缓冲
`confirmSeconds`	`10`	动手前的确认窗（卡片上有倒计时，仍可打断）
`maxWaitMinutes`	`0`	最多等多久；`0` = 一直等（另有 12 小时硬上限）
`checkSeconds`	`10`	助手的轮询间隔
`bootTimeoutSeconds`	`90`	拉起后等端口回来的上限
`maxAttempts`	`3`	拉起失败后的重试次数
`notifyAfterMinutes`	`20`	等这么久还没发车就通知一次；`0` = 不通知
`notifyRepeat`	`false`	要不要重复通知
`notifyRepeatMinutes`	`60`	重复通知的间隔
`noticeCommand`	`''`	外部通知命令（见下节）；空 = 完全不通知
`noticeTimeoutMs`	`30000`	通知命令超时，超时就杀掉
`waitForImDirect`	`true`	IM 私聊算不算「有人在用」
`waitForAllSessions`	`false`	所有会话都 idle 才动手（含群聊）
`queueMaxMembers`	`8`	同一趟车最多几个人
`wakeMessage`	`true`	重启成功后要不要把唤醒消息投回原会话
`wakeMessageMaxChars`	`600`	唤醒消息里原样带回 `reason` 的字数上限
`wakeDelaySeconds`	`3`	起来后等几秒再投唤醒消息（等服务就位）
`resumeHint`	`''`	唤醒消息里附一句自定义提示（留空 = 不提）

外部通知（notice hook）

为什么这样设计

怎么配

- id: self-restart
  config:
    noticeCommand: 'node C:\tools\my-notify.mjs'

命令里用环境变量取内容：

环境变量	内容
`DSH_SR_EVENT`	事件名，见下表
`DSH_SR_TEXT`	一句话正文（已经是单行，可直接发）
`DSH_SR_PLANID`	这趟重启的单号
`DSH_SR_COUNT` / `DSH_SR_ELAPSED` / `DSH_SR_WAITEDMIN` 等	各事件附带的标量字段（字段名大写归一）

`DSH_SR_EVENT`	什么时候触发
`restart-queued-long`	等了 `notifyAfterMinutes` 还没发车
`restart-done`	重启成功且之前发过"还在排队"通知（配对，不刷屏）
`wake-failed`	重启成功，但没能叫醒排队的会话
`restart-failed`	重启失败或被取消

安全边界

插件只执行 noticeCommand 这一条你自己写的命令，不执行 DSH_SR_TEXT 等 payload 里的任何内容 —— payload 只作为环境变量传入，不参与解释。
命令由 shell 执行（所以可以带参数、管道、重定向）。这意味着命令本身有完整权限 —— 只写你信任的命令，别把会话内容拼进去。
有超时（noticeTimeoutMs）、有并发上限（同时最多一条在跑）、失败只记日志。
通知失败绝不影响重启：重启是该做的事，通知是锦上添花。

重启完自己醒过来接着干

重启成功后，插件会把一条消息投进原会话（不是定时提醒、不是系统提示），会话因此被驱动起来跑一轮 —— 带回来的正是你当初写的 reason。

resume: false 的重启（收尾型）不叫醒。
投递是**「至多一次」的：宁可偶尔"这次没叫醒、需要手动开"，也绝不允许同一次重启投出两条 —— 两条一样的「接着干」会让同一件活被干两遍。所以顺序是先记账、再投递、投不进去才回滚**。
消息投出去就撤不回了：restart_status(cancel: true) 只能拦住还没投递的。

「闲下来」是怎么判断的：两段式

第一段：等自己这一轮说完。 连续 idleSeconds 没有新动静。
第二段：等别人。 再看一遍全部会话，othersWindowSeconds 内写过会话的算「在动」。

不是所有"别人"都一样：

来源	算不算"有人在用"	说明
本地窗口	算
IM 私聊	算（`waitForImDirect` 可关）	私聊那头随时可能来人
IM 群聊	不算	那是机器人在跟别人聊，重启中位只有几十秒
查不到	算（保守）	宁可多等

⚠️ 默认值下，"自动找空闲"可能经常等不到：如果你有大量 IM 私聊会话，第一个该考虑调的就是 waitForImDirect。

「不等了，立刻重启」

状态文件在哪

%DSH_HOME%\self-restart\（默认 ~\.dsh\self-restart\）：

文件	是什么
`state.json`	插件每 10 秒写的实时状态（端口、在跑的会话、待执行的重启）
`plan.json`	当前这一趟重启的计划；没有待执行重启时不存在
`last-run.json`	上一次重启的结果（助手写）
`history.jsonl`	流水账，一行一次
`reported.json`	插件自己的记账（哪些已汇报、哪些已通知）
`helper.log` / `plugin.log`	助手 / 插件的日志
`notify-<planId>.json`	通知配对用的记账

日志会一直留着，需要时自己清理。

开发

改完怎么让它生效

改了 lib/index.js → 必须重启宿主（Node 侧代码不会热加载）。
改了 bin/*.ps1 → 下次排重启就生效（助手是现读现跑的）。

开发目录和 DSH 实际加载的目录是分开的，用 deploy.ps1 同步 + 对账：

pwsh -NoProfile -File deploy.ps1 -Check     # 只对账（0=一致 / 5=不一致）
pwsh -NoProfile -File deploy.ps1 -DryRun    # 预演会复制哪些文件
pwsh -NoProfile -File deploy.ps1            # 真正同步

跑测试

powershell -NoProfile -ExecutionPolicy Bypass -File test\run-all-tests.ps1
powershell ... -File test\run-all-tests.ps1 -Only 'test-helper','test-two-phase'   # 只跑指定几套

⚠️ 测试全程不碰真 DSH：所有用例都用假目标（假 exe / 假端口 / 假会话目录），每套末尾还有"真 DSH 监听者 PID 没变"的断言兜底。

目录结构

lib/index.js              插件主体（工具注册、状态轮询、唤醒投递、标题标记）
lib/notice-hook.js        外部通知钩子（执行用户配置的命令）
bin/dsh-self-restart.ps1  助手：等待 → 关闭 → 拉起 → 验证 → 写结果
bin/dsh-restart-window.ps1 状态卡片（WPF）
cordis.patch.yml          bundle 补丁（挂载点）
deploy.ps1                开发目录 → 加载目录 的同步 + 对账
test/                     自测（ps1 + mjs）

它内部怎么做的（想改代码再看）

已知边界

只在 Windows 桌面版上工作。 找不到主程序就明确失败，绝不乱猜路径。
sessionController 服务是自动唤醒的前提（DSH 自带，正常组合下都在）。拿不到 → 不会有「重启完自动叫醒」，但重启本身照常。
唤醒只在 outcome=success 时投递：重启失败 / 被取消 / 没执行（skipped-busy）都不会叫醒 —— 失败时叫醒 Agent 继续干会把故障掩盖掉。
投递是「至多一次」（刻意的），见上文。
通知是「尽力而为」：noticeCommand 失败、超时、没配，都不影响重启本身。

许可

MIT

NOOBnoob163/dsh-self-restart

dsh-self-restart

核心：一次重启，多个会话各自续命

什么时候你不需要它

它提供什么

几条设计取舍（会影响你怎么用它）

安装

方式一：用 DSH 的插件管理（推荐）

方式二：本地开发时用 workspace 链接

依赖

配置

外部通知（notice hook）

为什么这样设计

怎么配

安全边界

重启完自己醒过来接着干

「闲下来」是怎么判断的：两段式

「不等了，立刻重启」

状态文件在哪

开发

改完怎么让它生效

跑测试

目录结构

它内部怎么做的（想改代码再看）

已知边界

许可

Community comments

NOOBnoob163/dsh-self-restart

dsh-self-restart

核心：一次重启，多个会话各自续命

什么时候你不需要它

它提供什么

几条设计取舍（会影响你怎么用它）

安装

方式一：用 DSH 的插件管理（推荐）

方式二：本地开发时用 workspace 链接

依赖

配置

外部通知（notice hook）

为什么这样设计

怎么配

安全边界

重启完自己醒过来接着干

「闲下来」是怎么判断的：两段式

「不等了，立刻重启」

状态文件在哪

开发

改完怎么让它生效

跑测试

目录结构

它内部怎么做的（想改代码再看）

已知边界

许可

Community comments