cm-fixlisted

# cm-fix — 缺陷修复小闭环 执行前读取 `../../runtime/project-context.md`、`../../runtime/orchestration.md` 与 `../../runtime/review.md`。Codex 入口为 `$cm-fix`；Claude Code 跨平台入口为 `/cm-fix`，macOS/Linux 另有历史别名 `/cm:fix`。 **用法**：`$cm-fix {specs路径} {代码项目路径} 缺陷描述（现象/报错/截图均可）` 修 bug 专用的**轻量闭环**——不走 N1–N8 全链（那是 feature 流程），也不许脱离工作流裸改（裸改没防护网没审查，修一个坏三个）。 **多缺陷输入**：先对全部缺陷做第 1-2 步（复现+定位），**按根因聚类**——同根缺陷合并为一次修复（多个失败测试、一次改动、档案互链），修复顺序按严重度排,不按输入顺序。不聚类的代价：三个现象一个根因跑三个闭环,且第一个修复落地后,后两个的复现步骤可能已失效（第 1 步卡死）。 **转交进场**（消费上游落盘物,不改上游流程）：缺陷描述可附上游档案引用——`$cm-refactor` 档案的未修缺陷清单、N6 业务走查报告的偏差项、观测闭环的半份档案（按 slug 在 `fixes/` 检索）。带引用进场的缺陷,第 1 步**采信上游已有证据**（位置/现象/日志原文）,仍须实际复现一次核实,但不从零摸排。 **$cm-ai 全局规则在本流程内同等生效**：灾难级才暂停、多方案自主决策留痕、状态落盘（node 写 `FIX`）、运行日志照记、独立审查按 `runtime/review.md` 执行。 ## 闭环七步（每个缺陷） ### 1. 复现（不能复现的 bug 不许修） - 按描述实际操作/运行一次，拿到**失败证据**（报错原文、错误截图、错误返回值）;**证据要用严格裁判**——宽容裁判会把坏产物蒙混成功（实跑:补丁类缺陷 GNU patch 的 fuzz 容错险些吞掉复现,换 git apply --check 才拿到硬证据） - 复现不了 → 不猜着修，走**观测闭环**（偶现 bug 专用，两段式）： ① 在可疑路径加观测点（日志/埋点——观测点本身按最小改动+审查纪律入库，**观测点不是修复尝试**） ② 缺陷档案先落半份，状态记 `观测中`，写清"等什么证据（哪个日志出现什么内容）" ③ 本次命令正常收口退出，不挂着等——运行日志记 `done`,detail 写「观测中:等{什么证据}」;状态文件 state 复位,不留悬挂的 running ④ 证据到手后再次运行 `$cm-fix` 附上证据，**按 slug 定位 `fixes/` 下的半份档案**,从第 2 步定位续跑,档案续写、状态改 `修复中`,运行日志记 `resume`(detail 注证据摘要) ——**"我改了点东西你再试试"依然被禁止** ### 2. 定位（先找根因，不是找改哪行能让现象消失） - 有业务地图（`docs/codebase-context/`）→ 先查 07 业务线路定位所在链路，08 修改影响映射表查波及面 - 无地图 → 从失败点向上追调用链，找到**根因层**（现象在 UI，根因可能在数据层） - 输出一句话根因结论 + 波及面清单（本次修改会牵连哪些模块）——写进缺陷档案（第 7 步） ### 2.5 根因与修法对抗确认（条件触发