Workflow Diagnose
先診斷，再修復。
閱讀順序
在修改程式碼之前，先讀取最具參考價值的內容：
.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
後端特定規則
如果涉及後端程式碼，請針對架構邊界測試假設：
- 控制器
- 應用程式/服務
- 協調器/領域服務
- 儲存庫
- 持久層
- 基礎設施適配器/提供者/背景處理/串流處理
明確檢查錯誤是否實際上是由以下原因造成：
- 職責混雜
- HTTP 關注點洩漏到服務邏輯中
- 儲存庫擁有業務邏輯
- 實體/DTO/領域模型混淆
- 缺乏集中的例外或驗證處理
- 缺乏可追溯性或審計維度
最終回應格式
最後，請使用中文回應，並包含以下頂層章節：
## 工作流结果
- 技能: `workflow-diagnose`
- 状态: `completed`
- 产物: `IMPLEMENTATION_LOG.md` 或诊断结论
## 诊断摘要
- 问题现象: ...
- 反馈回路: ...
- 主要假设: ...
- 已确认原因: ...
- 排除项: ...
## 下一步
- ...