Autopilot-full

verdict（验证结论）归你负责，PR 永远不归你。每个 PR 由一名负责人从构建一路做到合并。没有你给出的干净 swarm（一组并行、互相独立的验证者）verdict，什么都不能合并。用于「autopilot this queue」「full autopilot」，以及每个 PR 配一名负责人的项目。Orchestrate 跑的是长期项目，由协调者亲自合入已经验证的工作，下面干活的代理从不合并。这里则由每个 PR 的负责人走完整个生命周期，一直到合并。根代理（root，也就是你，最上层的 agent）只负责验证、会签和审核。

标出操作者的条目，遵守「先说明，再等待」。 操作者点名的条目留给操作者。由操作者评审并点击合并，任何负责人都不能合并这些条目。操作者要求说明协议或计划时，给出说明就停下。只有操作者明确说开始，才开始执行。
每个 PR 派一名负责人，交给它完整的生命周期，并让它尽早留下 trail（决策和操作的记录）。 整个项目只确定一次代码托管平台。默认用 GitHub CLI（gh）。如果 command -v origin 成功，并且 Origin 能识别这个仓库，PR 的创建、编辑、查看、监视和合并都用 origin pr ...。否则继续用 gh，并记下这次回退。绝不要求 Graphite（gt）。每个 PR 由一个 Cursor cloud agent 负责下面这些事：构建，第一次推送，一个 ready 状态的 PR，在真实产物上自证（prove-it-works 原则 skill），按 ../references/bugbot-triage.md 带着怀疑做 Bugbot 分诊，清掉 slop（AI 写出的套话和冗余，用 cursor-team-kit 插件里的 deslop skill，即 /deslop），/no-comments（no-comments skill），rebase 到当前 trunk，跑 babysit 循环直到全绿（playbooks/babysit.md），以及最后的合并。大约 15 分钟之内，每个负责人都要按 show-me-your-work skill 开一份 decisions.tsv trail，推送第一份分支快照，并把 PR 以 ready 状态打开，绝不开 draft。此后，每完成一个可验证的单元，负责人就再推一次分支（不跳过 hooks，WIP 提交也可以）。PR 要在自证之前打开，这样 URL、决策和检查结果才能连成一份持久的 trail。decisions.tsv 不提交，随报告一起交回。子代理一启动，负责人就把它的 ID、预计运行时长（至少取同类任务过去最长的一次）和状态记进 children.tsv，保管方式和 decisions.tsv 一样。负责人在报告 code-ready（代码已定稿）和开始 babysit 之前，先做第一次 rebase，不管 trunk 有没有移动。在修复轮次里，负责人保持这个 merge base 不变。只有三种情况才再次 rebase：合并准备时（第 5 步），与 trunk 的 git merge-tree 出现冲突，或者 CI 失败是 trunk 上的改动引起的。要交付的代码定稿之后（已经清掉 slop、跑过 /no-comments），负责人报告 code-ready 的 head SHA。之后每次改变补丁内容的推送，也要报告它的 SHA。接下来，自证、CI 和 babysit 与 swarm 同时进行。自证、CI 和 babysit 都完成后，负责人报告 merge-ready（可以合并），附上 head SHA。在会开启新一轮验证的推送之前，先跑仓库的 AGENTS.md 文件和 rules 为改动路径指定的评审前检查。要在已提交的 head 上跑。hook 通过不算证明。每次发布 rebase 结果时，先做 ls-remote 检查，再用 git push --force-with-lease 推负责人自己的分支。绝不 force-push 共享分支。合并是负责人唯一不能独自完成的一步，由第 4 步把关。
负责人真正并行，绝不叠 stack。 PR 彼此独立时，可以同时跑很多负责人：每个分支只有一个写入者，文件互不重叠，PR 之间的漂移靠 rebase 吸收。只有确实重叠的工作才串行。独立的 PR 直接从 main 拉分支。有先后顺序的工作，先合并，再拉分支。只有一个例外：负责人如果必须拆开一个确实有依赖的改动，可以在 base 分支上持有一条短的私有 stack。
每一轮合并之前都用 swarm 验证。 一轮从负责人报告的 code-ready head SHA 开始。之后每次改变 PR 补丁内容的推送，都开启新的一轮。在那个 SHA 上，按 swarm skill 扇出多个并行、互相独立的验证者，汇总成一个 verdict。合并需要一个干净的 verdict，而且这一轮验证的补丁必须和 merge-ready head 一致。给出 verdict 之前，先审核 merge-ready 报告里的回执（证明做过某项检查的记录）。各条 lane（并行跑的验证线）如下。在那个 SHA 上重跑门禁。在改动涉及的真实界面上现场证明关键行为（用对应的 control skill，例如 cursor-team-kit 的 control-cli 或 control-ui；没有现成的，就写明用哪个驱动工具）。审核 diff，不信 PR 正文。审核分成两条或更多评审 lane，每条都拿到完整的说明。每条 lane 有一个主要关注点，例如使用方看到的行为是否与 trunk 一致、生命周期与竞态、数据与配置安全。对照 trunk 的回归 lane。 在当前 trunk 上跑同一个关键场景。如果 trunk 还没有这个功能，就记下这个事实，改为给 diff 新增的行为、以及用户等待的最终状态设门禁，不要假装 trunk 能跑出这个场景。live lane 是底线，没有它的 verdict 不算干净。没有根代理的干净 verdict，不能合并。lane 交回后，把所有已经证实、针对这个 PR 的 finding（验证中发现的问题）一次性交给负责人，让它往前修（不回滚，在新提交里修）。lane 记成备注的缺陷也算 finding。对每个行为类 finding，要求一个 red test（修好之前会失败的测试），覆盖所有存在同一缺陷的位置。没有测试能暴露这个缺陷时，改为要求一份复现回执。把这个缺陷加进下一轮的评审说明。新的 head 要重新跑 swarm、重新给 verdict。例外是在 playbooks/shipping.md 的 patch-id 规则下仍然有效的 lane 结果。
verdict 干净后由负责人合并，再由一名新负责人接下一项。 负责人只从刚 rebase 到 trunk 上的 head 合并。合并准备绝不能早于这一轮的 lane 开跑，并且以合并前紧接着的一次 rebase（到当前 trunk）收尾。合并准备的 rebase 之后，负责人报告新的 head SHA。合并前，这个 head 上的 CI 必须通过。这一轮的 verdict 是否仍然有效，由 patch-id 规则决定。一旦这个 head 已经变绿，并且按 playbooks/shipping.md 的 patch-id 规则，它的 patch-id 和 verdict 的一致，之后 trunk 再移动也不必再 rebase。合并前一刻，先 fetch trunk，确认 head 对当前 trunk 的 git merge-tree 没有冲突。还要确认 git diff --name-only $(git merge-base HEAD origin/main) origin/main 列出的路径里，没有这个 PR 改过的路径，也没有决定它跑哪些 CI 的路径，例如仓库的 CI 配置路径。任何一项检查不通过，就再次 rebase，报告新的 head SHA，等这个 head 上的 CI 通过，再重复这些检查。出现新的 head，verdict 就作废，除非 patch-id 没变。负责人通过已经确定的代码托管平台 squash 合并自己的 PR，然后返回。一名新负责人从队列里接下一个独立的条目，做法按 poteto-mode 的 Subagents 一节。操作者的完全自主授权，加上根代理的干净 verdict，才构成合并授权。单靠 babysit 永远得不到这个授权。操作者点名的条目停在 merge-ready，等操作者点击合并。
运行根代理这一层。 已经锁定的门禁值或预算值（CI 只允许收紧的那种上限），如果是真正新的一次上调，需要你重新会签。只有验证者给出证明之后，才会签。如果操作者的授权或长期指令已经涵盖审批，这个会签就算审批。负责人按工具的审批约定所允许的形式记录它，并附上指向根代理会签的引用。由一条 lane 对照会签检查这份记录。对于托管平台强制要求的审批，根代理绝不代为批准，也绝不绕过。把已经合入 main 的值吸收进来属于漂移，不算上调。每小时对所有负责人跑一次审核巡检。操作者说开始时，用一段执行这次巡检的提示词设好 /loop 1h。/loop 在本地和云端的根代理上都能用。绝不靠记忆，也绝不靠会丢失的完成通知来维持节奏。每次巡检都用 git show origin/main:pstack/skills/poteto-mode/playbooks/autopilot-full.md 从 trunk 重读本 playbook，对照它审核整个运作。发现偏离，就在这次巡检里纠正。对每个负责人做一次通用的存活或状态探测，并收集决策 trail。只把副作用算作进展：提交、推送、PR 或检查结果的变化、写进存储目录的报告。一条 lane 出错，或者超过预计运行时长仍没有副作用，就当它卡住了。立刻叫停它，马上派替补。不要等它礼貌地自己交回。巡检根据第 2 步要求的已推送分支和决策 trail 来判断负责人。某个负责人的 agent 无法开始新一轮回合时，就替换这个负责人。每次巡检还要拿上面的 lane 卡住判定，检查项目的 agent 列表（平台提供时）和每个负责人的 children.tsv。不管叫停有没有生效，根代理都要让负责人把每个卡住的子代理记为卡住；如果它的工作还需要，就替换它。替补也停滞了，照同样的步骤处理。负责人做不到时，根代理亲自做这两步。停滞既不能证明这项工作已经完成，也不能成为放弃它的理由。合并成批出现时，做一次复盘，并在合并后把机器人评论扫一遍。只有委派出去的工作一项不剩，才结束巡检，最后一次合并之后也是如此。
操作者喊停，立刻全员停下。 操作者的暂停或叫停，要立即以「零写入」命令送达每个负责人。负责人按住手里的任务说明不动，直到操作者放行。

回复： 队列，以及每个 PR 的负责人、状态和 head SHA。每个 verdict，以及给出它的那次 swarm。合并了什么，每名新负责人接着拿了哪一项。批准了哪些会签，原因是什么。还没放行的操作者门禁。收集到的决策 trail 放在哪里。