QA 集成测试全流程编排器

角色定位

本 Skill 是编排层，不执行业务逻辑。职责：
1. 校验输入参数
2. 管理流水线执行顺序与产物收集
3. 按序调用子 Skill
4. 收集各阶段产物
5. 生成汇总报告

业务逻辑由子 Skill 各自实现。

输入参数

> map-spec-testing agent 调用接口：skill: qa-integration-pipeline args: "type=unit|integration designDoc=<path> sourceFiles=<list> [testFramework=<框架>]"
>
> 本 Skill 仅接收 agent 传入的参数，其余变量（feature / host / host_baseline / driver_id）在 Phase 0 内部自动推导，不作为输入参数。

内部变量（Phase 0 自动推导）

子 Skill 清单

Phase 0: 初始化与服务部署

Phase 0.0: 知识库查询（可选）

在流水线执行前，可查询 LLM-Wiki 知识库获取流水线配置最佳实践和历史问题处理经验：

POST http://10.190.56.84:8080/search
Content-Type: application/json

{
  "collection": "navi-guide-qa-knowledge",
  "query": "<feature> QA流水线 常见问题 最佳实践",
  "limit": 5
}

查询时机：
- Phase 0.1 初始化前：查询同类功能的历史流水线配置、部署参数、环境设置经验
- 各 Phase 失败时：查询该 Phase 历史失败原因和处理方案（如 diff 失败、回归失败等）
- Phase 6 汇总报告前：查询历史风险等级评估和测试策略决策依据

检索结果应用：
- 参考历史配置，优化当前 feature 的流水线参数设置
- 借鉴历史问题处理经验，加速故障定位和恢复

Phase 0.1: 基础初始化

1. 校验 designDoc 存在且可读
2. 判断 type：若 type=unit → 直接返回 {"status": "skipped", "reason": "本 Skill 只处理 integration 测试，unit 测试请使用其他工具"}，不执行后续任何 Phase
3. 推导 feature 名：
   - 从 designDoc 路径推断（如 .claude/workflow/<slug>/design.md 取 <slug>；或取 designDoc 所在目录名）
4. 确定工作根目录 <CASE_DIR>：
   - 优先级：环境变量 QA_CASE_DIR → .claude/qa-pipeline.config.json 中的 case_dir → 默认 /home/xiaoju/map-spec/
   - 每个需求在 <CASE_DIR>/<feature>/ 下隔离存放
5. 读取配置（优先级：传入参数 > 环境变量 > .claude/qa-pipeline.config.json > 默认值）：
   - host：环境变量 QA_HOST → config host
   - host_baseline：环境变量 QA_HOST_BASELINE → config host_baseline
   - driver_id：config driver_id → 默认 580548822047701
   - top30_city_points_dir：config top30_city_points_dir → 默认 /home/xiaoju/map-spec/top30_city_points/
   - search_ng_data_dir：config search_ng_data_dir → 默认 /home/xiaoju/map-spec/search-ng-data/
   - regression_case_dir：config regression_case_dir → 默认 /home/xiaoju/map-spec/navi_guide_tools/case/AI_Case/
   - regression_project_dir：config regression_project_dir → 默认 /home/xiaoju/map-spec/navi_guide_tools/
   - notification.enabled：config notification.enabled → 默认 true
   - notification.dchat.enabled：config notification.dchat.enabled → 默认 true
   - data_mode：由设计文档/代码变更推断 → 默认 single

