回归执行与分析器

它解决什么问题

在功能合入或交付前，回归 Job 会跑大量用例，但结果往往只是一串通过/失败。真正需要判断的是：失败是否由本次变更引入。常见困境包括：新增 case 本身没过、存量功能被破坏、环境不稳定、历史遗留问题互相混杂。人工查看 Jenkins 页面、下载产物、对比基线，既重复又容易漏判。

它如何工作

这个技能面向 Jenkins 驱动的回归流程，核心职责是执行、监控、分析、报告四段链路。

触发与轮询

它通过 Jenkins MCP 工具调用执行，例如 build_item、get_queue_item、get_build。这里有一个工程细节：build_item 返回的是 Queue Item ID，不是最终构建号，因此需要继续调用 get_queue_item 获取实际的 build_number。随后轮询构建状态，直到出现 SUCCESS、FAILURE 或 UNSTABLE，超时上限为 30 分钟。

产物与失败分析

构建结束后，通过 jenkins_get_artifacts 获取产物列表，再下载关键文件：report.json 和 console.log。report.json 是失败分析的主要输入，包含用例列表、状态与失败详情。技能会统计总数、通过数、失败数、跳过数和失败率，并对每个失败用例做归因：

• 新增 case 失败 → 标记为本次变更引入；
• 存量 case 失败 → 若提供 host_baseline，在基线上复跑同一用例；
• 基线也失败 → 历史遗留；
• 基线通过 → 本次变更引入；
• 未提供基线 → 标记为待确认。

失败分类包括 regression、new_case_failure、flaky、historical。

输出与协作

最终生成两份产物：//reports/regression_report.json 与 //reports/regression_analysis.md。如果 regression_count > 0，说明存量功能被本次变更破坏，上游 qa-integration-pipeline 应将 Phase 5 标记为 failed，并询问用户是否继续。技能不中断询问，交互由上游统一处理。

适用边界与注意点

• 该技能是 Phase 5 子 Skill，需要运行在已有 qa-integration-pipeline 的上下文中，不应脱离上游独立使用。
• 所有外部操作都走 Jenkins MCP 标准工具，不直接执行本地命令；没有 Jenkins MCP 连接时无法工作。
• feature、env、case_branch 为必填参数，分别影响目录命名和回归 Job 参数。
• case_paths 可选。若传入，新增 case 的失败可直接归因；若不传，存量失败缺少基线时只能标为待确认。
• host_baseline 是判定历史遗留问题的关键输入。没有它，失败归因的准确性会明显下降。
• 可选地查询 LLM-Wiki 知识库，用于补充历史失败模式和分类经验，但资料未说明知识库结构。
• 产物统一落在 //reports/ 目录，上游需能读取该路径。