testgen-flow-test-case-export

<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>