debug-planlisted

# /cc-code:debug-plan — bug 诊断器（第一动作即 plan 模式） > ⭐⭐⭐ **触发后第一动作 = call `EnterPlanMode` 工具。** > 所有问诊 / 侦察 / 三件套 / 交谈都在 plan 模式内做，**没有 plan 外窗口**。 > **定位：技术诊断器，不是需求规划器。** 与 `/cc-code:plan-prd-feature` 的分界：那个处理「需求模糊」，本命令处理「需求明确但实现错了」—— bug 本身就是需求，期望行为要么主人说了、要么 prd.md 已有断言。 > **配对**：本命令落盘 B-n 后，修复执行走 `/cc-code:debug-qa-dev`（增量定位 B-n → Dev→QA → affected 精准回归）。 ## ⛔ 六条铁律（违反任一即本次诊断无效） ### 铁律 1：第一动作 call EnterPlanMode 触发后，在 call `EnterPlanMode` 之前，**不许做任何动作**： - ❌ 不许先 Read `Agent.md` / `status.md` - ❌ 不许先 codegraph 探测 - ❌ 不许先输出三件套 - ✅ 唯一允许的第一动作：call `EnterPlanMode` 工具 ### 铁律 2：期望行为唯一来源 = 主人原话 + 既有 A/U 断言 这是 plan-prd-feature 铁律 2 在 debug 线的移植 —— **诊断时最容易犯的错就是拿实现当期望**。 ``` 期望行为的合法出处： ✅ 主人在对话里的原话 ✅ prd.md §1.5 的既有 A 断言 ✅ ux.md §2.3 的既有 U 判定项 ⛔ 绝不许从「代码现状」反推「所以期望应该是 X」 ⛔ 绝不许从 codegraph 产出反推期望 —— codegraph 只答「代码现在是什么样」 ``` ### 铁律 3：裁决门（bug ↔ 迭代的分界） 满足任一即**拒修**，指路 `/cc-code:plan-prd-feature`，本命令到此为止： ``` ① 修复需要改 api.md / data.md 契约 ② 修复需要改 prd.md / ux.md 需求（新规则 / 新断言 / 新交互态） ③ 期望行为在合法出处里找不到，且主人不愿当场拍板 ``` > 「深层 bug 牵涉多文件」**不是**拒修理由 —— 影响面大小是事实问题，由 `impact` / `affected` 沿 import 图算出，不由规划仪式回答。**动契约才拒修，不动契约再深也修。** ### 铁律 4：三件套只确认不落盘 三件套服务当轮对话裁决，主人 ExitPlanMode 确认即弃。落盘物仅两处：`bugs.md` 的 B-n 条目 + `status.md` 一行指针。 ### 铁律 5：B 编号独立序列 `bugs.md` 的 B-n 独立递增（读已有最大号取下一个），**绝不复用 A/U 序列**（那两个永久稳定，bug 断言生命周期是天级）。条目修完即删，不占 active 篇幅。 ### 铁律 6：越权红线 ``` ⛔ active/prd.md / ux.md / api.md / data.md / project.md —— 本 skill 绝不改写 ⛔ active/gates.md —— QA 唯