用途：诊断无法解释的软件故障，区分“仅诊断”与“诊断并修复”两种请求；先建立期望与实际行为的差异，明确范围、时间、环境/版本。
主要能力：在可行时于隔离的本地夹具上复现，记录输入、前置条件、命令与观察结果；对间歇性失败记录频率、顺序、并发与有界重复策略；沿调用方、状态/配置、持久化与外部边界回溯症状，对比正常与失败案例，区分观察、假设与历史说法；形成少量竞争性假设，为每个假设记录支持/冲突证据与一个低成本区分性检查。
使用方式：优先执行信息量最高的安全检查，更新置信度并淘汰被矛盾的假设；仅在修复请求授权下做窄范围插桩，纯诊断使用只读检查或独立的一次性复现，不改动用户代码。最终说明因果链：前置条件 → 错误决策/状态 → 可观察症状，并引用真实的 file:line/日志/测试证据。仅诊断时给出原因与建议修复/回归目标；要求修复时继续最小完整修复与验证，适合时用 hai-tdd，否则用针对性的集成/运行时检查，并重跑原始案例、检查邻近契约，交付参照 output-template.md，区分症状缓解与根因修复、已执行检查与建议检查。
适用场景：本地可复现或可隔离运行的故障诊断；需要形成可被检验的因果解释而非仅打补丁的场合。
限制：尊重用户环境与权限，复现不授权破坏性生产操作、外部消息、付费调用或流量压测；重复检查无新证据时须更换假设或证据来源，并指出确切阻塞点；不得为消除症状而大范围重构、抑制错误、盲目重试或改变期望行为，缓解措施须标注并限定范围；临时插桩在诊断完成后移除。状态为 trial，方法尚未在代表性真实任务中证明改进。交接：行为变更实现交 hai-tdd；系统难以变更交 hai-architecture；变更评审交 code-review-and-quality；验收证明交 write-technical-acceptance-report；多阶段修复交 hai-goal。