> data_mode 推断逻辑（优先级从高到低）：
> 1. 若 designDoc 或 test_plan 中明确提到"数据版本切换"、road_data_manager、enable_road_data_manager → dual
> 2. 若 sourceFiles 中包含数据层/道路数据相关文件（如 *road_data*、data_manager、*.proto 数据定义） → dual
> 3. 否则默认 single
>
> 以上变量在后续各 Phase 通过 <变量名> 占位符传递给子 Skill（如 top30_city_points_dir=<top30_city_points_dir>），无需在每个子 Skill 中重复读取配置。
>
> dchat 通知开关：所有 dchat 通知仅在 notification.enabled == true 且 notification.dchat.enabled == true 时执行。执行前读取：
> bash > NOTIFICATION_ENABLED=$(jq -r '.notification.enabled // true' .claude/qa-pipeline.config.json) > DCHAT_ENABLED=$(jq -r '.notification.dchat.enabled // true' .claude/qa-pipeline.config.json) >
6. 服务部署检查：
- 若 host 和 host_baseline 均已配置 → 跳过本步骤，继续步骤 7
- 若 host 或 host_baseline 未配置 → 调用 service-deployer 子 Skill：
skill: service-deployer args: "feature=<feature> data_mode=<data_mode>"
- service-deployer 在本地自动获取当前分支、推导基线分支、部署两个 async 服务
- 执行完成后，解析返回 JSON 中的 target.host 和 baseline.host，更新本地 host / host_baseline 变量
- 若 service-deployer 返回 failed → 标记 Phase 0 为 failed，阻断后续所有 Phase

 **dchat 通知**（Phase 0 失败）：
 ```bash
 if [ "$NOTIFICATION_ENABLED" = "true" ] && [ "$DCHAT_ENABLED" = "true" ]; then
     node .claude/scripts/lib/dchat-notify.js "【QA Pipeline】
     功能：<feature> | ❌ Phase 0 服务部署失败
     原因: <失败原因摘要>"
 fi
 ```

7. 检查/初始化依赖工程（目录不存在时自动创建/拉取）：
   - <top30_city_points_dir>（批量起终点工程）：
   • 检查目录是否存在且为 git 仓库
   • 若不存在 → git clone git@git.xiaojukeji.com:map-qa/top30_city_points.git <top30_city_points_dir>
   • 若已存在但非 git 仓库 → 报错
   • <search_ng_data_dir>（筛选执行框架）：
   • 检查目录是否存在且为 git 仓库
   • 若不存在 → git clone git@git.xiaojukeji.com:map-qa/search-ng-data.git <search_ng_data_dir>
   • 若已存在但非 git 仓库 → 报错
   • <regression_project_dir>（回归工程）：
   • 检查目录是否存在且为 git 仓库
   • 若不存在 → git clone git@git.xiaojukeji.com:map-qa/navi_guide_tools.git <regression_project_dir>
   • 若已存在但非 git 仓库 → 报错
   • <regression_case_dir>（AI_Case 目录）：
   • 检查目录是否存在
   • 若不存在 → mkdir -p <regression_case_dir>
8. 生成部署报告 <CASE_DIR>/<feature>/deploy_report.md（记录部署状态、服务地址、分支信息）
9. 创建目录：<CASE_DIR>/<feature>/{diff,data,test_cases,reports,logs}
10. 自动检测 test_plan 文件：<CASE_DIR>/<feature>/test_plan.md，存在则标记并跳过 Phase 1

dchat 通知（Phase 0 完成）：

if [ "$NOTIFICATION_ENABLED" = "true" ] && [ "$DCHAT_ENABLED" = "true" ]; then
    node .claude/scripts/lib/dchat-notify.js "【QA Pipeline】
    功能：<feature> | ✅ Phase 0 服务部署完成
    目标服务：<host>
    基线服务：<host_baseline>"
fi

Phase 1: 测试方案生成

条件：<CASE_DIR>/<feature>/test_plan.md 不存在时执行

调用子 Skill：

skill: test-plan-writer
args: "feature=<feature> designDoc=<designDoc> sourceFiles=<sourceFiles>"

期望产出：<CASE_DIR>/<feature>/test_plan.md

