用途：针对某一失败测试或一次红色 CI 运行给出开发者可行动的结论——是自身 PR 问题、主干引入，还是不稳定（flaky）；若为主干引入，则指出肇事 SHA、作者、PR 以及是否已有修复。全程只对已有数据做推导，无需重跑 CI。
主要能力与数据来源：基于两个非物化（始终最新）的仓库视图。engineering_analytics_ci_failures 每行对应 CI 日志中一条 pytest FAILED <nodeid> 行，已预生成 fingerprint（测试 id + 数字/十六进制归一化后的错误），按 fingerprint 分组可得首次/最近出现时间、出现次数与分支分布。engineering_analytics_ci_job_history 每行对应一次 job 尝试，含结论与提交归属：head_sha、commit_author_name、commit_message、commit_pr_number，也是绿色（通过）记录的唯一来源。
使用方式：先用手工 fingerprint（references/investigation-queries.md 中的查询 1）确定失败形态，再按三种列判断：单分支为该 PR 自身问题；单个 trunk-merge/pr-<n>/… gate 分支为队列同伴或之后落地的代码；多分支密集爆发且命中 master 为干干断裂，需跑边界查询定位肇事提交行与首个绿色（修复）行；多分支在数天/数周内零散出现为 flaky，用 engineering-analytics-flaky-tests 佐证。仓库层可用 engineering-analytics-broken-tests MCP 工具做整体分类入口，终端可用 hogli ci:insights。
限制与注意事项：日志仅记录失败，无绿色基线；fingerprint 仅支持 pytest（Jest/playwright/cargo 需回退原始失败日志工具）；测试运行前即失败的 job 在任何测试级表面上不可见，只能看 job 结论；runs-on 为 depot-* 的 runner 需查看 job 自身缓存日志；不同数据源新鲜度不同，实时事件先看 ci_failures 并核对仓库 max(created_at)；结论可能因 workflow_run webhook 尚未结算而过期；重试（run_attempt > 1）中第二次通过为 flaky 信号，第 5 次以上仍失败为确定性；revert 会体现为新的首个绿色/首个红色提交，归属跟随 revert；所有日志查询需限定时间窗口（14 天足够），并配合 created_at_raw 字符串下限以避免全表扫描。缺失事实暂未提供。