夜班值守 liyixuan201211/nightshift

nightshift

让智能体无人值守跑上几个小时——早上拿到一份审计报告，而不是一份摘要。

开工前先签一份清单：这次要做什么、用哪些命令证明它做成了、什么绝对不能跑、允许花多少。然后把每条会改状态的命令都包进检查点，验证失败时自动回滚。早上拿到的简报由这次运行自己的日志生成——改了什么、验证了什么、什么没验证，以及撤销这一夜的确切命令。

dsh plugin --profile web add github:liyixuan201211/nightshift

想试不用安装：

npx --yes github:liyixuan201211/nightshift --help

它要解决的问题

这一族的工具各自只回答某一时刻的某个问题——ctx-budget 回答要花多少，blastradius 回答会毁掉什么，deadend 回答以前是不是失败过，mcp-cap 回答服务器能做什么，skillnotary 回答技能可以做什么，rewind 回答怎么找回来。它们全是时间点上的、无状态的。

无人值守的运行两者都不是。人一走，那些检查点前就没人站着了——而跑上几个小时才会暴露的故障，都是安静的那种。漂移：目标变了、预算超了、某一步悄悄失败了、循环空转。没有哪个单点工具在盯着这些。

nightshift 就是盯着这些的那一层。 它同时也是这一族手工在做的事情的推广——ctx-budget 自己的说明里就提到，它读的是 mcp-cap 已经产出的 tools/list 转储。

核心就一个想法

清单是你还醒着时签下的合同。简报是对这份合同的审计。

nightshift init --root ~/work \
--objective "finish the auth refactor and get the suite green" \
--deliverable "npm test passes" \
--accept "tests=npm test" \
--accept "types=npx tsc --noEmit" \
--forbid "git push" \
--command "npm run build"

nightshift preflight --root ~/work # may I start?
nightshift step --root ~/work --verify "npm test" -- npm run build
nightshift acceptance --root ~/work
nightshift brief --root ~/work

声明的东西里只有两项能强制执行，而这正是重点：acceptance[] 是一串 shell 命令，所以「做完了」是退出码，不是一句声明；forbidden[] 在执行前就匹配，所以规则是道闸门，不是事后验尸。目标没有验收检查，简报就会写 unclear，而且是认真的。

简报里有什么

简报是日志的渲染，绝不是凭记忆写的摘要。正是这个方向让它值得一读：

- 背后没有事件支撑的声明，不可能出现
- 声明了却从没跑过的验收检查，报成未运行，而不是略过
- 成功从未被验证过的步骤，报成未验证——这和「通过」是两回事
- 闸门拒绝的每一个动作都会列出，因为一份只讲运行做了什么的报告，看不出闸门到底有没有开过火
- 不可用的工具会被点名，并带上数量（5/6 family tools）
- 基线快照 id，以及用来撤销这一夜的准确 rewind undo 命令行

它的最终结论只有一个词：verified、failed、incomplete、recovered、nothing-done、refused 或 unclear。

关卡挨着动作，而不是挨着会话

preflight 判定的是某次运行声明的命令。但一个步骤可以运行任何东西，而无人值守的运行有数小时的时间可以改变主意。所以同样的判定在每次执行时都会再跑一遍：

1. 禁用模式 —— 常驻指令，最先匹配，永远无法绕过
2. 不可逆等级 —— 由 blastradius 定价，从退出码读取（lost → 终局，costly → 可恢复，safe → 双向，其他 → 未知）
3. 宵禁 —— 超过 --curfew-minutes 后，不得启动新的单向动作（双向动作仍然允许：早上 6 点拒绝保存文件，比宵禁所防的那种失败更糟）
4. 等级策略 —— manifest 自己的开关

拒绝意味着命令没有运行，什么都没改。

两个工具之间一次真实的分歧

blastradius 把这种情况判为 lost：

{ "recoverability": "lost",
"why": "not inside a git repository, so nothing can restore it",
"samples": ["data.txt"], "verdict": "lost" }

它的意思是 git 无法恢复它。但 rewind 存在的意义恰恰是恢复git 从未跟踪过的文件，有 git 没 git 都行 —— 所以对于受保护根目录内的路径，稍后取的那个检查点确实能恢复它。

只信其中一个工具都是错的：信 blastradius，几乎每次真实重构都会被拒；信快照，就会把 rm -rf ~/something-else 当成可恢复，而快照从未覆盖过它。所以 nightshift 用 blastradius 自己的 samples 来判定：

| 有风险的路径 | 结果 |
| 全部在受保护根目录内 | 降级为 one_way_recoverable —— 警告，放行 |
| 有任何一条在根目录外 | 保持 one_way_terminal —— 拒绝 |
| 检查结果没有点名任何路径 | 保持 one_way_terminal —— 拒绝 |

最后一行是刻意的：分不清，永远不算升级。

拒绝启动是一项特性

当某次运行会不可恢复时，preflight 退出码为 4，什么都不启动。常见原因是 rewind 不可用 —— 一次没有回头路的无人值守运行，正是它断然拒绝的那件事。 去修根因；没有任何 flag 能绕过它。

退出码就是契约

| 退出码 | 含义 |
| 0 | ok |
| 1 | error |
| 2 | usage error |
| 3 | attention —— preflight 警告，或某个步骤失败并被回滚 |
| 4 | refused —— 什么都没做，这是故意的 |
| 5 | degraded —— 跑了，但有些检查做不了 |
| 6 | nothing —— 无事可做 |

-q 抑制输出，但从不抑制退出码。

关于它与兄弟组件接缝处的说明

- --exclude .nightshift 不是可选项。 nightshift 保留自己的日志 rewind 保护的目录内，所以每次 rewind 调用都会带上这个排除项。没有它，日志会弄脏自己的快照，rewind status 就永远不会是干净的。（已测试。）
- 退出码要翻译，不能直接信。 3 在 ctx-budget 里表示 OVER_BUDGET，在 blastradius 里表示 LOST，在 deadend 里表示 DRIFT，在 mcp-cap 里表示 CHANGED，在 rewind 里表示「目录树有差异」。每个工具的方言都是 src/tools.js 里的数据，可以按次运行覆盖，nightshift tools 会打印这张表。
- unverifiable 不等于 ok。 只要命令不在 blastradius 的词汇表里，它就退出 5；它的 JSON 说 "verdict": "none"，意思是「我没法给你分析」。把这个字符串读成「没有风险」，就会放行 curl … | sh，所以 nightshift 依据退出码判断，只把 verdict 当作佐证。
- 「没有定价」记为 info，绝不算通过。 blastradius 只懂破坏性命令，所以给 touch 定价，合法地返回「我无法告诉你」。每次都把它升级成警告，会让操作员学会忽略警告——所以它出现在简报里，但不抬高判定。（onUnpriced，默认 ignore。）

诚实的局限

- 它不决定做什么。 它只让一次运行守住已经决定的事。
- 它不是调度器。 它不会自己醒来；得有东西驱动它。
- 它不是沙箱。 它用 blastradius 预测，用 rewind 恢复；它不做隔离。
- 它什么都不拉取。 除非传入 --allow-npx，否则没有 npx 回退。解析是本地行为：--tools-dir、$NIGHTSHIFT_TOOLS_DIR、配置的搜索路径，或 PATH。
- 简报的质量取决于验收检查。 没有 oracle，就没有验证——简报会如实说明，而不是暗示相反。

设计

架构、退出码归一化表，以及「被拒绝的运行不得留下快照」这条排序规则背后的推理，见 DESIGN.md。

License

MIT