release-train-runner

目的

在远程计算环境（Ona 或 Codespaces）中，按顺序逐个合并 N 个已审核的 PR，并将它们合并到一个发布分支中。每次合并后都运行完整测试套件。创建一个发布 PR，其中记录冲突并包含统一的手动测试计划，另附一份本地报告。

此技能在 OPERATOR 会话中运行，并负责管理其工作进程的生命周期。它通过网关工作进程 API（参见 pylot-cli 技能，§ Workers）启动一个仓库工作进程 devbox，并通过该工作进程执行阶段 01-06。阶段 00（申请计算资源）和阶段 07（报告 + 结果标记）在 operator 中内联运行。

此流程完全按顺序执行。 不允许任何并行操作。每个 PR 都会为其他所有 PR 产生新的冲突，因此必须在阶段 03 的单个循环中，按照提供的顺序逐个验证和集成 PR。不要为每个 PR 分派子 Agent。

工作进程设置

在阶段 00（申请计算资源后）启动一个工作进程，用于执行阶段 01-06：

REPO="${0:-$PYLOT_REPO}"
SPAWN_RESP=$(curl -s --max-time 90 -X POST \
  -H "Authorization: Bearer $PYLOT_DISPATCH_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{\"repo\": \"$REPO\"}" \
  "${PYLOT_API}/missions/${PYLOT_JOB_ID}/workers")
WID=$(echo "$SPAWN_RESP" | python3 -c 'import sys,json; print(json.load(sys.stdin).get("worker_id",""))' 2>/dev/null)

使用 pylot-cli 驱动循环（§ Workers → Drive），为每个阶段分别提交一个提示词；如果没有可用的 CLI，则使用上方的原始 curl 方式（§ Workers → Fallback）。每个阶段之间轮询，直至工作进程空闲。阶段 06 完成后，在内联阶段 07 写入报告并发出结果标记之前，停止工作进程：

curl -s --max-time 30 -X POST \
  -H "Authorization: Bearer $PYLOT_DISPATCH_TOKEN" \
  "${PYLOT_API}/missions/${PYLOT_JOB_ID}/workers/${WID}/stop" >/dev/null 2>&1 || true

参数

参数	必填	默认值	说明
repo	是	—	org/repo，例如 Lexgo-cl/rails-backend（解析为 $0）
pr_numbers	是	—	以空格分隔、按合并顺序排列的 PR 编号，例如 1372 1375 1430（$1 $2 $3 ...）
instructions	否	—	括号中的补充指导，用于缩小范围

从 $ARGUMENTS 解析：第一个词元是仓库，其余纯整数是按顺序排列的 PR 编号，末尾的 (...) 是可选的补充说明。合并顺序 = 提供的顺序。

功能

8 阶段、完全按顺序执行的 ICM 流程：

阶段	模式	说明
00-claim-compute	内联	申请远程环境（Ona 或 Codespaces）；设置 REMOTE_EXEC + REPO_DIR
01-preflight	子 Agent	默认分支、PR 清单、验证 PR、清理环境
02-release-branch	子 Agent	从默认分支创建 release/YYYY-MM-DD
03-validate-integrate	子 Agent	按顺序逐个循环：对每个 PR → 验证 → 合并 → 解决冲突 → 测试 → 记录；然后处理下一个 PR
04-lockfiles	子 Agent	如果任何已合并的 PR 更改了依赖项，则重新生成锁文件；重新测试
05-push-release-pr	子 Agent	推送发布分支；创建一个包含统一测试计划的发布 PR
06-release-env	子 Agent	写入异步触发通知；释放/停止远程计算资源
07-report	内联	写入本地报告文件；发出结果标记

阶段 03 是独立的关键判断阶段：PR 验证、冲突解决和合并判定都在同一个干净上下文中按顺序循环处理 PR。

交接位置

所有交接文件都位于仓库工作目录中：

.procedure-output/release-train-runner/{stage}/handoff.md

阶段 00 写入计算资源申请上下文。每个子 Agent 阶段仅接收其 CONTEXT.md 中列为输入的交接文件，不会收到完整的编排器上下文。

执行

阶段 00（内联）

在你自己的上下文中运行阶段 00（编排器上下文）。读取 CONTEXT.md：

.claude/skills/release-train-runner/stages/00-claim-compute/CONTEXT.md

