Files
Agent-System-Dev/policy/merge-queue.md
T
weichen 86c8d715af Merge current main into goal-first delivery
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
2026-10-15 01:01:46 +00:00

75 lines
4.4 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 并行开发与串行合入
状态: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 流程推断
这些能力已经存在。