diagnose-verify-fix

name	diagnose-verify-fix
description	用于 Quantia 仓库的"验证优先"诊断与修复工作流——当用户报告 bug、异常、生产日志报错、或要求"检查/审查当前修改是否引入新问题"时使用。强制：先证实问题真实存在并定位根因 → 评估多方案择优 → 修复 → 回归自检 → 本地/接口验证，最后才声明完成。覆盖生产日志（阿里云 115.29.213.22）根因定位、phase/文档一致性核对。纯新功能开发、纯查询/解释、用户已明确"直接改"时可跳过严格证实步骤。

诊断 → 验证 → 根因 → 择优 → 修复 → 回归（Quantia 验证优先工作流）

这是本仓库用户的签名工作流。几乎每次"修 bug / 检查改动 / 看日志"的请求都隐含这套要求， 即使用户没逐条写出来，也要按此执行。

触发场景

• "请帮我检查并验证…是否包含 bug / 引入了新问题"
• "为啥…会失败 / 为啥结果是降级版"（贴图、贴日志）
• "帮我修复服务器运行时的错误"（贴 *.log）
• "当前修改是否合理 / 有没有不符合预期的行为"
• "综合评估这几个方案…选最优" / "是否有更优解决方案"
• 进入下一个 phase 前的"再次审查确认无遗漏"

五步硬流程（不可跳步）

1. 证实问题真实存在（先别动手改）

• 复现：写最小复现（脚本 / 单测 / Invoke-RestMethod 黑盒调接口），或在代码里定位触发路径。
• 区分"用户以为的问题"与"真实问题"：用户常给现象（"结果是降级版""收益为 0"），根因可能在别处。
• 若无法复现 → 明确告知"当前无法复现"，列出已验证的点，再问用户补信息；不要猜测性地乱改。

2. 定位根因（root cause，不是症状）

• 顺数据流回溯：Fetch → MySQL/cache → Analysis job → Handler → 前端（见 AGENTS.md 规则 1 的管道边界）。
• 生产日志诊断（阿里云 115.29.213.22，库 instockdb）：
  • 常看：quantia/log/stock_fetch.log / stock_error.log / refresh_ai_kb.log / kline_cache 相关。
  • 读 Traceback 顶层异常 + 触发函数，再对应到本地源码；注意"数据源降级""OHLC 异常过滤""未找到命令"等高频根因。
  • 日志是 Compute/Fetch 侧产物——分析时仍遵守管道分离，不在 handler 里加网络请求来"修日志"。
• 一句话写清根因（"X 因为 Y，触发于 Z"），让用户能确认。

3. 列方案 + 择优（用户偏好显式对比）

• ≥2 个可行方案时，列优缺点对比（正确性 / 副作用 / 性能 / 维护成本 / 与文档一致性）。
• 主动问一句"是否有更优解"再下结论——用户多次要求"再深入分析是否有更优方案"。
• 选最优且最合理的，不是最省事的。说明为什么不选其它。
• 与 document/*.md（特别是当前 phase 的开发计划）核对，确保方案不偏离需求。

4. 修复（最小、不外溢）

• 只改根因相关代码；不顺手重构、不加无关"改进"（见 AGENTS.md 实施纪律）。
• 改动若涉及后端常驻进程 → 走 restart-and-deploy skill 重启 + 黑盒接口验证（commit ≠ 生效）。

5. 回归自检 + 验证（声明完成前必做）

• 回归扫描：本次改动是否引入新 bug / 破坏既有行为？显式回答，别默认"应该没事"。
• 跑相关单测：python -m pytest tests/test_<相关>.py -q；改了多模块就跑相关多文件。
• 黑盒验证被改接口：Invoke-RestMethod 确认 200 + 预期字段（区间用 2026-03~05，2025 在生产 DB 为空）。
• 自定义策略相关改动：内置 vs custom_<id> 两条路径都验证（见 AGENTS.md Custom-strategy parity）。
• 只有 1-5 全过，才向用户报告"已修复/已验证"，并附验证证据（测试通过数 / 接口返回片段）。

完成后

• 通过自检 → 按 commit-and-push skill 询问是否提交推送（用户高频要求"验证后提交推送"）。

反模式（请避免）

反模式	正确做法
没复现就按用户描述直接改	先证实问题真实存在 + 根因
修了症状没修根因（如 fillna 掩盖 NaN 源头）	顺数据流回溯到根因再修
只给一个方案就动手	多方案对比 + 择优，必要时问"是否有更优解"
改完不做回归扫描就说"完成"	显式回答"是否引入新 bug"+ 跑测试 + 黑盒验证
后端改完只 commit 不重启 → 说生效了	重启 web_service + 黑盒接口确认
自定义策略只测内置一侧	内置 + custom 两条路径都验证