/api-aqa-flow-data-collection

name: api-aqa-flow-data-collection
description: "Phase 1 Data Collection of api-aqa-flow"
alwaysApply: false
disable-model-invocation: true
user-invocable: false
baseSchema: docs/schemas/phase.md

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

Redaction of every captured value runs inside `data-collection` via `sensitive-data` before write; `raw-data.md` is PUBLIC by default. </raw_data_contract>

<phase_steps> 1. Confirm data sources from project config 2. Execute data collection — see `<execute_collection>`: **1.2a** core collection (`data-collection` TMS role + `qa-knowledge` existing-test scan → `<raw_data_contract>`), **1.2b** optional Wiki collection when scoped 3. Validate and update state </phase_steps>

<confirm_inputs step="1.1"> 1. Verify project config loaded with data source information 2. Verify initial data file exists with test case reference 3. Identify TMS, Wiki, and codebase sources to query 4. **Failure path:** if (1) or (2) is missing, stop Phase 1, record `Phase 1 blocked: missing prerequisite [config | initial-data]` in `agents/TEMP/<FEATURE>/api-aqa-state.md`, and ask the user to re-run Phase 0. If (3) finds no usable sources, record the gap and ask the user to confirm proceeding with empty data sources before continuing. </confirm_inputs>

<execute_collection step="1.2" subagent="discoverer" role="AQA data collector">

<verify_primary_raw_data step="1.2a"> 1. Resolve the **TMS provider** per `<workflow_context>` (Jira tickets are a valid TMS source when the project stores test cases there). If no TMS source is resolvable, ask the user once; if still missing, stop Phase 1 and record `Phase 1 blocked: no resolvable test-case source` in `agents/TEMP/<FEATURE>/api-aqa-state.md` — do NOT invent an ID. 2. USE SKILL `data-collection` with role `TMS`, the resolved provider, the test-case input handle, and the **Test Case Data** + **API Endpoints Identified** sections of