---
name: testing-orchestrator
description: "当需要从需求文本一键生成测试项、测试用例与预期成果时使用，按 identify→decompose→generate→build→format 全链路编排并透传上下文。"
---

# testing-orchestrator

## 目标
严格执行测试生成调用链，确保每一步上下文显式传递、结构一致、可追踪。

## 标准调用链
1. identify-requirement-type
2. decompose-test-items
3. generate-test-cases
4. build-expected-results
5. format-output

## 编排规则
1. 优先使用 Skill 与 Tool，不使用临时硬编码逻辑替代。
2. 除非用户明确要求，否则不得跳过任何步骤。
3. 每一步必须显式接收上一步输出。
4. 分类失败时输出未知类型并继续执行通用分解。

## 步骤契约

### Step 1: identify-requirement-type
- 输入：
	- user_requirement_text
	- debug（可选）
- 输出：
	- requirement_type
	- reason
	- candidates
	- recommended_test_methods（格式：`Mxx|方法名`）

### Step 2: decompose-test-items
- 输入：
	- user_requirement_text
	- requirement_type（来自 Step 1）
	- recommended_test_methods（来自 Step 1）
- 输出：
	- normal_test_items
	- abnormal_test_items
	- coverage_analysis

### Step 3: generate-test-cases
- 输入：
	- normal_test_items（来自 Step 2）
	- abnormal_test_items（来自 Step 2）
	- requirement_type（来自 Step 1）
	- recommended_test_methods（来自 Step 1）
- 输出：
	- normal_test_cases
	- abnormal_test_cases
	- method_alignment_report

#### Step 3 路由规则（按需调用）
1. 从 `recommended_test_methods` 提取 Method ID（`Mxx`）。
2. 若命中 `M01-M12`，调用 `generate-test-cases-blackbox`。
3. 若命中 `M13-M18`，调用 `generate-test-cases-whitebox`。
4. 同一测试项命中黑盒+白盒时，并行生成后去重合并。
5. 合并后统一输出 `case_id` 与 `method_alignment_report`，并记录未落地方法到 `gaps`。

### Step 4: build-expected-results
- 输入：
	- normal_test_cases（来自 Step 3）
	- abnormal_test_cases（来自 Step 3）
	- requirement_type（来自 Step 1）
	- recommended_test_methods（来自 Step 1）
- 输出：
	- normal_expected_results
	- abnormal_expected_results

### Step 5: format-output
- 输入：
	- normal_test_items, abnormal_test_items（来自 Step 2）
	- normal_test_cases, abnormal_test_cases（来自 Step 3）
	- normal_expected_results, abnormal_expected_results（来自 Step 4）
	- coverage_analysis（来自 Step 2）
	- method_alignment_report（来自 Step 3）
	- debug（可选）
- 输出：
	- markdown_output

## 执行顺序与回退
1. Step 1 必须先执行，若无法确定类型则输出未知类型并继续。
2. Step 2 若覆盖率不足，不中断流程，记录 coverage_analysis.gaps 并继续。
3. Step 3 若方法对齐不足，不中断流程，输出 method_alignment_report。
4. Step 4 若缺少定量口径，使用通用默认口径并标记待确认字段。
5. Step 5 若 Markdown 格式化失败，回退为结构化 JSON，不丢失三段内容。

## 成果完整性检查
- 最终输出必须同时包含：测试项、测试用例、预期成果。
- 每个测试用例必须能追踪到测试项，每个预期成果必须能追踪到测试用例。
- 输出必须按正常测试/异常测试分组。

## 输出模板
最终输出由 format-output 统一生成，必须遵循三段式结构并保持编号追踪。

## 调试模式
当 debug=true 时，输出步骤日志并包含：
- step_name
- input_summary
- output_summary
- success
- fallback_used
- duration_ms