用途：调查 Kibana 中 Scout 或 FTR 测试的不稳定失败，目标是给出准确诊断与稳健的长期修复，而非只治标。有效结论包括：真实产品缺陷并升级给负责团队、环境问题且可能自行恢复、数据不足无法定论。
必要输入：必须提供带 failed-test 标签的 GitHub issue 链接；未提供时应先索取。issue 中已有的根因分析或修复提案可参考，但需自行研究并独立得出结论。
主要能力：判断失败发生在 kibana-on-merge 本地流水线、Cloud 流水线还是两者；检查是否伴随大量无关测试失败；分析测试服务器配置（Scout 默认或自定义、FTR 自定义参数）；对 Scout 映射 step_key（如 scout_test_lane_4）到配置列表，识别同一 Playwright lane 共享服务器导致的污染；检查并行配置下的资源压力。
产物检查：优先查看失败截图、DOM/HTML 快照、服务器日志（仅 INFO 及以上）以及 Scout/Playwright 的完整会话 trace。可用 bk artifacts list <build> -p <pipeline> --job-uuid <jobId> --json 列出产物，用 cd <dest-dir> && bk artifacts download <artifact-id> --build <build> -p <pipeline> -y 下载。日志位置：FTR 的 Kibana 日志在 target/test_failures/*.log，Scout stateful 在 .scout/server.log，Scout serverless 的 Elasticsearch 日志无。
范围分析：评估失败频率与时间分布、最近失败时间、测试是否仍存在于失败分支、同套件其他测试是否同错、是否特定版本分支、首次失败与最后通过时间、issue 是否被关闭后重开、是否存在多次修复尝试链。
最佳实践核查：选择合适测试类型、用 API 做 setup/teardown、等待 UI 更新与复杂组件渲染、避免手动重试循环、预期共享测试环境、不向下一套件泄漏状态。修复建议须遵守 .github/workflows/shared/flaky-test-fix-guardrails.md。
限制与陷阱：flaky-test-runner 全绿不能证明修复有效；等待超时抛错位置不代表责任方；需匹配错误签名再判断旧修复是否失效；Cloud 镜像滞后 main，需确认构建包含修复；产物不可用时应如实说明而非编造假设。报告应避免虚假确定性。