test_plan.md 必须包含的字段：
- feature：功能名
- test_scenarios：测试场景列表
- experiment_config：实验/灰度配置（供 Phase 2 多次 diff 使用）
json { "type": "ab_test", "groups": [ {"name": "control", "driver_id": "202606101119", "desc": "对照组（白名单A）"}, {"name": "treatment", "driver_id": "580548822047701", "desc": "实验组（白名单B）"} ] }
- type：ab_test / grayscale / none
- groups：需要 diff 的各组配置，每组包含 name、driver_id（白名单 ID，空字符串表示非白名单/默认逻辑，非空表示使用该白名单）、desc
- 对照组可能有自己的独立白名单，也可能不设白名单（空字符串），视实验设计而定
- 若为 none，则只执行一次默认 diff
- data_filter_conditions：数据筛选条件（供 Phase 3 使用）
- test_strategy：测试策略矩阵，明确各阶段是否执行及判断依据
| 阶段 | 是否执行 | 判断依据 |
|------|----------|----------|
| Diff（Phase 2） | 是/否 | 是否有接口/响应变更、字段增减；若有 AB 实验/灰度，需多组 diff |
| 数据筛选（Phase 3） | 跟随 Case 生成 | Case 生成必须执行时自动执行 |
| Case 生成（Phase 4） | 必须执行 | 基于 diff 结果和变更范围补充/调整用例 |
| 回归（Phase 5） | 是/否 | 是否影响现有流程、通用模块变更 |
- 示例：
- 新增功能 + 接口变更：Diff=是, 回归=是 → required_phases: [1,2,3,4,5]
- 纯结构调整/重构：Diff=是, 回归=是 → required_phases: [1,2,3,4,5]
- 仅配置/文案变更：Diff=是, 回归=否 → required_phases: [1,2,3,4]
- required_phases：由 test_strategy 推导出的 Phase 数字列表，供流水线读取
- risk_level：风险等级（low/medium/high），影响回归覆盖策略和重试次数

后处理：
- 检查 test_plan.md 是否存在
- 检查 required_phases 字段是否完整
- 若检查失败 → 标记 Phase 1 为 failed，阻断后续所有 Phase

dchat 通知（Phase 1 失败）：
bash if [ "$NOTIFICATION_ENABLED" = "true" ] && [ "$DCHAT_ENABLED" = "true" ]; then node .claude/scripts/lib/dchat-notify.js "【QA Pipeline】 功能：<feature> | ❌ Phase 1 测试方案生成失败 原因: <失败原因摘要>" fi

dchat 通知（Phase 1 完成）：

if [ "$NOTIFICATION_ENABLED" = "true" ] && [ "$DCHAT_ENABLED" = "true" ]; then
    node .claude/scripts/lib/dchat-notify.js "【QA Pipeline】
    功能：<feature> | ✅ Phase 1 测试方案生成完成
    测试场景：<从test_plan读取场景数> 个
    风险等级：<从test_plan读取risk_level>" "test_plan.md"
fi

Phase 2: Diff 执行与分析

执行条件：
1. 读取 test_plan.md 中的 required_phases
2. 若 2 ∈ required_phases，执行本 Phase
3. 若 2 ∉ required_phases，标记 Phase 2 为 skipped_by_plan，直接进入 Phase 3

调用子 Skill：

skill: diff-executor-and-analyzer
args: "host=<host> host_baseline=<host_baseline> test_plan=<CASE_DIR>/<feature>/test_plan.md feature=<feature> driver_id=<driver_id>"

职责：子 Skill 内部完成：
1. 根据 test_plan.experiment_config 决定 diff 执行次数：
- type=none：执行 1 次 默认 diff
- type=ab_test：执行 2 次 diff（对照组 + 实验组白名单）
- type=grayscale：执行 2 次 diff（白名单 + 非白名单）
- 每次 diff 使用对应 driver_id 调用服务，产出独立的 diff 结果目录
2. 对每组 diff 结果，依据 test_plan 筛选预期差异（原 search-data-diff 逻辑）
3. 初步识别 bad case（unexpected_diff），汇总多组结果

