diagnose

诊断

找出导致 Bug 的机制。此技能用于诊断；除非用户在诊断后明确要求实现修复，否则不会实现修复。

通过 triangulate-diagnosis 调用时，使用提供的分析视角，并按照 triangulate-diagnosis/REFERENCE.md 中的格式原样返回 诊断报告。

输入

接受以下任意内容：

• Bug 报告、错误消息、异常行为、截图、日志或粘贴的堆栈跟踪。
• 复现步骤或失败的测试。
• 上下文中已有的本地问题、规范、工单、PR、提交、分支或文件路径。
• 来自 triangulate-diagnosis 的分析视角：repro-first、data-flow 或 recent-change / environment。

只有当症状或目标代码库区域过于模糊，无法着手时，才提出一个简洁的问题。否则，明确说明假设后继续。

保密证据边界

在展示、引用、委派或持久保存任何诊断命令、输出或工件之前，应用机密信息脱敏边界。 将机密值和包含机密信息的参数替换为 <REDACTED>，同时保留足以传达诊断信号的最少非机密上下文。使用环境变量引用来构建反馈循环，而不是写入明文凭据。

如果脱敏后缺少区分剩余假设所需的证据，请在此边界处停止，并仅请求经过安全脱敏的工件，或单独授权的检测。绝不要索取、回显或持久保存原始机密。

流程

1. 重述症状和范围

撰写简短的工作摘要：

• 观察到的行为。
• 预期行为。
• 受影响的入口点、模块、工作流或命令。
• 约束和非目标。
• 已有的证据。

保持客观。不要从先入为主的原因开始。

2. 建立反馈循环

优先采用自动化复现：

• 现有的失败测试。
• 新增的定向失败测试。
• 最小脚本、命令、curl 请求、固定数据、回放或手动步骤。

如果无法建立反馈循环，只继续到确定缺少什么工件或访问权限为止。将最终置信度标为低。

3. 检查当前行为

从可观察到的症状出发，沿调用路径追踪到相关边界：

• 输入、持久化状态、配置、环境和功能标志。
• 受影响路径上的调用方和被调用方。
• 错误处理、回退路径、缓存、时序和并发。
• 相关的近期更改、迁移、依赖项更改或部署差异。

探索范围应与症状相称。广泛搜索前，先阅读附近的代码和测试。

4. 提出并证伪假设

维护一份简短的候选机制列表。对于每个重要候选项：

• 准确描述该机制。
• 预测如果假设成立，应出现哪些证据。
• 执行能确认或证伪它的最小检查。
• 根据具体证据记录已排除的其他可能性。

不要把“这段代码看起来可疑”当作证据。

5. 找出根因

当证据明确指出产生症状的机制时，停止调查。指出根源所在的文件、模块、接口、数据边界或配置来源。行号稳定且有帮助时可使用行号，但优先使用持久的模块／函数定位信息。

如果仍有多个可能的原因，请报告这些不同可能性，不要强行给出单一答案。

6. 建议修复路径

描述最小且完整的修复位置和方案：

• 应更改什么。
• 为什么该更改能解决这一机制。
• 应通过什么测试或反馈循环验证修复。
• 需要留意的风险或相邻行为。

除非用户在同一轮中明确要求修复 Bug，否则不要编辑文件。

输出

使用以下格式：

## Diagnosis Report - lens: <single-pass | repro-first | data-flow | recent-change>

### Root cause
<One paragraph: the mechanism that produces the symptom and where it originates.>

### Evidence
- <Concrete observation from a test, command, log, instrumentation, code path, or trace.>

### Feedback loop built
<Failing test, command, script, replay, or manual sequence. State if none could be built.>

### Fix location and approach
<Where the fix goes and the smallest coherent shape of it.>

### Alternatives ruled out
- <Hypothesis and the evidence that falsified it.>

### Confidence: <high | medium | low>
<One line explaining the confidence level.>

如果用户还要求进行实现，先完成诊断，然后根据所请求的工作流继续进行修复，或将结果转交给 to-spec、to-tickets 或 execute-ticket。