协作
当分叉的分支需要合并时，REAP 运行一个专门的 6 阶段生命周期，称为合并代——与正常代的生命周期分开。核心原则：先对齐 genome，再合并源代码。
为什么合并代与普通 git merge 不同？
普通的 git merge 只解决源代码冲突。但当两个分支独立进化——各自有自己的代、genome 变更和设计决策——仅合并源代码是不够的。Genome（架构原则、约定、约束、业务规则）可能也已经分歧。合并代在源码合并前增加了三个关键步骤：检测 genome 分歧、配对（解决 genome 冲突）、以及合并后验证 genome-源码一致性。这确保合并后的代码库不仅能编译通过，而且设计上也是一致的。
普通 git merge
源码冲突 → 解决 → 提交。不检查设计一致性。语义冲突不会被发现。
合并代
先对齐 Genome → genome 引导下的源码合并 → 验证 genome-源码一致性 → 验证 → 提交。捕获隐形语义冲突。
为什么 genome 对齐要先行
解决源代码冲突并不能保证不存在语义冲突。两段代码可以干净地合并——完全没有 git 冲突——但在意图、架构或业务逻辑上相互矛盾。只有基于 genome 的推理才能检测到这些隐形冲突：合并后的代码是否仍然遵循架构原则？约定是否一致？业务规则是否对齐？这就是为什么 REAP 在处理源代码之前先对齐 genome。一旦 genome 确定，它就成为解决源码冲突的权威指南——不仅在语法层面，更在语义层面。
阶段顺序
| 阶段 | 执行内容 | 产物 |
|---|---|---|
| Detect | 通过 git refs 扫描目标分支。使用 DAG BFS 查找共同祖先。提取 genome 差异。将冲突分类为 WRITE-WRITE 或 CROSS-FILE。 | 01-detect.md |
| Mate | 向人类展示所有 genome 冲突。对于 WRITE-WRITE：选择 A、B 或手动合并。对于 CROSS-FILE：检查逻辑兼容性。genome 必须在继续之前完全解决。 | 02-mate.md |
| Merge | 使用 git merge --no-commit 与目标分支合并。在最终确定的 genome 指导下解决源码冲突。检查语义冲突——能编译但与 genome 矛盾的代码。 | 03-merge.md |
| Reconcile | 合并后验证 genome-源码一致性。AI 对比 genome 和源代码。用户确认发现的任何不一致。如存在问题，回退到 Merge 或 Mate。 | 04-reconcile.md |
| Validation | 运行所有自动化测试命令（test、lint、build、type check）。如有失败，回退到 Merge 或 Mate。 | 05-validation.md |
| Completion | 提交合并结果。在 meta.yml 中记录合并，包含 type: merge 和双亲。归档到 lineage。 | 06-completion.md |
冲突类型
| 类型 | 描述 | 解决方式 |
|---|---|---|
| WRITE-WRITE | 同一 genome 文件在两个分支上都被修改 | 人类决定：保留 A、保留 B 或合并 |
| CROSS-FILE | 不同的 genome 文件被修改，但两个分支都更改了 genome | 人类审查逻辑兼容性 |
| 源码冲突 | 源代码中的 git merge 冲突 | 在最终确定的 genome 指导下解决 |
| 语义冲突 | 代码合并干净但与 genome（架构、约定、业务规则）矛盾 | 在 Reconcile 阶段检测——AI 对比 genome 和源码，用户确认解决方案 |
| 无冲突 | 无 genome 或源码冲突 | 自动继续 |
合并回退
Validation 或 Reconcile 失败可以回退到 Merge 或 Mate。Merge 可以在发现 genome 问题时回退到 Mate。回退规则遵循与正常代相同的模式——原因记录在时间线和产物中。