无人值守运行
此模式适用于“这是计划，开始执行”：在无人键盘操作的情况下从头到尾实现整个计划，并确保当人类返回时工作可审查。它不限于特定时间段，适用于任何无人监控、无人回答问题的场景。
前提：已批准的计划
此模式不豁免“先提议后构建”（参见 coding-process）。它是在计划获得批准之后执行的步骤。在已批准的计划范围内，你可以自行决定可逆的实现细节，并将每个假设记录下来。一个有记录的假设胜过花费整夜等待的会话。这就是此模式的全部豁免范围。
四个不得自行越过的检查点
即使步骤是可逆的，这些仍然是检查点。这些都不是判断性问题。
- 范围。任何已批准计划未涵盖的内容：一个新功能、无人要求的重构，或因为实现困难而取消某个步骤。设置缺失的测试框架也属于范围问题。
- 任何离开机器的操作：外部消息、发布或调用第三方服务。仓库内的工作（分支、提交、推送、PR）属于计划范围内；与外部世界的通信则不属于。
- 任何涉及开销的操作：付费API、配置的基础设施、任何计费的内容。
- 任何具有破坏性或不可逆的操作：数据丢失、强制推送到共享分支、生产环境。
保持工作持久性
- 先隔离工作环境。使用工作树，除非工具已经为你提供了工作树。无人值守运行时，正是其他人可能接触到主检出的时刻。
- 在每个逻辑单元完成后进行提交和推送，而不仅仅是最后。未推送的工作会在会话突然结束时丢失。在此模式下，这覆盖了通常的“提交前请求确认”规则。
- 永远不要在暂停时留有未提交的工作。如果你的代理存在使用限制，请在接近限制时暂停，等待重置后再继续。
- 在检查点运行完整测试套件，而不是每次编辑后。在编辑过程中，运行能捕获当前修改的最窄检查：一个包的类型检查，或一个测试文件。在一个工作单元完成并推送审查前，运行构建、lint、完整测试套件和等同CI的检查。十分钟前刚跑过的套件，在未改动的代码上再次运行只会白白消耗计算资源且毫无收获。
委托（如果你的代理可以生成子代理）
- 将机械性工作委托给更便宜的模型：克隆现有结构、编写模板代码、同步文档、重复性编辑。将主模型用于正确性关键逻辑（模式、安全边界、核心服务）和判断性决策。
- 并发控制在约五个以内。超过这个数量，审计将失去实际意义，并行代理可能会冲突修改同一文件。
- 审计所有委托输出。切勿未阅读就整合子代理的输出。检查输出是否合理、遵循约定，并且构建和测试通过。当输出错误时，评估差距：小的错误自己修复，大的错误连同修正说明一起发回给子代理。
障碍处理
- 直接提出问题；不要猜测。当计划步骤遇到明确的检查点，或遇到真正的障碍（缺失的基础设施、失败的假设）时，要清晰地标记出来，而不是自己编造一个会改变设计的变通方案。
- 先完成所有不依赖答案的工作，这样人类返回时看到的是问题加上已完成的工作，而不仅仅是一个问题。
- 停滞的PR审查也是一个障碍。标记它，并在不依赖答案的本地环境中继续构建上游阶段。
无人监控时，UI验证不可省略
在无人监控时，驱动浏览器进行UI验证是最容易被忽略的步骤，而评审者在差异中无法看到它的缺失。请遵循 verify-ui。如果环境确实无法运行该功能（缺少凭据、不拥有的基础设施），请在PR的“测试”部分说明：指出是什么阻碍了测试，以及替代验证了哪些内容。沉默会被理解为“已验证”。
完成后
报告工作状态：已交付的内容（PR和分支）、等待审查的内容、做出的每个假设，以及标记的每个障碍。如果会话即将结束，请将这份报告写入 docs/plans/ 中的交接文档。