diagnose

诊断

先选择分支，再选择模型。协调器工作和确定性命令在调用权限范围内执行。在当前角色中应用此方法。此方法不会分派工作者。若要分派工作者，请使用 shared/references/model-preview.md 及其中唯一获批的路由快照。嵌套技能和运行器会使用该快照，不再进行其他选择或分派工作者。

根据观察到的故障证据和相关代码找出原因。模式匹配不等于诊断：熟悉的症状只能提供一个假设。证明材料将症状 → 机制 → 原因串联起来。

当这条因果链得到证据支持时，诊断才算完成。如果调查无法确认这条因果链，请报告尚存的不确定性，以及解决问题所需的证据。如果请求授权修复，请应用修复。

建立证据

阅读提供的错误、日志、跟踪记录、数值、失败的测试结果，以及这些证据指向的代码路径。确认这些证据适用于受影响的版本和条件。复用当前任务中已有且足够的证据。

现有证据无需新的本地复现，也可能足以证明原因。请说明其中的联系，例如：“跟踪记录就是证明材料：重试后连接仍保持打开，导致连接池耗尽。”

解决待解问题

仅使用能够解决剩余不确定性的技术：

1. 必要时复现。 选择能确认或否定待解假设的命令、输入和环境。记录确切的命令和输出。
2. 限制尝试次数。 重复探测前，设定尝试次数或时间上限。若调用方已提供上限，则沿用该上限。证据回答了问题或达到上限时就停止。重复失败不会重置上限。
3. 适当时缩减范围。 如果缩小输入或设置有助于区分可能的原因，或得到可用的回归用例，请这样做。
4. 选择区分度最高且成本最低的探测。 如果多种原因都说得通，请选择结果能够区分这些原因的探测。证据已确认原因后，不要再臆造其他可能性。
5. 补充缺失的证据。 仅当现有证据不足时，才添加有针对性的日志、断言或断点。保留故障状态，并考虑对时序或行为的影响。

如果无法运行某个探测，或无法复现故障，请记录结果。继续使用其他可用且能查明原因的证据。如果达到调查上限后仍存在不确定性，请报告已有证据支持的因果联系、尚未解决的假设，以及所缺的最少证据。

修复和验证

对于获授权的代码修复：

1. 说明此更改如何解决已证实的机制。
2. 应用 tdd，将该机制编码为回归测试。观察修复前的预期失败结果，以及修复后的通过结果。无需复现完整的生产事故，聚焦测试也可以确认该机制。复用已有且有效的失败测试证据。
3. 运行受修复影响的检查并记录结果。如果无法运行所需的验证，请报告限制，并说明修复尚未得到确认。
4. 移除诊断期间添加的临时检测代码和临时复现内容。保留回归测试、有用的证据记录，以及保护真实不变量的断言。

评估请求以诊断和证据为结尾，无需实施修复或新增回归测试。

证据规则

1. 重启进程或清除状态前，先保留相关证据。
2. 每次探测只更改一个变量，以便判断其影响。
3. 如果多项代码更改都能消除症状，请先分离各自的影响，再声称是哪项更改修复了原因。
4. 将缺乏支持的因果联系标记为尚未解决。测试通过或症状消失本身都不足以证明原因。

管道模式（mode:pipeline）

不要暂停并提出问题。遵循调用方管道的升级规则以及 shared/references/pr-watch-contracts.md 中的状态词汇。

{
  "status": "fixed-and-pushed | diagnosed-no-fix | flaky-infra | needs-human",
  "reproduced": true,
  "root_cause": "<causal chain: symptom → mechanism → cause>",
  "evidence": "<the artifact of proof>",
  "fix": "<commits or diff, null when no fix>",
  "regression_test": "<test name/path, or null>",
  "residuals": [{ "title": "...", "decision_context": "..." }]
}

仅当本次运行中观察到复现，或提供的复现证据支持复现时，才将 reproduced 设为 true。否则设为 false。在 evidence 中，区分复现无需进行、无法进行，或已尝试但未复现故障的情况。

即使通过日志或跟踪记录证明了原因，reproduced 也可以为 false。如果原因仍然未知，请在 root_cause 中说明，并在 residuals 中记录证据缺口。只有在修复已验证且获授权的推送成功后，才能使用 fixed-and-pushed。

边界

1. tdd 负责测试执行循环。已确认会失败的测试应留在该循环中。
2. fable-mindset 负责证据准则；此技能提供诊断技巧。
3. safe-incremental-coding 保护未经测试的现有行为。当该行为出乎意料且需要调查其原因时，应用此方法。