api-aqa-flow-data-collection

<api_aqa_flow_data_collection>

<description_and_purpose> Gather test case details from the configured TMS, search the configured Wiki, and discover existing API test patterns in the codebase to establish baseline for automation. </description_and_purpose>

<workflow_context>

• Phase 1 of 8 in api-aqa-flow
• Input: project config + initial data from Phase 0
• Output: plans/api-aqa-{IDENTIFIER}/raw-data.md with test cases, documentation, and existing test patterns
• Prerequisite: Phase 0 complete, api-aqa-project-config.md and initial-data.md exist
• Collection skill: data-collection (single canonical collector for TMS + Wiki sources) — this phase resolves each in-scope provider and passes its role + provider to the skill; the skill loads the role-named binding. Existing-test-pattern scan: qa-knowledge (code_analysis mode, via reverse-engineering). This phase OWNS the raw-data aggregation contract (<raw_data_contract>) — the skills EMIT into the sections this phase asserts.
• Provider resolution (merge evidence; providers are NOT hardcoded). Providers were resolved in Phase 0 and recorded in api-aqa-project-config.md (tms_provider, wiki_provider + base URLs, prefilled from gain.json sdlc.*). Reconcile with explicit user names/handles (which win for this run), recognizable provider URLs (valid evidence when unambiguous), and available integrations. If evidence conflicts or remains ambiguous, ask only about the unresolved provider/input; never silently choose between conflicting systems.
• Optional Wiki collection when in scope — signals in <config_binding>; procedure in <execute_collection> step 1.2b.
• Required skills: data-collection (TMS + Wiki collector), qa-knowledge (code_analysis mode — existing-test + backend-source scan), reverse-engineering, qa-structure ({IDENTIFIER} + raw-data path) </workflow_context>

<config_binding> Wiki scope comes from api-aqa-project-config.md (Phase 0, prefilled from gain.json) plus run evidence per <workflow_context>. This phase OWNS the resolution + collection inline (step 1.2b) — there is no separate sub-flow.

• In-scope signals ("is a Wiki in scope?"): wiki_provider holds a real provider (not none/N/A), wiki_base_url / Location is set, the user supplied Wiki pages/URLs, or gain.json sdlc.wiki names one — treat absent values as absent. The collection skill is ALWAYS data-collection with role Wiki + the resolved provider (Confluence is the canonical example; any Wiki backend maps the same way).
• Raw-data heading (fixed): ## Documentation / Wiki under plans/api-aqa-{IDENTIFIER}/raw-data.md. Do not invent a different heading unless api-aqa-project-config.md explicitly instructs a rename (then write under the configured heading and note the mapping once). </config_binding>

<raw_data_contract> This phase owns the raw-data aggregation artifact plans/api-aqa-{IDENTIFIER}/raw-data.md and its sections — data-collection and qa-knowledge emit into these, they do not define them. Required sections (empty → N/A — <reason>, never blank):

• Test Case Data — from data-collection (role TMS, resolved provider); ≥1 test-case source required.
• Documentation / Wiki — from data-collection (role Wiki, resolved provider) via step 1.2b when scoped; else the SKIPPED_NO_CONFIG outcome row (per <wiki_outcomes>).
• Existing Test Patterns — from qa-knowledge (code_analysis mode — test-automation architecture analysis, via reverse-engineering); framework, HTTP client, structure/assertion/auth conventions, reusable utilities. Record env-file path + variable names only, never literal values.
• Backend Source Code Analysis — backend path from config or discoverable refsrc/ docs; framework, route patterns, key dirs (or N/A when no path).
• API Endpoints Identified — every row has Method + Source populated; partial rows tagged as gaps.
• Data Collection Summary — counts + gap notes; a delegated-skill stop is recorded verbatim as Gap: <skill> stopped — <message>, never fabricated over.