api-aqa-flow-project-config-loading

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