# 并行开发与串行合入

状态：active；执行方式：manual。目标是让多个分支并行开发，同时避免所有分支随着
`main` 持续移动而反复同步、解决冲突和重跑最终 CI。

本规则只安排 Dev `refs/heads/main` 的最终交付顺序。各任务的需求、授权、阶段状态和证据
仍保存在原任务卡；受保护分支的最终准入仍由 Gitea 执行。

## 队列与职责

- Dev main 使用一份[合入队列 #518](https://git-home.u1680832.nyat.app:30319/weichen/Agent-System-Dev/issues/518)。
- 队列只记录顺序和当前窗口：任务/PR、owner、依赖、就绪状态、当前 base/head、CI、合入结果。
- 协调智能体维护顺序和窗口；任务 owner 负责分支内容和必要整改；窗口内的同步、冲突处置、Review、当前 HEAD CI 核验和所有 PR 合入由智能体执行。
- 普通功能 PR、修复 PR 和任务卡闭合 PR 都会移动 main，因此使用同一队列。组件仓按各自目标分支单独安排。

入队表示内容基本就绪且已取得该任务所需授权，不要求分支已经包含不断移动的最新 main。
依赖未完成或仍待必要人工决策的任务标为 `blocked`，不占窗口。默认按就绪顺序处理；紧急插队须在
#518 写明原因。

## 开发与等待

等待中的分支继续独立开发、提交和运行必要的局部检查，但不因为别的任务合入 main 就自动：

- 合并最新 main；
- 解决与最终交付无关的冲突；
- 推送新的最终候选；
- 重跑完整的最终 PR CI。

main 前进时，等待任务只记录“待轮到后同步”。开发期检查可以按任务需要运行，但不能作为之后
新 HEAD 的最终准入证据。

## 最终交付窗口

同一时间只给一个 Dev main 任务最终窗口。领取窗口前，协调智能体确认前一窗口已经释放、依赖
已完成，并在 #518 记录任务、PR、owner、当前 source HEAD 和领取时间。

窗口内按以下顺序执行：

1. 运行一次 `make task-sync`，纳入当时最新的 `origin/main`，解决冲突并核对组件组合。
2. 完成需要进入候选的代码、文档和任务卡内容，提交后固定 `base_sha` 与最终 `head_sha`。
3. 运行任务要求的本地检查；固定后的命令收据保存在源码外，避免为了记结果再改变 HEAD。
4. 对固定 PR HEAD 运行现有完整 CI；当前必需作业为 `test`、`test-pg`、`svc-realcombo`。
5. 完成当前 HEAD 的必要人工决策结论（如有）和智能体 Review。合入前再次核对 main、head、冲突和三项 CI。
6. 智能体使用固定 `head_commit_id`、`force_merge=false` 经 PR 合入，回读实际 main 与候选内容一致后释放窗口。

同一 base/head 下，验收、Review 和合入前的 `make task-sync` 只核验，输出 `changed=0`，不创建
额外提交，也不重复仍然有效的完整 CI。

## 对象变化与失败

以下任一对象变化都会使旧的最终结果失效：目标 base、候选 HEAD、组件 pin、检查定义或与结果
相关的环境。受影响任务保留旧结果的适用对象，回到队列等待新窗口；不得复制旧绿色状态或为了
省 CI 而降低检查。

冲突、代码/Review/CI 失败或等待必要人工决策时，当前任务保存现场、标为 `blocked` 并释放窗口，
其它分支继续局部开发。合入请求超时或返回不明时，先查询 PR 和 main 的真实状态；结果查清前
保持该目标暂停，不重复发送合入请求。

若窗口之外仍有 main 推进，当前固定候选按对象变化处理。协调智能体记录实际推进和受影响任务，
然后继续按队列安排；不要求为启用本规则证明所有历史写者、所有角色或自动互斥机制已经覆盖。

## 验收标准

一次排队交付满足以下条件即完成：

- 等待任务没有仅为追 main 而反复生成最终候选或重跑最终 CI；
- 轮到的任务只在窗口内同步最新 main，冲突在固定候选前解决；
- 实际合入的 HEAD 拥有当前必需 CI 和有效 Review；
- 合入由智能体执行，实际 main 内容与受审候选一致；
- 窗口结果写回 #518，随后才处理下一任务。

本规则不建设自动优先级、合并列车、批量预测合并、原子租约、旧执行者 fencing，也不修改
分支保护、CI workflow 或 runner 配置。将来需要自动队列时另行设计；不得从本 manual 流程推断
这些能力已经存在。