用途：针对给定的 Azure DevOps（ADO）流水线运行，分析测试失败原因，并对其进行归类（服务抖动、基础设施/测试框架问题、确定性的产品/测试缺陷），同时与相邻运行对比以区分偶发失败与确定性失败，必要时为真实缺陷提交规范的 ADO Bug。适用组织为 fluidframework、项目为 internal，代码仓库位于 GitHub 的 microsoft/FluidFramework。
主要能力：按成本从低到高分四层取数。第 1 层（首选）在 Tests 标签页用 Playwright 查看分组失败、错误/堆栈与每条测试的历史；第 2 层为无浏览器会话时的回退方案，使用 ADO MCP（ado-pipelines_*）获取失败阶段名称并定向解析报告日志；第 3 层为可选，使用 Test Results/Timeline REST 接口仅取失败测试、逐测试历史与精确的失败日志 id；第 4 层为最后手段，批量下载全部日志。分类是其核心交付物，并强调绿色构建也可能隐藏重试中被掩盖的失败。
使用方式：导航到 ADO 测试结果页并快照读取摘要，按 Outcome=Failed 过滤，记录完整测试名（含 [driver] 前缀）、断言/错误、堆栈与所属文件。必要时用 ADO MCP 列出失败阶段与日志，用 scripts/Parse-AdoTestLog.ps1 解析报告日志；跨运行对比时按相同任务匹配（如 test:realsvc:odsp:report），而非仅比对测试名。第 3 层接口需 -preview.1 版本，并可通过 Timeline 接口定位失败的 job/task GUID 与日志 id。REST 直连需自行提供凭据，优先使用 az login 获取 AAD token，资源 ID 必须为 499b84ac-1321-427f-aa17-267ca6975798，必要时先 az login --tenant 72f988bf-86f1-41af-91ab-2d7cd011db47 --allow-no-subscriptions。凭据只能从 az 或环境变量读取，禁止打印。
适用场景：Fluid Framework 真实服务 E2E 等流水线的测试失败排查、偶发与必现判定、生成日志深链，以及对确定性缺陷提交 Bug（需先与用户确认项目、标签、负责人；internal 项目提交 Bug 必须包含 System.Description，且该实例不展示 Repro Steps 字段）。
限制：报告日志众多（约 660 条、数十 MB），批量下载为昂贵路径，应优先使用更结构化的来源；ADO 标签页懒加载并分页，需先快照再点击；绿色构建声明“无失败”前必须检查重试尝试；ado-wit 更新需使用 updates 数组的 JSON-Patch，而非 fields。