testgen-flow-project-config-loading

<testgen_flow_project_config_loading>

<description_and_purpose> Find or create the project config file, obtain project-specific data retrieval configuration from user, and initialize the ticket output directory. </description_and_purpose>

<workflow_context>

• Phase 0 of 7 in testgen-flow
• Input: user request with an Issue Tracker ticket key/URL (Jira PROJ-123 is the canonical example)
• Output: initial-data.md, project config file, initialized state
• Prerequisite: user provided an Issue Tracker ticket key or URL </workflow_context>

<phase_steps>

1. Parse initial user input for ticket key
2. Setup output directory
3. Load or create project config
4. Obtain project info from user (if config is new)
5. Create initial-data file
6. Update state file </phase_steps>

<parse_input step="0.1">

1. Extract the Issue Tracker ticket key or URL from the user prompt (REQUIRED) — Jira shapes are the canonical examples; adapt parsing to the resolved tracker.
2. Accept formats:
   • Ticket only: PROJ-123, a full ticket URL, or Analyze requirements for PROJ-123.
   • Ticket + Wiki: the ticket key/URL plus one or more Wiki page URLs, e.g. Analyze PROJ-123, docs: https://<wiki>/pages/123.
   • Ticket + other documentation URLs (e.g. Google Drive): the ticket plus any documentation links the project config lists as data sources.
3. Any non-ticket links pasted here are captured verbatim into initial-data.md and carried into Phase 1 data collection, resolved there per the project config's data sources. A recognizable provider URL is valid provider evidence. </parse_input>

<setup_directory step="0.2">

1. Create plans/testgen-{TICKET-KEY}/ (full per-ticket layout in <output_directory> below).
2. Initialize testgen-state.md from <state_file_template> below. At init the Phase 0 row is [ ] Phase 0: Project Config Loading - In progress (all others Not started); step 0.6 flips it to [x] ... Completed only after the config and initial-data files exist. </setup_directory>

<load_project_config step="0.3">

1. Search for testgen-project-config.md at plans/testgen-{TICKET-KEY}/testgen-project-config.md (per-ticket, inside this ticket's feature plan folder — one copy per run, not a shared project-wide file, so parallel sessions and commits never collide).
2. Branches (exhaustive):
   • File exists AND non-empty: skip to step 0.5.
   • File missing OR exists but empty: proceed to step 0.4 (do NOT create an empty placeholder file — step 0.4 will write the populated file). </load_project_config>

<obtain_project_info step="0.4">

Contiguous 1–5 sequence. The <example_format_of_question> block below is the verbatim question text used by step 2 — it is not a numbered step and the sequence does not restart after it.

1. Pre-fill from gain.json (merge evidence; do not force one source): read repository-root gain.json; use sdlc.issue_tracker(_project), sdlc.wiki(_project), and sdlc.test_management(_project) when populated, plus recognizable provider URLs from the prompt. Explicit user input wins for this run; a missing gain.json never blocks the phase. Name the prefilled providers in the question below so the user confirms rather than re-supplies them.

2. USE SKILL questioning. Ask the user about knowledge base and data retrieval setup using the question text in <example_format_of_question> below (adapt its canonical provider names to the prefilled ones).

3. Process the user's answer — confirm the default scheme OR capture their customization.

4. Validate the answer provides sufficient information. Minimum required fields:

   • Data sources (which of: Issue Tracker, Wiki, attached docs, other URLs — resolved providers recorded by name)
   • Retrieval method per source (MCP-based / direct URL / search-by-keywords)
   • Auth assumptions (MCP already configured / token in env / requires per-call OAuth)

   Validation failure paths:

   • If user said YES to default but the default cannot run in the environment (no MCP, no auth): re-prompt up to 2 times naming exactly which field(s) are absent. After 2 unsuccessful re-prompts, stop Phase 0, record Phase 0 blocked: default unrunnable — missing <field> in testgen-state.md, and ask the user to supply a complete answer before continuing.
   • If user said NO but did not name source / method / auth: re-prompt up to 2 times naming the missing fields explicitly. After 2 unsuccessful re-prompts, stop Phase 0, record Phase 0 blocked: incomplete config answer in testgen-state.md, and ask the user to supply a complete answer before continuing.

5. Apply the <safety_boundaries> redaction-at-intake gate, then save the validated configuration to plans/testgen-{TICKET-KEY}/testgen-project-config.md (path per step 0.3).