# Bugfix 专用链路

## 目标

把复杂缺陷固化成可复现、可修复、可防回归的行为契约。此阶段不猜根因、不扩大为新功能。

## 流程

1. **证据回放**：收集环境、版本、前置数据、最小复现步骤、日志/截图/失败测试和发生频率。无法复现时标 `unconfirmed`，继续调查，不能编造。
2. **行为三分法**：
   - `CUR`：当前错误行为，客观描述实际观察。
   - `EXP`：相同条件下应出现的正确行为。
   - `UNCH`：修复后必须继续工作的既有行为。
3. **限制范围**：用 `CON` 写禁止修改的接口、兼容性、数据格式、性能/安全底线；区分用户明确约束和基于证据的推断。
4. **稳定编号**：`BUG-nnn / REPRO-nnn / CUR-nnn / EXP-nnn / UNCH-nnn / CON-nnn`。发布后不重排；变化用 revision。
5. **确认与输出**：用户确认三类行为和范围后，按 `templates/bugfix.md` 生成 `output/bugfix.md`，运行契约校验，再交给 design-master。

## 升级为 Feature 的条件

出现以下任一证据时暂停 Bugfix，让用户确认是否新建 Feature：需要新增用户能力；改变公开契约而非恢复既有契约；必须重做业务流程；无法在不破坏多个 UNCH 项的情况下修复。

## 硬门禁

- 至少一个可执行 `REPRO`、一个 `CUR`、一个 `EXP`、一个 `UNCH`、一个 `CON`。
- CUR/EXP 必须描述同一触发条件，区别只在结果。
- 禁止把“可能是数据库问题”之类假设写成根因事实。
- 不能复现时允许输出调查规格，但状态必须是 `unconfirmed`，不得声称缺陷已定位。