testgen-flow-data-collection

<testgen_flow_data_collection>

<description_and_purpose> Extract all relevant data from the Issue Tracker ticket and related Wiki / documentation sources to establish baseline for gap analysis and requirements generation. </description_and_purpose>

<workflow_context>

• Phase 1 of 7 in testgen-flow
• Input: initial user request + initial-data.md
• Output: raw-data.md with extracted Issue Tracker and Wiki data
• Prerequisite: Phase 0 complete
• Collection skill: data-collection (single canonical collector). This phase resolves each in-scope provider and passes its role + provider to the skill; the skill loads the role-named binding.
• Provider resolution (merge evidence; providers are NOT hardcoded):
  1. Providers were resolved in Phase 0 (testgen-project-config.md data sources, prefilled from gain.json sdlc.issue_tracker(_project) / sdlc.wiki(_project)).
  2. Reconcile with explicit user names/handles (which win for this run) and recognizable provider URLs in initial-data.md (valid evidence when unambiguous).
  3. Evidence conflicting or ambiguous → ask only about the unresolved provider/input; never silently choose between conflicting systems.
  4. Wiki scope clearly absent → SKIPPED_NO_CONFIG (record the gap + skip that source, do not fabricate a provider). The Issue Tracker source is required.
• Integrations: Issue Tracker + Wiki per the parent Terminology (Jira and Confluence are the canonical examples throughout this phase). </workflow_context>

<phase_steps>

1. Extract Issue Tracker ticket data
2. Get Wiki documentation
3. Create raw data document
4. Update state file </phase_steps>

<extract_ticket step="1.1">

1. Read plans/testgen-{TICKET-KEY}/initial-data.md (contributes the original user prompt and a pointer to the project config) and the original user request.
2. Resolve the Issue Tracker provider per <workflow_context>. If unresolvable with scope active, re-read config; still absent → record the gap and stop Phase 1.
3. Extract ticket key from user input (parse from URL if needed). Ticket-key extraction failure path: if no key can be parsed (no URL, malformed input, ambiguous candidates): stop Phase 1, ask the user once for the exact ticket key (PROJ-NNN form), do not proceed until the user provides it. After 2 unsuccessful re-asks, record Phase 1 blocked: ticket key unresolvable in testgen-state.md and stop.
4. USE SKILL data-collection with role Issue Tracker, the resolved provider, the resolved ticket key, and the ticket section of <create_raw_data>'s minimum-output contract; the skill loads its issue binding and adapts the canonical Jira examples to the target system. Retrieve fields: summary, description, status, issuetype, priority, labels, components, assignee, reporter, comments (up to 10). Redaction runs inside data-collection via sensitive-data before write.

</extract_ticket>

<get_wiki step="1.2">

1. Resolve the Wiki provider per <workflow_context>. If no Wiki is in scope, apply SKIPPED_NO_CONFIG: record Wiki Source: Skipped — no Wiki configured and proceed ticket-only.
2. USE SKILL data-collection with role Wiki, the resolved provider, the Wiki input handle(s), and the Wiki section of <create_raw_data>'s contract. The skill's documentation binding owns URL parsing, direct-URL-vs-search precedence, child-page traversal, truncation, deduplication, permission fallbacks, AND the authenticated reads/searches in one binding — no second skill to reconcile against; its canonical Confluence examples adapt to the target system. Redaction runs inside data-collection via sensitive-data before write.
3. Search-term seed (passed to data-collection when no URLs supplied): project key (from ticket key), labels, component names, key terms from summary/description.
4. Fallback: when the binding reports zero pages after URL + search + its ask-once user fallback, record Wiki Source: not available — proceeded ticket-only in the data collection summary and continue. Do NOT fabricate documentation content. </get_wiki>