/api-aqa-flow-project-config-loading

name: api-aqa-flow-project-config-loading
description: "Phase 0 Project Config Loading of api-aqa-flow (USER INTERACTION CONDITIONALLY REQUIRED)"
alwaysApply: false
disable-model-invocation: true
user-invocable: false
baseSchema: docs/schemas/phase.md

<api_aqa_flow_project_config_loading>

<description_and_purpose> Initialize the AQA session directory, load the existing project config or collect project-specific information from the user, and seed the workflow state file for backend API test automation. Canonical paths, the `{IDENTIFIER}` derivation rule, the config-key schema, and the state-file shape are owned by USE SKILL `qa-structure` — this phase binds to them and does not restate them. </description_and_purpose>

<workflow_context>

• Phase 0 of 8 in `api-aqa-flow`
• Input (REQUIRED): user request with test case reference (TMS case ID, Issue Tracker ticket, or direct description — e.g. TestRail `C1234`, Jira `PROJ-123`)
• Input (OPTIONAL, when provided by user): repository-root `gain.json` `sdlc.*` providers, Swagger/OpenAPI spec URL or path, Wiki/docs page URLs, backend source code locations
• Output (paths owned by `qa-structure`): per-session `plans/api-aqa-{IDENTIFIER}/api-aqa-project-config.md` and `plans/api-aqa-{IDENTIFIER}/initial-data.md`; shared workflow state `agents/TEMP/<FEATURE>/api-aqa-state.md`.
• Prerequisite: starting new AQA flow
• HITL: conditional — user is questioned ONLY if the project config does not already exist
• Required skills: `qa-structure` (paths / `{IDENTIFIER}` / config schema / state shape), `sensitive-data` (redaction at intake)
• Recommended skills: `questioning` (config-missing interview)

</workflow_context>

<phase_steps> 1. Parse user input, resolve providers from `gain.json` + evidence, derive `{IDENTIFIER}`, and create the session directory + state-file stub. 2. Load this session's config if present, or collect the still-missing project info from the user and create it. 3. Create the initial-data file and mark Phase 0 complete. </phase_steps>

<execute_config step="0.1" subagent="discoverer" role="AQA project config loader">

USE SKILL `qa-structure` for the session layout, `{IDENTIFIER}` derivation, and the config-key schema — the skill routes on those topics and loads its own files. This phase performs session initialization DIRECTLY (no dedicated init skill); it delegates only user-questioning to `questioning`. On the config-missing branch it performs a bounded set of loads (layout, config schema, then the interview + config template at step 0.1.5) — load each at its step via the owning skill; never write an artifact from memory.

1. **Parse initial user input.** Extract:

• **Test case reference** (REQUIRED): TMS case ID, Issue Tracker key/URL, or direct test-case description.
• **Additional context** (OPTIONAL): Swagger URL, Wiki pages, API documentation links.
• Supported phrasings: `"Write API tests for TC-1234"`, `"Automate backend tests for PROJ-123"`, `"Create API tests for the user registration endpoint"`, `"Automate TC-1234 with Swagger: https://api.example.com/swagger"`.

2. **Resolve providers (merge evidence; do not force one source).** Read repository-root `gain.json`; use `sdlc.test_management(_project)`, `sdlc.wiki(_project)`, and `sdlc.issue_tracker(_project)` when populated. Explicit user names/handles win for this run; a recognizable provider URL or handle is valid evidence (a Confluence URL implies Confluence). If evidence conflicts or stays ambiguous, ask only about the unresolved provider; a missing `gain.json` never blocks a direct-description run. 3. **Derive `{IDENTIFIER}`** per the `qa-structure` rule (Issue Tracker key → TMS case ID → kebab-case feature). On multiple candidates, first non-empty wins; record the chosen value + rejected candidates in `initial-data.md`. 4. **Create the session directory** `plans/api-aqa-{IDENTIFIER}/` and write the **state-file stub** below to `agents/TEMP/<FEATURE>/api-aqa-state.md`. The full per-phase update schema is owned by `api-aqa-flow.md` `<state_file>`; this stub is only the seed:

   # API AQA State - <Test Name / Feature>

   **Last Updated**: [DateTime]
   **Current Phase**: 0
   **Test Case Source**: [TMS case ID / Issue Tracker ticket / Manual]
   **Feature**: [Feature Name]
   **IDENTIFIER**: [the {IDENTIFIER} value chosen above — must match plans/api-aqa-{IDENTIFIER}/ directory]
   **Providers**: [resolved TMS / Wiki / Issue Tracker + project handles, or N/A per role]

   ## Phase Completion Status

   - [x] Phase 0: Project Config Loading
   - [ ] Phase 1: Data Collection
   - [ ] Phase 2: API Spec Analysis
   - [ ] Phase 3: Gap & Requirements Clarification
   - [ ] Phase 4: Test Case Specification
   - [ ] Phase 5: Test Implementation
   - [ ] Phase 6: Execution & Report Analysis
   - [ ] Phase 7: Test Corrections

5. **Load or create the project config** at `plans/api-aqa-{IDENTIFIER}/api-aqa-project-config.md` (per-session, inside the feature plan folder): if the file exists AND is non-empty → `<config_exists>`; if it is missing OR empty → `<config_missing>`. 6. **Verify** the feature plan folder `plans/api-aqa-{IDENTIFIER}/` exists and the config is non-empty before proceeding.

</execute_config>

<config_exists step="0.1.5a"> 1. Reuse the existing config as-is; skip to step 0.2 — nothing to collect, no user interaction. 2. Still confirm every required key from `qa-structure`'s config-key schema is present; a malformed / incomplete existing config is handled per `<failure_handling>` (the config-incomplete branch). </config_exists>

<config_missing step="0.1.5b"> 1. Pre-fill every key already resolved by step 0.1.2 provider evidence (`gain.json` + user input); then collect ONLY the still-unresolved project info from the user — USE SKILL `questioning` asking the config-missing interview prompt owned by `qa-structure`, trimmed to the missing keys. 2. Validate the answers + prefill cover at minimum: Wiki/document storage, Swagge