工作流诊断
先诊断，后修复。
首先阅读
在修改代码前，先阅读最高信号量的上下文：
.ai-workflow/GOAL.md（如存在）.ai-workflow/PLAN.md（如存在）.ai-workflow/ACCEPTANCE.md（如存在）.ai-workflow/IMPLEMENTATION_LOG.md（如存在）AGENTS.mdCONTEXT.md（如存在）- 相关文档、ADR 和架构契约
- 具体的失败代码路径、测试、日志或运行时证据
核心行为
- 在提出修复方案之前，先建立稳定的反馈回路。
- 优先使用证据而非猜测。
- 按假设排序，而非遵循第一个看似合理的解释。
- 保持诊断与大规模机会性重构分离。
- 当根因明确时，带着明确证据交接给规划或实施。
工作流
1. 定义失败
写下：
- 失败内容
- 预期行为
- 实际行为
- 失败是确定性的、不稳定的、数据相关的还是环境相关的
- 可以观察到反馈的最小表面
2. 建立反馈回路
首选：
- 一个失败的自动化测试
- 一个可复现的命令
- 一个狭窄的本地场景
- 一个针对性的日志或指标追踪
如果尚无法建立稳定回路，请明确说明并记录当前可获得的最佳代理证据。
3. 排序假设
按可能性从高到低列出最可能的原因。
每个假设应连接：
- 症状
- 怀疑的层或组件
- 什么证据可以确认或反驳它
4. 检查和检测
使用最少必要的检测手段来区分假设：
- 针对性日志
- 断言
- 临时探针
- 测试调整
- 状态快照
不要因为代码难看就立即重写架构。
5. 记录诊断
当处于活跃工作流任务中时，将诊断优先的通过写入 .ai-workflow/IMPLEMENTATION_LOG.md。包括：
- 反馈回路
- 考虑的假设
- 收集的证据
- 已确认或已排除的原因
- 下一个修复的重点
如果没有活跃的 .ai-workflow 任务，请在响应中提供诊断结果，并建议在实施前创建或刷新任务。
6. 干净交接
如果需要修复：
- 当修复需要一个范围明确的实施计划时，使用
workflow-plan-acceptance - 当活跃任务已有批准的计划时，使用
workflow-implement
后端特定规则
如果涉及后端代码，请针对架构边界测试假设：
- 控制器
- 应用层/服务层
- 编排器/领域服务
- 仓库
- 持久化层
- 基础设施适配器/提供者/后台/流处理
明确检查 Bug 实际上是否由以下原因引起：
- 职责混杂
- HTTP 关注点泄漏到服务逻辑中
- 仓库拥有的业务逻辑
- 实体/DTO/领域模型混淆
- 缺少集中式异常或验证处理
- 缺少可追踪性或审计维度
最终响应格式
最后，用中文回复，包含以下顶级部分：
## 工作流结果
- 技能: `workflow-diagnose`
- 状态: `completed`
- 产物: `IMPLEMENTATION_LOG.md` 或诊断结论
## 诊断摘要
- 问题现象: ...
- 反馈回路: ...
- 主要假设: ...
- 已确认原因: ...
- 排除项: ...
## 下一步
- ...