期望产出：
- 单次 diff：type=none
- <CASE_DIR>/<feature>/diff/bad_case.md
- <CASE_DIR>/<feature>/diff/manifest.json
- <CASE_DIR>/<feature>/diff/expected_diff.txt
- 多组 diff：type=ab_test / grayscale，按 group name 分目录
- <CASE_DIR>/<feature>/diff/<group_name>/bad_case.md
- <CASE_DIR>/<feature>/diff/<group_name>/manifest.json
- <CASE_DIR>/<feature>/diff/<group_name>/expected_diff.txt
- 示例：diff/control/bad_case.md、diff/treatment/bad_case.md

后处理：

1. 检查 bad_case.md 中是否有 unexpected_diff
2. 若无 unexpected_diff：
   - 标记 Phase 2 为 success
   - 继续 Phase 3

3. 若发现 unexpected_diff:
   - 输出 bad case 详细报告（含 diff 坐标、请求 ID、差异字段）
   - 多组 diff 特殊检查：若 experiment_config 存在，检查组名=control（或描述中明确为对照组）的分组是否出现 unexpected_diff。若出现 → 直接标记为 bug（对照组无论是否有独立白名单，都应与基线一致，出现差异说明实验分流逻辑有问题），无需询问用户，直接生成 reports/phase2_bug.md

   dchat 通知（Phase 2 对照组异常）：
   bash if [ "$NOTIFICATION_ENABLED" = "true" ] && [ "$DCHAT_ENABLED" = "true" ]; then node .claude/scripts/lib/dchat-notify.js "【QA Pipeline】 功能：<feature> | 🐛 Phase 2 对照组发现 unexpected_diff 状态: FAIL（实验分流逻辑异常）" fi
   - 询问用户（仅实验组/白名单组的 unexpected_diff）：
   ```
   Phase 2 发现 unexpected_diff，共 X 条：
   [简要列出 bad case 列表]

   请确认处理方式：
   A. 预期内差异（test_plan 漏定义了）→ 我将自动更新 test_plan.md 和 expected_diff.txt
   B. 代码 bug → 记录 bug 信息，继续执行后续 Phase 或提前结束
   C. 先跳过，后续人工处理 → 标记本 Phase 为待人工确认，继续后续 Phase
   - **用户选 A（预期内差异）**： 1. 读取 unexpected_diff 详情 2. 自动更新 `test_plan.md`：补充预期差异定义到 `test_scenarios` 3. 自动更新 `expected_diff.txt`：将本次 unexpected_diff 纳入预期 4. 标记 Phase 2 为 `success（人工确认）` 5. 继续 Phase 3 - **用户选 B（代码 bug）**： 1. 生成 `reports/phase2_bug.md`：记录 bug 详情、复现坐标、预期 vs 实际 2. 标记 Phase 2 为 `failed（bug 确认）` 3. **dchat 通知**（Phase 2 bug 确认）：bash
   if [ "$NOTIFICATION_ENABLED" = "true" ] && [ "$DCHAT_ENABLED" = "true" ]; then
   node .claude/scripts/lib/dchat-notify.js "【QA Pipeline】
   功能：<feature> | 🐛 Phase 2 发现代码 Bug
   unexpected_diff: <条数> 条
   状态: FAIL"
   fi
   `` 4. 询问用户："是否继续执行 Phase 3~6？（是 / 否，直接返回 FAIL）" - 选"是" → 继续执行后续 Phase（Phase 3~6） - 选"否" → 跳过后续 Phase（Phase 3~6），直接生成报告，最终返回 FAIL - **用户选 C（先跳过）**： 1. 标记 Phase 2 为skipped_with_manual_check`
   2. 继续 Phase 3

dchat 通知（Phase 2 完成）：

if [ "$NOTIFICATION_ENABLED" = "true" ] && [ "$DCHAT_ENABLED" = "true" ]; then
    node .claude/scripts/lib/dchat-notify.js "【QA Pipeline】
    功能：<feature> | ✅ Phase 2 Diff 完成
    expected_diff: <条数> 条
    unexpected_diff: <条数> 条
    状态: <PASS/WARNING/FAIL>"
