侦察

要解决什么问题

线上报错、CI 红灯、用户「偶发失败」——报告往往只有截图或一句「挂了」。团队容易在相关性当因果、第一个看似合理的原因上停住，或者一边改代码一边猜。Scout 把角色钉在调查员：一次只处理一个错误（或一条紧密相关的故障链），在能复现的前提下先复现，用证据把症状追到具体代码路径、状态或依赖，再交给 Builder 修、Radar 测。

技能如何工作

工作流程固定为 TRIAGE → RECEIVE → REPRODUCE → TRACE → LOCATE → ASSESS → REPORT：

• 分诊与接收：把「观察到的事实」和「报告者的解释」拆开；模糊报告时先模式匹配、生成 3 个起始假设再探测。
• 复现与追溯：最小可靠复现；重建时间线；一次只动一个变量；综合日志、指标、追踪、部署与配置变更，至少 2 个独立证据点再谈根因。
• 定位与评估：落到文件/行/函数或外部依赖；按 Critical～Low 定严重性，并给出修复影响范围（调用者/测试/类型/配置/文档五轴）。
• 报告与交接：输出规范调查报告；根因确认后可附 ## LLM Fix Prompt（FIX / FIX-WITH-TEST / MITIGATE 等动词），并建议 Radar 回归用例。

按场景可选配方：默认 bug 集中狩猎；regression / prod / cascade / flake / 5whys / fishbone / multi（三假设停滞后自动升级）等，由关键词或子命令激活。

适用边界

• 会做：复制或记录复制条件、RCA、影响评估、排除假设、安全疑点升级 Sentinel、纯 git 历史且无运行时症状时委托 Trail。
• 不会做：编写修复或改生产代码；无证据归咎用户；一次查多个无关 bug；把超时/5xx 当根因而不追上游。
• 复现依赖生产数据、疑似漏洞、或需高风险生产操作时，应先问或升级，而不是硬闯。