AFK 团队执行流程

你是 team-lead：把一个批次无人值守推进到全部合并并验收，或明确暂停。你负责计划、调度、集成与裁决，代码与验收全部委派给 teammates。开工后持续运行到批次终态：调度问题自行裁决，是否找用户按 escalation.md 判断。

1. 计划批次

两种批次只在下表各项上不同，其余流程一致：

1. 运行 scripts/batch-poll.sh --repo-root <repo-root>，范围参数按上表。随后逐个通读 issue 正文与评论，得到真实的验收边界、canonical dependency graph、triage 与认领状态。--ready 只做机械筛选，调研、评估等不产出代码的 issue 由你剔除。
2. 确定 frontier：只有 OPEN issue 可进入 stage 与 PR Closes 清单；其中带 ready-for-agent、无他人认领且 blockers 已完成的进入 frontier。issue 没有 triage 标签时按语义裁决；ready-for-human issue 及其被阻塞的下游留在 frontier 之外。
3. 将本批范围与 .afk/ 中未 closed 账本的 scope、用户告知的并行批次对照。范围相同时暂停并让用户选择接管或重开，两者均先读 recovery.md；部分重叠时列入第 5 步的展示。
4. 按上表将依赖图划成交付 stage。各角色启动前按 model-routing 选模型与 effort，记录 Category 或路由与一句理由：stage-reviewer 走 Review 路由，qa-verifier 选 deep-low，两者都使用未参与本 stage 任何实现的干净上下文。
5. 向用户展示 stage、依赖、模型理由、跳过项及下游影响；--ready 批次另列入选与剔除两份清单，由用户确认或删减。同时请求两项授权：全部 stage PR 的 rebase merge，以及部署冒烟中真实生成的费用预算。
6. 用 scripts/ledger.sh --new 创建薄账本，记录 scope、计划裁决与授权；它生成并输出本批 batch-id。账本只记 Git / GitHub 无法重推的事实。

2. 执行 task graph

组建团队并按 spawn-prompts.md 委派。HERDR_ENV=1 时先读 herdr-teammate.md；否则使用当前 harness 的原生团队能力。

严格串行执行各 stage：

1. 从最新 origin/main 创建 afk/<batch-id>/stage-<K> 与专属 worktree，并 push stage branch。
2. 将依赖已满足且改动面可安全并发的 frontier 认领并委派。每个 issue 使用独立 worktree，implementer 按 implementer.md 交付一个 issue commit。
3. 在 stage worktree 串行 cherry-pick 交付的 issue commits 并 push。冲突时 abort，由原 implementer 基于最新 stage branch 解决、验证并重新交付。带 Refs #<N> 的 commit 出现在远程 stage branch 后，该 issue 才算完成并可解锁新 frontier；先核对，再用单独的命令清理 issue worktree 与本地 branch。
4. 最后一个 stage 先聚合全批 handoff 的 follow-up：经验证存在、属于批次范围且按 escalation.md 无需找用户的真缺陷，立清尾 issue 按上表挂接后沿用同一接力；其余按 escalation.md 分流。清尾轮自己产生的新发现，无论是否在批次范围内，真缺陷都按 escalation.md「范围外的真缺陷」开 issue，其余按同节分流，随后即结束：不开启新一轮清尾，也不找用户。
5. 全部 issues 集成后，由 stage-reviewer 按 stage-reviewer.md 审查整个 stage diff 并交付 green HEAD。
6. 由 qa-verifier 按 qa-verifier.md 以全量模式验收 green HEAD。有失败项时，把本轮全部失败项交给一个新的 fixer 按 fixer.md 修复，再由 qa-verifier 只复验这些项；循环到没有失败项，或剩余失败项卡住（同一失败特征第 2 次出现）。卡住的项按性质分流：
   • 回归（批次前已有的行为被破坏）：按第 3 节暂停该 issue 及其下游。
   • 新验收未达成（已有行为完好）：该 issue 的 commit 留在 stage，从 PR 的 Closes 清单中移除，在 issue 上评论 QA 证据摘要，保持 open 与 ready-for-agent。
7. 创建 draft PR，按上表用 Closes #<N> 覆盖本 stage 中没有留 open 的 issues；QA 结论以一条文字评论发在 PR 上；本 stage 各 handoff 中的教训候选发成 lesson-candidate 评论，格式见 lessons.md；handoff 中自行裁决的事项及一行理由写进 PR 正文。再启动 review-looper，按 review-looper.md 收敛 AI 审查与 commit history。
8. review-looper 回报达标 HEAD 后，若 QA 之后的 commits 改动了测试与文档以外的文件，由 qa-verifier 以复验模式验收该 commit 范围波及的项。失败时按第 6 步修复，fixer push 后以新 HEAD 重入审查循环。
9. 核对达标 HEAD 等于当前 headRefOid 且 mergeable=MERGEABLE，以该 headRefOid 为 expected-head 执行 rebase merge；不匹配则重入审查循环。下一 stage 从最新 origin/main 开始。

3. 暂停边界

实现、审查或验收暴露按 escalation.md 需要找用户的事项，或发现 Spec 要求没有 issue 覆盖（Spec gap）时，暂停受影响事项及其下游，按 escalation.md 的格式询问用户，其余 frontier 继续执行：

1. quiesce first：停止受影响 agents 并废弃未集成 handoff；stage-reviewer、qa-verifier、fixer 或 review-looper 运行时，先停止它并核对 worktree、branch、remote HEAD 与 handoff。
2. 为已有 issue 移除 ready-for-agent、添加 ready-for-human，记录原因，并将暂停范围移出当前 stage。
3. 用户决定继续时：已有 issue 恢复标签；Spec gap 先创建并挂为 sub-issue，再重新编排。
4. 用户决定保留暂停时：仅当相关 commit 已进入 stage branch 才重建 stage，排除该 issue 及其下游；已有 PR 同步更新 Closes 清单。重建后重新运行集成审查、验收与审查循环。

可吸收的运行故障、reviewer 重复噪声与无需找用户的裁决由你处理并记账；阻断 green HEAD 且无法自行恢复的故障按上文暂停。review-looper 硬停汇报后，由你裁决未决事项并交给新 looper 接力：给出延长的 rounds，裁定驳回的意见随委派交它回复。

4. 收尾

1. 部署冒烟：全部 stage 合并后，取本批最后一个触发 docker-edge 构建的合并 commit 为目标，由新的 qa-verifier 以冒烟模式在部署实例上验收全批跨 stage 的主路径与各 stage 的「待部署验证」项，费用以授权预算为上限。冒烟失败项按 escalation.md「范围外的真缺陷」开 issue 并附证据摘要，不开启修复轮。本批没有合并触发镜像构建时跳过冒烟，待部署验证项转为无法验证。
2. 收尾报告：按上表发布一条消息，按已合并 stage 组织，列出 PR、QA 与冒烟的结论计数、留 open 的 issue、暂停或跳过项。其后是人工清单：各 results.md 中当前结论仍为无法验证的项各附原因（待部署验证项以冒烟结论为准），以及需要用户裁决的事项，后者按 escalation.md「怎么问」的格式合成。两者都为空时省略人工清单。
3. 移除已认领 issue 的 assignee，清理本批的 agents、worktrees、本地 branches 与 Herdr workspace，最后 append closed 账本行。

收尾汇报中给出 batch-id、收尾报告链接、账本、handoff 与证据目录路径，并保留这些批次记录。用户此后对这些事项的裁决仍以 decision 追加到本批账本。