fi

Phase 3: 数据筛选

执行条件：
1. 读取 test_plan.md 中的 required_phases
2. 若 3 ∈ required_phases，执行本 Phase
3. 若 3 ∉ required_phases，标记 Phase 3 为 skipped_by_plan，直接进入 Phase 4

> 当前策略下 Case 生成必须执行，Phase 3 通常自动跟随执行。

调用子 Skill：

skill: data-filter-executor
args: "feature=<feature> test_plan=<CASE_DIR>/<feature>/test_plan.md diff_dir=<CASE_DIR>/<feature>/diff/ host=<host> host_baseline=<host_baseline> top30_city_points_dir=<top30_city_points_dir> search_ng_data_dir=<search_ng_data_dir> regression_case_dir=<regression_case_dir>"

职责：子 Skill 内部完成：
1. 基于 test_plan 中的筛选条件，从坐标池/历史数据中筛选有效测试数据
2. 复用历史 AI_Case 资产（可选）
3. 分析筛选结果，评估数据覆盖度
4. 生成筛选配置与筛选结果

期望产出：
- <CASE_DIR>/<feature>/data/filter_analysis.md（数据筛选分析报告，含场景覆盖映射与数据概览）
- 按筛选方案产出的数据文件：
- 方案 A（diff 筛选）：data/expected_diff.txt、data/manifest.json
- 方案 B（script 筛选）：data/filter_config_<feature>.py、data/main.py、data/baseline_results.json、data/target_results.json
- 方案 C（reuse）：data/preset_cases.json

后处理：
- 读取子 Skill 返回结果中的 data_sufficient 字段
- 若 data_sufficient == false，提示补充数据或调整筛选条件
- 若子 Skill 返回 FAIL → 标记 Phase 3 为 failed，记录日志

dchat 通知（Phase 3 失败）：
bash if [ "$NOTIFICATION_ENABLED" = "true" ] && [ "$DCHAT_ENABLED" = "true" ]; then node .claude/scripts/lib/dchat-notify.js "【QA Pipeline】 功能：<feature> | ❌ Phase 3 数据筛选失败 原因: <失败原因摘要>" fi

dchat 通知（Phase 3 完成）：

if [ "$NOTIFICATION_ENABLED" = "true" ] && [ "$DCHAT_ENABLED" = "true" ]; then
    node .claude/scripts/lib/dchat-notify.js "【QA Pipeline】
    功能：<feature> | ✅ Phase 3 数据筛选完成
    有效数据: <有效数据数量> 条
    筛选方案: <A/B/C>"
fi

Phase 4: Case 生成

执行条件：
1. 当前策略下 Case 生成为必须执行阶段，无跳过条件
2. 直接进入本 Phase 并调用子 Skill

调用子 Skill：

skill: case-generator
args: "feature=<feature> test_plan=<CASE_DIR>/<feature>/test_plan.md data_assets=<CASE_DIR>/<feature>/data/filter_analysis.md regression_project_dir=<regression_project_dir> default_case_dir=<regression_project_dir>/case/default_Case/"

> data_assets 为 Phase 3 产物（data/filter_analysis.md），case-generator 内部读取其中的场景覆盖映射与数据概况，并引用同目录下的具体数据文件（expected_diff.txt / baseline_results.json / preset_cases.json）获取坐标和响应样本。

期望产出：<regression_project_dir>/case/AI_Case/<feature>/test_<feature>.py

> 测试代码直接输出到回归工程 <regression_project_dir>/case/AI_Case/<feature>/ 目录，并创建 <feature> 分支提交。qa-integration-pipeline 同时在 <CASE_DIR>/<feature>/test_cases/ 下保存副本用于产物收集。

后处理：
1. 从子 Skill 返回结果中读取 case_branch（如 <feature>），更新本地 case_branch 变量
2. 若返回 self_check_passed == false，标记 Phase 4 为 warning，记录风险
3. 若子 Skill 返回 FAIL → 标记 Phase 4 为 failed，记录日志
4. 继续 Phase 5（如 5 ∈ required_phases）

