Why: Synchronize the approved policy candidate with the active simplified merge-window rules now on origin/main. Evidence: Resolved the two semantic conflicts by preserving upstream queue simplification and this task's goal-first/cursor-per-unit contract; focused task-card regression and cached diff checks passed. Impact: Retains the active single-window delivery process while replacing mechanical stage approvals with necessary decisions and preserving Cursor-per-unit execution. Refs: .task/feature-goal-first-delivery.md
75 lines
4.4 KiB
Markdown
75 lines
4.4 KiB
Markdown
# 并行开发与串行合入
|
||
|
||
状态: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 流程推断
|
||
这些能力已经存在。
|