debug-mode

调试模式

只修复已证实的原因；看似可行、只成功一次的修复不能证明任何问题。 如果已经处于调试模式运行中 → 继续循环。

尊重用户使用的动词：diagnose 在 修复 之前结束，且不应用任何修复； 报告前移除所有临时日志。 debug 或未指定动词的错误报告，则一直运行到 修复。

工作流

1. 理解。 当症状、受影响的范围、预期行为、实际行为和复现路径都已明确时完成。
2. 红灯循环。 构建一条命令，驱动错误代码路径并断言其确切症状：失败的测试、curl 脚本、在测试样例上运行的 CLI、无头浏览器脚本或回放的跟踪记录。务必精简：确定性强、速度快、可无人值守运行，并断言症状，而不只是“没有崩溃”。对于间歇性错误，反复触发并增加压力，提高复现率，直到问题可调试。对于运行缓慢的代码，循环应作为基准测量（计时工具、性能分析器、查询计划、生产跟踪记录），并在超过指定阈值时显示红灯。如果无法实际运行命令（受身份验证限制、仅限特定用户或仅在生产环境中出现），请说明原因，并依靠步骤 5-6 中的检测手段。命令已在此错误上显示红灯，或已说明无法复现时，即完成。
3. 精简。 有循环时，每次只缩减一项复现要素（输入、调用方、配置、数据、步骤），每次缩减后都重新运行循环。只要移除任意一项都会让循环显示绿灯，即表示所有剩余部分都不可或缺，此时完成。没有循环时，直接进入步骤 4。
4. 提出假设。 当 2-3 个按可能性排序的假设都明确指出了哪些观察结果会证实或否定它们时，即完成。
5. 检测。 对于运行缓慢的代码，对精简后的复现进行性能分析，或在已知良好状态与已知错误状态之间进行二分查找（使用循环运行 git bisect run）。 其他情况则添加临时日志。当观察结果能区分各项假设，且不会泄露机密或改变行为时，即完成；如果改变了行为，则从侵入性更低的位置进行观察。
6. 复现。 当错误已触发且证据已收集时，即完成；如果存在循环，则通过循环完成。如果流程受身份验证限制或仅限特定用户，请让用户复现并等待。
7. 分析。 当证据证实一项假设，或明确否定所有现有假设时，即完成。如果证据否定了所有假设，请根据证据提出新的假设，并返回步骤 5。
8. 修复。 当某个切入点能触发真实错误模式时，先将精简后的复现转为回归测试。只有在应用了有证据支持的最小修复、循环（如果存在）已在原始场景中显示绿灯，且所有临时日志均已移除后，才算完成。

日志

• 通过应用自身的日志记录器或本地文件写入结构化事件： hypothesis_id、event、可将某个用户操作关联起来的请求或会话 ID、观察到的值以及时间戳。
• 为每条临时日志添加唯一前缀（例如 [DEBUG-a4f2]），以便只需运行一次 grep 即可移除。

报告格式

最后按以下格式结束：

## Symptoms
## Hypotheses Tested
## Evidence Collected
## Confirmed Root Cause
## Fix Applied
## Instrumentation Removed
## Residual Risk

如果没有应用修复，请在 Fix Applied 下说明，并指出缺少哪些证据。