dchat 通知（Phase 4 失败）：
bash if [ "$NOTIFICATION_ENABLED" = "true" ] && [ "$DCHAT_ENABLED" = "true" ]; then node .claude/scripts/lib/dchat-notify.js "【QA Pipeline】 功能：<feature> | ❌ Phase 4 Case 生成失败 原因: <失败原因摘要>" fi

dchat 通知（Phase 4 完成）：

if [ "$NOTIFICATION_ENABLED" = "true" ] && [ "$DCHAT_ENABLED" = "true" ]; then
    node .claude/scripts/lib/dchat-notify.js "【QA Pipeline】
    功能：<feature> | ✅ Phase 4 Case 生成完成
    用例数: <用例数> 个
    case 分支: <case_branch>"
fi

Phase 5: 回归执行与分析

执行条件：
1. 读取 test_plan.md 中的 required_phases
2. 若 5 ∈ required_phases，自动执行
3. 若 5 ∉ required_phases，标记 Phase 5 为 skipped_by_plan，直接进入 Phase 6

调用子 Skill：

skill: regression-executor-and-analyzer
args: "feature=<feature> case_paths=<regression_case_dir>/<feature>/ job_name=NG_DataCheck_FT env=<host> case_branch=<case_branch> host_baseline=<host_baseline>"

职责：子 Skill 内部完成：
1. 使用 build_item MCP 工具触发回归 Job，参数映射：
json { "tool": "build_item", "arguments": { "fullname": "NG_DataCheck_FT", "build_type": "build", "params": { "env": "<host>", "case_branch": "<case_branch>" } } }
> env 为目标服务 host，case_branch 为 case 所在分支，其他参数使用 Job 默认值。
2. 获取实际构建号：build_item 返回的是 Queue Item ID（不是构建号），需先调用 get_queue_item 获取实际 build_number
json { "tool": "get_queue_item", "arguments": { "item_id": "<build_item返回的Queue ID>" } }
返回示例：{"build_number": 70, "result": null, ...}
3. 使用 get_build(number=<实际构建号>) 轮询等待结果（最多 30 分钟）
4. 解析回归报告，识别失败用例
5. 判断失败是否为本次变更引入

期望产出：
- <CASE_DIR>/<feature>/reports/regression_report.json
- <CASE_DIR>/<feature>/reports/regression_analysis.md

后处理：
- 若子 Skill 返回 FAIL → 自动重试 1 次，仍失败则标记为 failed，继续 Phase 6（不阻断报告）

dchat 通知（Phase 5 失败）：
bash if [ "$NOTIFICATION_ENABLED" = "true" ] && [ "$DCHAT_ENABLED" = "true" ]; then node .claude/scripts/lib/dchat-notify.js "【QA Pipeline】 功能：<feature> | ⚠️ Phase 5 回归执行失败 原因: <失败原因摘要>" fi

dchat 通知（Phase 5 完成）：

if [ "$NOTIFICATION_ENABLED" = "true" ] && [ "$DCHAT_ENABLED" = "true" ]; then
    node .claude/scripts/lib/dchat-notify.js "【QA Pipeline】
    功能：<feature> | ✅ Phase 5 回归完成
    通过: <通过数> 个
    失败: <失败数> 个"
fi

Phase 6: 汇总报告

由本 Skill 自行执行（不调用子 Skill）：

1. 按标准产物路径收集各 Phase 产出
2. 合并为 qa_integration_report.md
3. 输出到 <CASE_DIR>/<feature>/reports/
4. 输出 MAP_SPEC_RESULT（供 map-spec testing agent 解析）

dchat 通知（Phase 6 完成 / 流水线结束）：

