Files
octopus-workflow/core/checklists/bugfix.md
T

86 lines
5.6 KiB
Markdown
Raw Normal View History

> 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 | 复现置信度评级 15(≥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 | ☐ | ☐ | |