一句话

半天以内的小修：先复现并写一个会失败的回归测试，修到变绿，自审后开 PR。全程一个窗口，不换上下文。

适用

• 适合：单个 bug、小缺陷、一个会话内能完成的修补。
• 不适合：跨模块的功能（去 W2-单会话功能 或 W3-多会话功能）、方向不明的大改。

步骤

1. 诊断：难缠或偶发的 bug 用 matt-diagnosing-bugs，先造一条能对它变红的紧密反馈环；一般报错用 addy-debugging-and-error-recovery 走复现、定位、最小化、修根因。产出是根因结论，还没动代码。
2. 回归测试：matt-tdd 在约定的 seam 上写一个会失败的测试锁住这个 bug，也可用 addy-test-driven-development 的 Prove-It 模式先复现。
3. 修复：最小改动让测试变绿。这一步和前两步留在同一窗口，继续即可。
4. 自审：addy-code-review-and-quality 过一遍 diff，按 Critical、Required、Optional、Nit、FYI 分级，Critical 和 Required 修完再走。
5. 交付：matt-pr 写 PR body，Summary 讲清改动、Evidence 给前后证据、Merge Danger 判风险。

token 与旋钮

• 省：不开子代理评审，自审由主线程直接做，诊断靠描述复现。
• 标准：上面五步全走。
• 加强：第四步之后挂 ctk-verify-this，对「bug 已修」抓 baseline 和 treatment 对比证据再开 PR（本机无 CTK 时用脚本自验，可选/借鉴）。

进入与退出

• 进入：缺陷明确、影响面小、不需要设计讨论。
• 完成判据：回归测试和全量测试绿，PR 开好。
• 之后：进 W7-交付与运维循环 盯 CI 和评审；越挖越大就升级到 W3-多会话功能。

常见坑

• 不写回归测试直接改，同一个 bug 还会回来。
• 自审发现 Critical 级问题还照样合并。
• 改动牵出旧架构问题就当场重构；正确做法是记下来转 W3。

关联

• 入口：00-怎么选工作流 · 下游：W7-交付与运维循环 · 升级：W3-多会话功能