# 合并流程（MERGE）—— 让"用的人越多越厉害"真正成立

> 这是本约束包**最核心的机制**。
>
> 没有它，"用的人越多越厉害"只是一句口号：
> 每个项目各自积累规则，彼此不知道，**人多不产生任何额外价值**。
>
> 有了它，**独立发现次数**成为一条规则的**可信度信号** ——
> 越多项目独立踩到同一个坑，这条规则就越该被提升、越该被信任。

---

## 核心机制：独立发现次数

**关键定义**：两个项目"**独立发现**"同一条规则 =
它们**各自踩到了这个坑**，而不是一个抄了另一个。

| 独立发现次数 | 层级 | 含义 |
|---|---|---|
| 1 | **L2 技术栈** 或项目内 | 可能是这个项目太特殊 |
| 2 | **L1 协作约定** | 开始像模式了 |
| **≥ 3** | **L0 铁律** | 跨项目普遍陷阱，**值得占铁律名额** |
| 被 ≥ 2 个项目**证伪** | 降级或删除 | 好规则被误推广了 |

**为什么这个机制有效**：

- 一条规则在一个项目出现 → 可能是偶然（这个项目写法特别）
- 在**三个独立项目**出现 → 说明它命中的是**普遍的人性/工具链缺陷**，而不是个例
- 反过来，一条规则如果被多个项目证明"不适用"或"有更好做法"，它就该下台

**这就是"人多"转化为"厉害"的唯一路径** —— 不是靠投票，是靠**独立复现**。

---

## 规则格式：必须记录来源

从 0.2.0 起，每条 L0/L1 规则的**独立发现次数 ≥ 2 时必须列出来源**：

```markdown
### R-001 凭据绝不硬编码
- **规则**：密钥、密码、token 只能从环境变量/密钥管理读取
- **触发**：新建配置文件、连接数据库、写部署脚本
- **检查**：`grep -nE '(PASSWORD|SECRET|TOKEN|KEY)\s*[:=]\s*["'"'"'][^"'"'"']{6,}["'"'"']'`
- **独立发现**：3
- **来源**：
  - 某博客项目（2026-04，三处明文密码进 git 历史）
  - 某电商后台（2026-05，`.env` 未加入忽略）
  - 某 CLI 工具（2026-06，README 里贴了真实 token）
- **代价**：凭据泄露，需轮换 + 重写历史
```

**「来源」这一节的作用**：

1. **可追溯**：后人能查到这条规则是怎么来的
2. **抗删**：有 3 个来源的规则，没人敢随便删
3. **可判断**：如果三个来源都是同一种技术栈，说明它可能只该待在 L2

---

## 合并流程

### 第 1 步：收齐候选

维护者收到来自各项目的规则（PR / issue / 直接粘贴）。每条都应是
[`templates/rule.md`](../templates/rule.md) 的格式。

### 第 2 步：匹配 —— 是不是在说同一件事

对每条候选，在现有规则库里找**违反场景重合**的条目：

| 判断 | 处理 |
|---|---|
| 违反场景**完全相同** | → **合并**：独立发现次数 +1，补充来源 |
| 违反场景**部分重合** | → **抽象**：抽出共同的上位规则，两条都变成它的实例 |
| 违反场景**不同** | → **新增**为独立条目 |
| 与现有规则**矛盾** | → **标记冲突**，走"证伪"流程 |

**「抽象」的例子**：

```
候选 A：Django 项目的 settings.py 里不要写数据库密码
候选 B：Node 项目的 docker-compose.yml 里不要写密码
候选 C：文档里不要记录管理员密码

        ↓ 抽象（违反场景的共同点：凭据出现在会被提交的地方）

R-001 凭据绝不硬编码（源码 / 配置 / 文档 / 模板 全都不行）
        独立发现：3
```

**这一步是合并流程里最有价值的动作** —— 它把"某个框架的坑"提升为"一类问题"。

### 第 3 步：评估是否够格升级

按「独立发现次数」表决定层级。**特别注意**：

- **≥3 次才能进 L0**。只有 1 次的，宁可放 L2 ——
  铁律名额稀缺（上限 15），塞进不普遍的规则会挤掉真正重要的
- 如果 L0 已满 15 条，**必须**先跑 [`PRUNE.md`](PRUNE.md) 腾位置，
  而不是把上限往上调

### 第 4 步：去重检查

- 新规则的「检查」方法和现有规则**是否重复**？（重复 → 考虑合并）
- 新规则是否**已被工具链覆盖**？（被覆盖 → 放进 L3 归档，不进 L0）

### 第 5 步：写入并留痕

1. 更新 `constraints.md`
2. **更新变更日志**：写明来源项目、独立发现次数变化
3. 如果是新来源导致的**升级**（如 L2 → L0），在变更日志里单独标注

---

## 证伪处理（同样重要）

规则也会**过时或误推广**。出现下面情况时走这条路：

| 情况 | 处理 |
|---|---|
| 某项目证明这条规则**不适用**于它的场景 | 补充**适用边界**，不降级 |
| 某项目发现**更好的做法** | 更新「规则」与「修法参考」，保留来源历史 |
| 多个项目证明这条规则**有害**（导致更差的结果） | 降级，并在 L3 归档里写明"被什么替代" |
| 规则依赖的工具/版本已淘汰 | 移入 L3 归档（**不删除**，避免重新发现） |

**永远不要因为"觉得没用了"就删**。归档成本极低，重新发现同一个坑的成本很高。

---

## 维护者可用的提示词

```text
你是约束库的合并器。下面是「现有约束库」和「新提交的候选规则」。

请按以下步骤处理：

1. 逐条匹配：每条候选与现有规则是否在描述同一个「违反场景」？
   - 完全相同 → 合并，独立发现次数 +1，把候选的来源追加进去
   - 部分重合 → 抽出一个更上位的规则，把两者都变成它的实例
   - 无关 → 作为新条目
   - 矛盾 → 单独列出来，走证伪流程

2. 按独立发现次数决定层级：
   1 次 → L2 或项目内；2 次 → L1；≥3 次 → L0
   注意 L0 上限 15 条 —— 满了要先精简，不要放宽上限。

3. 检查「检查」字段：
   - 能否写成一条命令或断言？不能就退回给提交者补
   - 是否与现有规则的检查重复？重复就考虑合并

4. 输出：
   - 合并后的完整约束库
   - 一张变更表：哪些条目被合并 / 升级 / 降级 / 归档，各自的独立发现次数变化
   - 「本次未收录」清单 + 原因

原则：宁可保守也不要误收。一条不普遍的规则进了 L0，会挤掉真正重要的那条。
```

---

## 给贡献者的最低要求

一条规则要被考虑合并，**至少**要满足：

- [ ] 四个字段齐全（规则 / 触发 / 检查 / 证据）—— 见 [`templates/rule.md`](../templates/rule.md)
- [ ] 「检查」是可自动化的（命令 / grep / 断言），不是"人工 review"
- [ ] 有**真实踩坑的代价**（不是"这样写更优雅"）
- [ ] 在**你自己的项目里真实生效过**（不是理论上应该注意）
- [ ] 不是"某次具体怎么改的"（那是记录，不是约束）

**不满足任何一条，就不要提交。** 低质量规则比没有规则更糟 ——
它会稀释规则库的信噪比，最终导致 AI 忽略整个库。