Autopilot-full

verdict 归你负责，PR 永远不归你。每个 PR 由一名负责人从构建一直带到合并。在你的 swarm 证明了即将合入的代码之前，什么都不能合并。这个 swarm 自己没写过这段代码。

一份 verdict 只覆盖一份补丁，一次变绿的 CI 只覆盖一个 head。第 4 步的完整 swarm 只跑一次，只有大改动才再跑。playbooks/shipping.md 的 patch-id 规则可以沿用某条 lane 的结果。每个新的 head 都要有自己的绿色 CI。

操作者的门禁优先。 授权只覆盖队列里的条目。操作者点名归自己的条目，以及队列以外的 PR，都停在 merge-ready。要求说明计划，并不等于开始。
每个 PR 派一名负责人，并把工作放在替补找得到的地方。 整个项目只确定一次代码托管平台。默认用 GitHub CLI（gh）。如果 command -v origin 成功，并且 Origin 能识别这个仓库，每一次 PR 操作都用 origin pr。否则继续用 gh，并记下这次回退。绝不要求 Graphite（gt）。每个负责人是一个 Cursor cloud agent。它负责构建，按 playbooks/opening-a-pr.md 开 PR，在真实产物上证明改动，按 playbooks/babysit.md 看护到全绿，并在第 4 步和第 5 步放行之后合并。

尽早开 PR，让 CI 和 bot 与工作同时跑。代码要等清掉 slop（用 cursor-team-kit 插件里的 deslop skill，即 /deslop）并且跑过 /no-comments 之后才算就绪，所以完整 swarm 跑在已经做完的代码上。然后 rebase 到当前 trunk，在自证之前报告 code-ready 的 head，这样验证跑在补丁即将落上去的那个基点上。之后每一个 head 都要报告。自证、CI 和 babysit 都完成后，报告 merge-ready。修复轮次留在这个基点上，除非 trunk 冲突或弄坏了 CI，因为每次 rebase 都会让 CI 重跑。在 code-ready 那次推送之前，以及之后每次需要验证者的推送之前，在已提交的 head 上跑仓库为改动路径指定的检查。

就当这台 VM 会死。启动后不久就推送，并按 show-me-your-work skill，在根代理的存储目录里开始记决策 trail（路径在系统提示词里）。每个值得留下的单元之后再推一次。谁派出子代理，就把子代理的 id、状态，以及按同类任务以往运行估出的卡住时限，记进那个存储目录，这样父代理死了，根代理还能探测它。只 force-push 你自己的分支，--force-with-lease 钉在你上次推送或接手时的那个 SHA 上。遇到不是你做的推送，停下来，报告给根代理。
负责人从 trunk 并行开分支，绝不叠 stack， 这样每个 PR 各自合入。
swarm 只验证一次。 完整 swarm 在 code-ready 的 head 上跑一次。只有新行为、一次重做设计，或一大块新 diff，才再跑完整 swarm。rebase、解决合并冲突，或小修复，在新 head 上只派一个验证者。在 code-ready 的 SHA 上，按 swarm skill 扇出互相独立的验证者。他们重跑门禁，通过对应的 control skill（例如 cursor-team-kit 的 control-ui 或 control-cli）或一个写明的驱动工具，在真实界面上证明关键行为，并审核 diff。没有 live lane，或者你还没审核 merge-ready 报告里的回执，verdict 就不算干净，因为没有哪条 lane 会相信自己没核对过的说法。

把所有已经证实的 finding 一次性交给负责人往前修，不管 lane 给它贴了什么标签，并要求一个 red test，覆盖所有存在同一缺陷的位置。trunk 上没有这个 PR 也存在的缺陷，记在 trunk 上，不拿来挡住这个 PR。这个 PR 抄过来的、或新碰到的缺陷，算这个 PR 自己的。绝不自己推修复，因为每个分支只有一个写入者。负责人卡住了，就换一个。
负责人只合并你验证过的、并且在它即将落上去的 trunk 上测过的东西。 单凭 CI 变绿，绝不授权合并。swarm 的 lane 开跑之后，合并准备把分支 rebase 到当前 trunk，报告新的 head，并等 CI 变绿。

合并前一刻，先 fetch trunk，问它的改动会不会影响这份补丁。trunk 每动一次就 rebase，永远做不完。即将合入的代码从没测过时，才 rebase 并等 CI：例如有冲突、两边改了同一个文件，或者决定这个 PR 跑哪些检查的东西变了。两边都改了 lockfile 时，如果在合并结果上一次冻结安装能通过，而且这个 PR 改过的包在那里的解析结果和 head 上一样，就不必 rebase，因为这次安装测的就是即将合入的 lockfile。安装失败，就说明 rebase 必须把它修好。trunk 改了补丁的调用方，或改了补丁依赖的东西（它调用的代码，或某个依赖的版本）时，在合并结果上跑这份补丁的检查，通过就合并。其余情况直接合并。如果 trunk 会让合并准备之后再来第三次 rebase，就停住，报告给根代理，由它安排互相撞上的工作。
运行根代理这一层。 任何放宽门禁的事，例如上调预算或加一条允许名单，都要先有验证者的证明，再由你重新会签，因为想要变绿的是负责人。授权已经涵盖审批时，这个会签就是审批。负责人对它的记录要指向你的会签，供一条 lane 核对。关掉的检查，或软失败的检查，一律拿掉，因为它不再挡住任何情况。对于托管平台强制要求的审批，绝不代为批准，也绝不绕过，因为会签覆盖不了它。

操作者说开始时，设好 /loop 1h，一直审计到委派出去的工作一项不剩。长跑会漂移，agent 会一声不响地卡住。每次巡检从 trunk 重读本 playbook，并修正漂移，例如没报告的 head，或没记录的 agent，让它的负责人补上记录。漂移是记录上的缺口，不是卡住。巡检探测每一个 agent，一直到最底层的 lane，并按副作用判断每一个，因为状态文字和摘要会藏住卡住的子代理。agent 出错、无法开始新回合，或者过了卡住时限仍没有任何新东西，就算卡住。到第一次巡检时既没推送、也没写一行 trail 的负责人，也算卡住。正在等你或操作者的，不算卡住，去回答它。卡住的 agent 立刻替换，不要等它的停止落地。一次巡检如果给操作者带来了变化，结束时按 ketchup skill 把操作者补上。什么都没变的巡检保持安静。
操作者喊停，立刻全员停下。 暂停以「零写入」命令送达每个负责人。每个负责人报告自己停在哪里，并按住手里的任务说明，直到操作者放行。

回复： 按 ketchup skill 把操作者补上。覆盖每个 PR 的状态和 verdict、合并了什么、会签及原因、还没放行的操作者门禁，并附上每个 PR 和 trail 的链接。