if [ "$NOTIFICATION_ENABLED" = "true" ] && [ "$DCHAT_ENABLED" = "true" ]; then
    node .claude/scripts/lib/dchat-notify.js "【QA Pipeline】
    功能：<feature> | ✅ 流水线执行完毕
    Phase 0: <phase0_status>
    Phase 1: <phase1_status>
    Phase 2: <phase2_status>
    Phase 3: <phase3_status>
    Phase 4: <phase4_status>
    Phase 5: <phase5_status>
    总体结论: <conclusion>" "<CASE_DIR>/<feature>/reports/qa_integration_report.md"
fi

报告模板：

# QA 集成测试报告 - {{feature}}

## 1. 执行摘要
| 阶段 | 结果 |
|------|------|
| 服务部署 | {{phase0_status}} |
| 测试方案 | {{phase1_status}} |
| Diff 执行与分析 | {{phase2_status}} |
| 数据筛选 | {{phase3_status}} |
| Case 生成 | {{phase4_status}} |
| 回归执行与分析 | {{phase5_status}} |

**总体结论：{{conclusion}}**

## 2. 产物清单
- 部署报告：{{deploy_report}}
- 测试方案：{{test_plan}}
- Diff 报告：{{diff_manifest}}
- Diff 筛选结果：{{expected_diff}}
- 数据筛选分析报告：{{filter_analysis}}
- 测试用例：{{test_cases}}
- 回归报告：{{regression_report}}
- 回归分析：{{regression_analysis}}

## 3. 风险与建议
{{risks}}

MAP_SPEC_RESULT 格式：

在报告输出末尾追加以下 JSON 块：

{
  "result": "PASS",
  "coverage": 95,
  "testCount": { "total": 1000, "passed": 953, "failed": 47 },
  "summary": "QA集成测试：5 Phase完成，diff通过率95.3%，回归通过",
  "failureDetails": ""
}

字段说明：
- result: PASS / FAIL / NEEDS_HUMAN（有阻塞问题需人工决策时）
- coverage: diff 成功率或场景覆盖率（百分比数字）
- testCount.total: 总请求数/用例数
- testCount.passed: 通过数
- testCount.failed: 失败/异常数
- summary: 一句话结论，包含关键指标
- failureDetails: 失败详情，无则留空字符串

> 注意：MAP_SPEC_RESULT 必须出现在输出末尾，map-spec testing agent 会解析此 JSON。

产物目录结构

> <CASE_DIR> 默认 /home/xiaoju/map-spec/（可通过 .claude/qa-pipeline.config.json 或环境变量 QA_CASE_DIR 覆盖），回归工程默认放在 <CASE_DIR>/navi_guide_tools/（可通过配置 regression_project_dir 覆盖）。

/home/xiaoju/map-spec/
├── navi_guide_tools/               # 回归工程（git clone 固定目录）
│   ├── case/
│   │   ├── AI_Case/
│   │   ├── default_Case/
│   │   └── globalSwitch.py
│   └── ...
├── top30_city_points/              # 批量起终点工程（git clone 固定目录）
├── search-ng-data/                 # 数据筛选执行框架（git clone 固定目录）
└── <feature>/                      # 每个需求的隔离目录
    ├── deploy_report.md            # Phase 0 产出
    ├── test_plan.md                # Phase 1 产出
    ├── diff/                       # Phase 2 产出
    │   ├── bad_case.md
    │   ├── manifest.json
    │   ├── expected_diff.txt
    │   ├── control/
    │   └── treatment/
    ├── data/                       # Phase 3 产物
    │   ├── filter_analysis.md
    │   ├── expected_diff.txt
    │   ├── manifest.json
    │   ├── filter_config_<feature>.py
    │   ├── main.py
    │   ├── baseline_results.json
    │   ├── target_results.json
    │   └── preset_cases.json
    ├── test_cases/                 # Phase 4 产物副本
    │   └── test_<feature>.py
    ├── reports/                    # Phase 5/6 产物
    │   ├── regression_report.json
    │   ├── regression_analysis.md
    │   └── qa_integration_report.md
    └── logs/
        └── pipeline_YYYYMMDD_HHMMSS.log