# 关系分类与证据标准

在 `gitlink-pr-topology` 中，不要把“有点像”直接写成“重复”。先按下面的证据标准分型。

## 1. depends_on

适用场景：

- 一条 PR 的描述明确写了依赖另一条 PR
- 下游 PR 直接建立在上游新增的命令、结构体、API 包装或测试夹具之上
- 不先合并上游，当前 PR 的验证、评审或主线集成都缺前提

高置信证据：

- 描述或评论中明确提到 `depends on #xx`
- 两条 PR 的 head/base 明显形成链条
- 下游代码直接引用上游新增符号

## 2. overlaps_with

适用场景：

- 解决同一个 issue 或同一个用户需求
- 修改同一命令入口或同一子模块
- 标题不同，但行为目标一致

高置信证据：

- 相同 issue 编号或相同命令名
- 相同文件集合重叠明显
- 两条 PR 的帮助文案或输出字段目标一致

## 3. supersedes

适用场景：

- 两条 PR 明显重叠，但其中一条覆盖范围更完整
- 较新的 PR 已吸收较旧 PR 的核心思路和大部分实现点
- 保留两条 PR 已没有意义

高置信证据：

- 功能覆盖包含关系明显
- 更强 PR 同时补齐测试、文档、兼容性
- 较弱 PR 长期未更新，而较强 PR 已响应 review 并继续演进

## 4. conflicts_with

适用场景：

- 两条 PR 改动同一热点文件
- 两条 PR 对同一 flag、同一 JSON 字段、同一错误提示给出不同方案
- 未来即使都要保留，也一定会互相重写或产生合并冲突

高置信证据：

- 同一文件相邻区域同时被修改
- 同一命令帮助文本或参数行为相互不兼容
- 一个 PR 的默认值选择与另一个 PR 相反

## 5. review_together

适用场景：

- 几条 PR 涉及相同模块，但没有明显冲突
- 一起 review 更容易统一命名、参数和输出风格
- 拆开看会让维护者重复加载同一上下文

高置信证据：

- 同一目录、同一组件、同一命令族
- 目标互补而非互斥

## 6. merge_after

适用场景：

- 不是严格依赖，但某 PR 最好在另一条 PR 之后处理
- 上游 PR 会影响接口、帮助文案或目录结构，下游先审价值不高

高置信证据：

- 上游 PR 改的是底层封装，下游 PR 改的是调用层
- 先合并下游会造成明显返工

## 低置信措辞

证据不足时，使用保守措辞：

- `possible_overlap`
- `possible_dependency`
- `possible_conflict`

不要在证据不足时使用 `supersedes`。
