用途：在 spec-superflow 执行过程中遇到任何缺陷、测试失败或异常行为时，先做根因调查再提出修复。核心原则是“先找根因，再动手修”，症状式修复视为失败。
主要能力：提供四阶段流程。阶段一为根因调查：仔细阅读错误信息与堆栈、稳定复现、检查近期变更（git diff、提交、依赖、配置、环境差异）、在多组件系统中于各边界加诊断日志、沿数据流反向追踪到源头。阶段二为模式分析：在同一代码库中找可工作的相似实现，完整阅读参考实现，列出工作与损坏版本之间的所有差异，理解依赖与假设。阶段三为假设与验证：一次只提一个假设，用最小改动单变量验证，失败则提出新假设而非叠加修复。阶段四为实现：先写失败测试用例，再做单一修复，最后验证无回归。
使用方式：直接或计划内变更可在执行中调查，无需阶段转换或独立调试台账，保留失败证据于现有进度条目；同一未解决问题失败三次即触发决策。遗留协议用于已有调试状态或需要台账的调查。记录尝试使用 SSF debug attempt record <change-dir> --id <unique-attempt-id> --summary "<what was tried and why it failed>" --evidence <change-local-failure-log>，查看用 SSF debug attempt show <change-dir> --json。三次以上有证据的失败后，需与用户讨论架构决策，用户明确选择后才可执行 SSF debug escalate <change-dir> --decision <continue|abandon> --reason "<user-confirmed decision>" --confirm。注意：执行 CLI 前需将行首 SSF 替换为 node "<plugin-root>/scripts/spec-superflow.mjs"，不得直接运行 SSF 或调用 PATH 中的 ssf。
适用场景：测试失败、缺陷、异常行为、性能问题、构建失败、集成问题，尤其在时间压力下或已多次尝试修复时。
限制：未完成阶段一不得提出修复；不得用原始 SSF state set 写 dp_5_* 字段；Wave Review 修复失败不计入调试尝试；解析失败应报告原始输出并请求澄清，缺失文件应立即升级；若确属环境、时序或外部因素，需记录调查内容并采取重试、超时、错误提示与监控等处理。