# 常驻监督进程与日志静默看门狗

## 否决了什么

为 CM 运行加一个常驻的监督角色，在任务卡住时自动提醒。被否的三种形态：

| 形态 | 结论 |
| ---- | ---- |
| 日志一段时间没变化就报警的通用看门狗 | 否决 |
| 系统级定时巡检（例如 launchd 定时任务） | 用户否决 |
| 宿主进程自带一个通过管道感知存活的监督子进程 | 用户否决 |

## 为什么

| 理由 | 证据 |
| ---- | ---- |
| 看门狗误报太多 | 在一个真实项目的历史里，约三分之二的「长时间没动静」是正常等待：长检查（一次 16–33 分钟）、等人审、隔夜。大量运行从不写结束事件，不能用「不是终态」判卡死。为了让日志看起来活着而补写心跳，违反 `runtime/logging.md` |
| 用户要求监督者与任务同生共死 | 系统级常驻定时器不随任务结束，用户不接受这种形态 |
| 管道监督的价值没有数据支撑 | 同一项目 8 天 107 次宿主启动里，已证实的宿主意外死亡是 0 次；多数重启是脚本主动关闭 |
| 真正的空转在会话编排层 | 去重后的 8 件被停后台任务里，4 件是模型自己写的等待命令条件错或没设超时，2 件是驱动命令没设外层时限，2 件是工具卡住（例如非交互调用没关输入）。插件内的监督进程管不到这些 |

最终只改文档：`skills/cm-ai/references/js-host.md` 启动前清单写明拆单步、后台命令设超时、等待用运行时接口、非交互调用关输入；用户指南删掉 launchd 教程并收紧提醒承诺。

## 什么条件变了可以重开

- 有记录证明宿主进程意外死亡，且现有的入口核对没有报出来。
- 宿主运行时（Claude Code、Codex）提供了随会话结束而结束、并能可靠唤醒的后台监督能力。
- 提醒日志里出现真实的发送失败，需要补发队列。

## 提过的时间

- 2026-10-09：四次多轮对抗分析，最后结论为只改文档。相关已合并改动：#191、#193、#194、#195。