/testgen-flow-test-case-export

name: testgen-flow-test-case-export
description: "Phase 6 Test Case Export of testgen-flow"
alwaysApply: false
disable-model-invocation: true
user-invocable: false
baseSchema: docs/schemas/phase.md

<testgen_flow_test_case_export>

<description_and_purpose> Export test cases from `test-scenarios.md` to a Test Management System (TMS) via MCP, mapping priorities, types, and structured steps. If TMS MCP unavailable, offer user alternatives (manual copy, CSV, etc.). </description_and_purpose>

<workflow_context>

• Phase 6 of 7 in `testgen-flow`
• Input: `test-scenarios.md` from Phase 5
• Output: test cases created in TMS
• Prerequisite: Phase 5 complete, user reviewed test cases, TMS MCP configured
• HITL: user must provide target location in TMS (e.g., section, folder, suite)
• Required skills: `qa-knowledge` (`scenario_design` mode) with the resolved TMS EXPORT provider (e.g. `testrail`, the canonical example) for connection, field mappings, and API details
• Recommended skills: `coding` (when updating tracked repository markdown such as `test-scenarios.md` with TMS IDs — read repo standards as authority), `hitl` (destructive-write confirmation)

</workflow_context>

<phase_steps> 1. Activate `coding` (if updating tracked files) and resolve the TMS EXPORT vendor binding 2. Verify TMS connection via MCP 3. Get target location from user 4. Parse test cases from markdown 5. Map to TMS format using skill mappings 5b. Destructive-write gate: dedup pre-scan + confirm-before-write (step 6.4b) 6. Export test cases via TMS MCP (remember to put pre-conditions, if not possible - create zero step as pre-conditions) 7. Update documents with TMS IDs 8. Write `export-report.md` (TMS IDs/URLs, per-case status, timestamp) 9. Update state file </phase_steps>

<identify_skill step="6.1"> **This phase OWNS the export contract** — what gets pushed (the approved case set from `test-scenarios.md`), ID handling (vendor-format case IDs written back per step 6.6), and idempotency (the destructive-write confirmation gate + dedup pre-scan). The skill EMITS the writes against this contract using the resolved vendor binding; it never decides the contract.

1. If updating tracked repository files (for example embedding TMS IDs into `test-scenarios.md` under version control): USE SKILL `coding` first (read repo standards as authority; repo docs win). 2. **Resolve the TMS EXPORT provider** (merge evidence — do NOT hardcode the vendor): read the TMS provider from `plans/testgen-{TICKET-KEY}/testgen-project-config.md` (data sources / provider fields written by Phase 0, prefilled from `gain.json` `sdlc.test_management(_project)`), explicit user input (wins for this run), or a recognizable TMS URL/handle; conflicting evidence → ask about the TMS only. The resolved provider (e.g. `testrail`, the canonical example) is passed to `qa-knowledge` (`scenario_design` mode) for the vendor-specific export contract (the skill loads its own `<vendor>-export` binding internally). 3. If no provider resolves but a TMS is clearly in scope, re-read config; if still absent, the export cannot run on the integration path → fall through to the step 6.2 fallbacks (manual copy / CSV / defer). 4. USE SKILL `qa-knowledge` (`scenario_design` mode) passing the resolved EXPORT provider. All subsequent steps use the connection check, field mappings, API calls, and ID formats it defines for that provider. </identify_skill>

<verify_connection step="6.2"> 1. Test TMS MCP connection using the method defined in the resolved EXPORT binding 2. **On connection failure:** inform user, verify MCP config and credentials. Retry once. On a second failure, present the **documented alternatives** below and let the user choose; do not silently abort:

• **Manual copy:** export the test cases as plain markdown for the user to paste into the TMS UI. Artifact: keep `plans/testgen-{TICKET-KEY}/test-scenarios.md` as-is; record the user's confirmation of manual export in `export-report.md` (see step 6.6).
• **CSV export:** generate `plans/testgen-{TICKET-KEY}/test-scenarios.csv` with one row per test case (columns: `TC_ID,Title,Priority,Type,Source_Requirements,Preconditions,Steps,Expected_Result,Tags`). Record the CSV path + row count in `export-report.md`.
• **Defer:** mark Phase 6 as `BLOCKED — TMS unavailable` in `testgen-state.md` and stop, awaiting user to fix MCP access.

3. **On chosen fallback:** the corresponding artifact path becomes the on-disk evidence of Phase 6 (replacing the TMS-IDs receipt section of `export-report.md`). **Still write `export-report.md` per the step 6.6 template — set `Outcome` to the fallback taken and mark TMS-specific sections `N/A — <fallback path>`; the validation_checklist requires the report on every path, including when you exit here without reaching step 6.6 on the happy path.** </verify_connection>

<get_target_location step="6.3"> 1. Ask user for target location in TMS — specifics defined by the resolved EXPORT binding 2. Parse location identifier from user response (accept flexible formats) </get_target_location>

<parse_and_map step="6.4"> 1. Read `plans/testgen-{TICKET-KEY}/test-scenarios.md` 2. Parse each TC-NNN: title, type, priority, preconditions, steps, expected results, test data, requirements 3. Apply priority mapping from the resolved EXPORT binding 4. Apply type mapping from the resolved EXPORT binding 5. Build preconditions text: TEST DATA table first (if parameterized, with "Execute for EACH row" note), then original preconditions 6. Format steps per the resolved EXPORT binding specification </parse_and_map>

<destructive_write_gate step="6.4b" type="HITL"> This step makes the ownership claimed in step 6.1 operational: it runs BEFORE the irreversible TMS write in step 6.5. Destructive-confirmation authority is owned by the `hitl` / `orchestration` skills — this step is the testgen-specific binding of that gate to the TMS push. 1. **Dedup pre-scan:** query the resolved target suite/section (via the resol