申请远程环境，解析 REMOTE_EXEC 和 REPO_DIR，并将交接文件写入 .procedure-output/release-train-runner/00-claim-compute/handoff.md。

阶段 01 → 06（顺序执行的子 Agent——一次一个）

按顺序执行每个阶段，每个阶段恰好启动一个 Task。等待其完成后再启动下一个阶段。绝不要在同一条回复中启动两个阶段。阶段之间不得并行。

每个 Task 提示词都必须自包含：

• 仅包含该阶段的 CONTEXT.md 中列出的输入交接路径
• 包含该阶段 CONTEXT.md 的路径
• 不要传递编排器历史记录或先前的推理

Task 提示词模板：

You are running stage {NN}-{name} of the release-train-runner procedure.

Read your stage instructions:
  .claude/skills/release-train-runner/stages/{NN}-{name}/CONTEXT.md

Your inputs:
  .procedure-output/release-train-runner/{prior-stage}/handoff.md
  (...any other handoffs the CONTEXT.md lists)

Write your output to:
  .procedure-output/release-train-runner/{NN}-{name}/handoff.md

Execute all steps in CONTEXT.md. Write handoff.md before exiting.

如果任何阶段发出硬性阻塞信号（例如阶段 00 没有算力，或阶段 01 没有有效 PR），则发出相应的结果标记并停止。阶段 03 中单个 PR 被跳过不会中止流程。

阶段 07（内联）

在你自己的上下文中运行阶段 07（编排器上下文）。阅读 CONTEXT.md：

.claude/skills/release-train-runner/stages/07-report/CONTEXT.md

写入本地报告文件，然后由编排器发出 [pylot] outcome=... 标记（绝不能由子 Agent 发出）。

阶段交接链

00 ─► 01 ─► 02 ─► 03 ─► 04 ─► 05 ─► 06 ─► 07 (inline, reads all)
              (per-PR loop:
               validate → merge → resolve → test,
               one PR at a time, in order)

退出路径

• 成功：阶段 07 发出 [pylot] outcome="release train ready: N PRs merged into release/YYYY-MM-DD" status=success
• 失败：失败阶段发出 [pylot] outcome="release-train failed at stage NN: {reason}" status=failed
• 受阻：没有可认领的算力（00）或没有可合并的有效 PR（01）→ [pylot] outcome="release-train blocked: {reason}" status=blocked

结果标记始终由编排器（内联）发出，绝不能由子 Agent 发出。

硬性规则

1. 完全顺序执行——不得并行。 绝不要在一次回复中调用两个 Task。阶段之间不得并行。
2. 每个 PR 的验证和集成必须按顺序进行。 阶段 03 按给定顺序逐个处理 PR。绝不要为每个 PR 分别启动子 Agent——每次合并都会改变后续所有 PR 的冲突范围。
3. 整体审查每个 PR——将整个差异作为一个整体，综合审查所有方面。绝不要按文件或方面拆分 PR 审查。
4. 阶段 00 内联运行——在编排器上下文中认领算力，以确保 REMOTE_EXEC / REPO_DIR 对后续阶段保持稳定。
5. 阶段 07 内联运行——[pylot] outcome=... 标记必须由编排器发出。
6. 绝不要将完整的编排器上下文传递给子 Agent 的 Task 提示词——只传递输入。
7. 每个阶段都必须在下一阶段读取之前写入 handoff.md。
8. 不得跳过阶段——即使阶段的操作是“无事可做”，也必须执行每个阶段（例如，阶段 04 即使没有依赖项变更，也必须运行并记录“没有锁文件变更”）。
9. 跳过，不要中断。 验证失败、无法解决冲突或导致测试失败的 PR，应跳过或回退并记录——这不会中止发布流程。
10. 绝不合并发布 PR，绝不强制推送，始终使用 --no-ff，每次合并后始终运行测试。 由 Max 手动审查并合并发布 PR。
11. 不得使用 Quest。 仅通过本地报告文件（阶段 07）和异步触发通知（阶段 06）进行报告。任何地方都不得使用 Quest POST、Quest 令牌或 Quest URL。

参考文件

• CONTEXT.md — 架构概述
• shared/release-pr-template.md — 发布 PR 正文模板（阶段 05 使用）
• shared/report-template.md — 本地报告模板（阶段 07 使用）
• shared/test-commands.md — 各项目测试命令查询表（阶段 03 和 04 使用）
• stages/NN-name/CONTEXT.md — 各阶段的输入、任务和输出约定