Diff 执行与分析器

要解决什么问题

在 QA 集成流水线（Phase 2）里，功能变更往往需要在目标环境与基线环境上跑同一批请求，再对照 test_plan.md 里的「预期差异」判断 diff 是符合设计还是回归。手工触发 Jenkins diff Job、拉产物、逐条比对字段与变化方向，既慢又容易漏判。

本 Skill 作为 Phase 2 子 Skill，负责把「触发 diff → 读结果 → 分类 → 出报告」串成一条可自动跑完的路径，并把 unexpected_diff_count 等摘要交回上游 qa-integration-pipeline，由流水线决定是继续 Phase 3 还是打断询问用户。

如何工作

外部交互一律走 Jenkins MCP（如 build_item、get_queue_item、get_build、jenkins_get_artifacts、jenkins_download_artifact），不直接在本地 shell 里跑 diff。

典型流程可以概括为：

• 前置校验：feature、host、host_baseline、test_plan 等必填项，以及 test_plan.md 是否可读
• 触发构建：默认 Job 名 ng_diff_new（可覆盖）；build_item 返回的是队列 ID，需用 get_queue_item 拿到真实 build_number，再轮询至 SUCCESS / FAILURE / UNSTABLE
• 多组 diff：若 test_plan 里配置了 experiment_config，按 none / ab_test / grayscale 分别跑 1 次或 2 次 diff，各组 driver_id 来自 groups[]，产物按组名落盘并在根目录汇总
• 读产物：下载 summary.txt、diff_details.jsonl、按接口字段拆分的详情、route_link_mapping.json 等，以 diff_details.jsonl 作为逐条分析输入
• 分类：从 testplan 4.2 预期差异解析场景、字段、基线/目标值与 direction；单条 diff 需字段名与变化方向同时匹配才记为 expecteddiff，否则进入 unexpected_diff
• 输出：各组或汇总路径下的 bad_case.md、expected_diff.txt、manifest.json，并返回 JSON 摘要（含 diff_type、group_results 等）

可选地在 Step 5 前查 LLM-Wiki，参考历史预期差异定义与 bad case 模式，减少边界误判。

边界与注意点

• 本 Skill 自动执行，流程中不向用户提问；人机交互由上游 qa-integration-pipeline 承担。
• Jenkins 构建失败或 UNSTABLE 时，应拉日志并返回 FAIL，不会假装分析成功。
• 多组实验时，根目录路径指向汇总产物；各组明细在 diff/{group_name}/ 下，下游需区分汇总与分组 manifest。
• driver_id 在单次 diff 时有默认值；多组场景以 test_plan.experiment_config.groups[].driver_id 为准，不再依赖全局默认参数。