> Core 中立版（Increment 6a 改写，原 deferHard verbatim）。编号与条目结构严格不变（C-2 不变量）；实例术语按 `core/adapters/TERMINOLOGY.md` 绑定。
# Bugfix 检查清单

> 开发者在修复 Bug 时自检使用。确保修复的是根因而非症状，且不引入新问题。

> **维度命名空间（dimension namespace）**: 本清单中的维度代码（如 TST/BEH/GATE/REG）是**清单局部（checklist-local）**标识符，仅在本文档内唯一；其他清单可能对相同字母串绑定不同概念（如 code-review.md 的 TST=Test Quality、verification.md 的 TST=Test Suite Completeness、port.md 的 TST=Test Porting）。跨清单引用时必须带清单限定（如 code-review.md TST 5.8），不得使用裸代码。

---

## 使用说明

1. Phase 1-4 每阶段结束时检查对应项；
2. Phase 5 完成后检查全部项；
3. 所有项通过后方可提交。

---

## 1. 复现确认（REPRO — Reproduction）

| #   | 检查项                                       | 通过 | 不通过 | 备注 |
| --- | -------------------------------------------- | ---- | ------ | ---- |
| 1.1 | Bug 可以稳定复现（有明确的复现步骤）         | ☐    | ☐      |      |
| 1.2 | 实际行为与 Bug 报告一致                      | ☐    | ☐      |      |
| 1.3 | 如果无法复现，已向用户反馈原因并等待补充信息 | ☐    | ☐      |      |
| 1.4 | 已捕获环境快照（`ps aux`、`lsof -p PID`、日志文件大小、进程树 — pipeline 模式强制，standalone 建议） | ☐    | ☐      |      |
| 1.5 | 复现置信度评级 1–5（≥3 方可进入 pipeline 设计阶段；<3 → abort） | ☐    | ☐      |      |
| 1.6 | 已检索 Gitea wiki `{slug}/repro-notes` / `{slug}/bugfix-report` 中是否存在同类症状的先前调查报告，复用已知根因而非重新推导（via `wiki 读写 API（见 TERMINOLOGY）`） | ☐    | ☐      |      |

---

## 2. 根因分析（ROOT — Root Cause）

| #   | 检查项                                     | 通过 | 不通过 | 备注 |
| --- | ------------------------------------------ | ---- | ------ | ---- |
| 2.1 | 根因已定位到具体代码行（非模块级别）       | ☐    | ☐      |      |
| 2.2 | 根因是底层逻辑缺陷，非表面症状             | ☐    | ☐      |      |
| 2.3 | 如果根因来自数据/环境/配置，已注明具体差异 | ☐    | ☐      |      |

---

## 3. 回归测试（TEST — Regression Test）

| #   | 检查项                                              | 通过 | 不通过 | 备注 |
| --- | --------------------------------------------------- | ---- | ------ | ---- |
| 3.1 | 已编写针对性的回归测试                              | ☐    | ☐      |      |
| 3.2 | 回归测试在修复前 FAIL（确认覆盖了 Bug）             | ☐    | ☐      |      |
| 3.3 | 回归测试在修复后 PASS                               | ☐    | ☐      |      |
| 3.4 | 如果无法编写自动化测试，已标注 `[flaky]` 并说明原因 | ☐    | ☐      |      |

---

## 4. 修复质量（FIX — Fix Quality）

| #   | 检查项                                       | 通过 | 不通过 | 备注 |
| --- | -------------------------------------------- | ---- | ------ | ---- |
| 4.1 | 修复是最小变更——只改了必须改的部分           | ☐    | ☐      |      |
| 4.2 | 未混入重构、风格调整或不相关的"顺手改"       | ☐    | ☐      |      |
| 4.3 | 修复的是根因而非症状                         | ☐    | ☐      |      |
| 4.4 | 同一模块的已有测试全部通过（修复未引入退化） | ☐    | ☐      |      |
| 4.5 | Commit 消息使用常规提交前缀（`fix:` / `refactor:` / `docs:`）并位于 `[{chunk-id}][{iteration}]` 之后 | ☐    | ☐      |      |

---

## 5. 全面回归（REG — Full Regression）

| #   | 检查项                                  | 通过 | 不通过 | 备注 |
| --- | --------------------------------------- | ---- | ------ | ---- |
| 5.1 | `bun run test:parallel` 全部通过（零失败）           | ☐    | ☐      |      |
| 5.2 | `bun typecheck` 无错误                  | ☐    | ☐      |      |
| 5.3 | `bun lint` 无错误                       | ☐    | ☐      |      |
| 5.4 | 如果有集成/端到端测试，已运行并全部通过 | ☐    | ☐      |      |
| 5.5 | 移交评审前已按 `core/checklists/code-review.md` 的 A11Y（§8）与 PERF（§4）节自检本次变更，并对全部改动文件跑 `bunx prettier --check`（pre-commit 钩子只扫提交时的 staged 文件，CR-COMMIT 把提交推迟到评审收敛后，移交前的工作区漂移没有任何钩子拦截——出处：sticky-diff-error 复盘 action item 2） | ☐    | ☐      |      |

---

## 6. 闭环（CLOSURE — Fix Linked to Commit）

> 防止"幽灵 artifact"：bugfix 报告已写出但代码修复从未提交/合并，导致 bug
> 复发并重复调查。参见 `core/skills/retrospective/SKILL.md` 了解该规则的
> 复盘出处。

| #   | 检查项                                       | 通过 | 不通过 | 备注 |
| --- | -------------------------------------------- | ---- | ------ | ---- |
| 6.1 | standalone bugfix 的 `{slug}/bugfix-report` 必须在同一周期内有**已合并提交**背书；若仅调查未应用修复，必须显式标注 "investigation only — no fix applied" | ☐    | ☐      |      |
| 6.2 | 若本次修复取代了先前的同类 `{slug}/bugfix-report`，已在该先前报告顶部标注 SUPERSEDED 并指向新 PR | ☐    | ☐      |      |