Create a simple summary identifying what is within scope and out of scope for this user story.

## System Scope Summary

### Within Scope
- [Systems, components, processes that ARE part of this change]
- [Data elements, mappings, values that ARE affected]

### Out of Scope  
- [Systems, components, processes that are NOT part of this change]
- [Functionality that is NOT part of this user story]

### Testing Focus
- **Focus On**: [Main testing priorities]
- **Out of Scope**: [What is NOT part of this testing effort]

Keep summary short and actionable.

User Story:
{userInput}

System Documentation:
Webform Policy Application: {system_doc_webform_policy_application}
Policy Manager: {system_doc_policy_manager}
Application Data Service: {system_doc_application_data_service}
Output Service: {system_doc_output_service}
End-to-End: {system_doc_end_to_end}

Analyze the user story and create exactly 10 focused questions within established system boundaries.

First, think step by step about what aspects need investigation. Then create your focused questions.

Focus on:
- What information do we need about the core topic?
- What is the current state vs. the change?
- What existing functionality must continue working?

Number each question 1-10 for easy reference. Stay within the established system boundaries.

User Story:
{userInput}

System Boundaries:
{system_context_extraction}

Analyze this documentation chunk to answer questions from the User Story Analysis within system boundaries.

First, carefully review the questions and identify which ones this chunk can answer. Then create your analysis table.

Create a table with the following columns:

| ID | Question | Relevant section | Answer |
|----|----------|------------------|--------|

Rules:
- No markdown syntax in table cells (use plain text)
- Only include questions that CAN be answered from this chunk
- Focus on information within established system boundaries
- The table has to be valid markdown syntax.

System Boundaries:
{system_context_extraction}

User Story Analysis:
{user_story_analysis}

System Doc - Webform Policy Application:
{system_doc_webform_policy_application}

Analyze this documentation chunk to answer questions from the User Story Analysis within system boundaries.

First, carefully review the questions and identify which ones this chunk can answer. Then create your analysis table.

Create a table with the following columns:

| ID | Question | Relevant section | Answer |
|----|----------|------------------|--------|

Rules:
- No markdown syntax in table cells (use plain text)
- Only include questions that CAN be answered from this chunk
- Focus on information within established system boundaries
- The table has to be valid markdown syntax.

System Boundaries:
{system_context_extraction}

User Story Analysis:
{user_story_analysis}

System Doc - Policy Manager:
{system_doc_policy_manager}

Analyze this documentation chunk to answer questions from the User Story Analysis within system boundaries.

First, carefully review the questions and identify which ones this chunk can answer. Then create your analysis table.

Create a table with the following columns:

| ID | Question | Relevant section | Answer |
|----|----------|------------------|--------|

Rules:
- No markdown syntax in table cells (use plain text)
- Only include questions that CAN be answered from this chunk
- Focus on information within established system boundaries
- The table has to be valid markdown syntax.

System Boundaries:
{system_context_extraction}

User Story Analysis:
{user_story_analysis}

System Doc - Application Data Service:
{system_doc_application_data_service}

Analyze this documentation chunk to answer questions from the User Story Analysis within system boundaries.

First, carefully review the questions and identify which ones this chunk can answer. Then create your analysis table.

Create a table with the following columns:

| ID | Question | Relevant section | Answer |
|----|----------|------------------|--------|

Rules:
- No markdown syntax in table cells (use plain text)
- Only include questions that CAN be answered from this chunk
- Focus on information within established system boundaries
- The table has to be valid markdown syntax.

System Boundaries:
{system_context_extraction}

User Story Analysis:
{user_story_analysis}

System Doc - Output Service:
{system_doc_output_service}

Analyze this documentation chunk to answer questions from the User Story Analysis within system boundaries.

First, carefully review the questions and identify which ones this chunk can answer. Then create your analysis table.

Create a table with the following columns:

| ID | Question | Relevant section | Answer |
|----|----------|------------------|--------|

Rules:
- No markdown syntax in table cells (use plain text)
- Only include questions that CAN be answered from this chunk
- Focus on information within established system boundaries
- The table has to be valid markdown syntax.

System Boundaries:
{system_context_extraction}

User Story Analysis:
{user_story_analysis}

System Doc - End-to-End:
{system_doc_end_to_end}

Extract test requirements specifically relevant to the user story change.

First, think step by step about what data elements, coverage areas, and requirements are directly impacted by this change. Then organize your findings.

## Requirements Analysis

### Data Elements (Change-Relevant)
| Data Element | Valid Values | Invalid Values | Change Impact |
|--------------|--------------|----------------|---------------|

### Coverage Areas
| Coverage Area | Why Relevant to Change | Priority |
|---------------|------------------------|----------|

### Requirements
| Requirement | How Change Affects It | Test Approach |
|-------------|----------------------|---------------|

Rules:
- Focus only on documented information relevant to the change.
- Mark unavailable info as *Not documented*

User Story:
{userInput}

System Boundaries:
{system_context_extraction}

Analysis Results:
Webform Policy Application: {analysis_webform_policy_application}
Policy Manager: {analysis_policy_manager}
Application Data Service: {analysis_application_data_service}
Output Service: {analysis_output_service}
End-to-End: {analysis_end_to_end}

Identify missing data needed to create good test cases.

Create a simple list of follow-up questions:

## Missing Data Questions

1. [Specific missing value or data needed]
2. [Another missing piece of information]
3. [Additional data required for testing]

Focus on practical missing information like specific values, error codes, validation rules, or boundary values.

User Story:
{userInput}

System Boundaries:
{system_context_extraction}

Requirements Analysis:
{test_requirements_analysis}

Search through all documentation chunks to answer the missing data questions.

First, systematically review each question against all documentation chunks. Then compile your findings.

For each question, search all chunks and provide:

## Follow-Up Answers

| Question | Relevant Section | Answer |
|----------|------------------|--------|

Rules:
- No markdown syntax in table cells (use plain text)
- If found, extract relevant section and note source
- If not found, mark as "Not documented"
- Provide practical answers for test case creation

System Boundaries:
{system_context_extraction}

Missing Data Follow-Up Questions:
{missing_data_followup}

System Doc - Webform Policy Application:
{system_doc_webform_policy_application}

System Doc - Policy Manager:
{system_doc_policy_manager}

System Doc - Application Data Service:
{system_doc_application_data_service}

System Doc - Output Service:
{system_doc_output_service}

System Doc - End-to-End:
{system_doc_end_to_end}

Create test plan with four tables in two sections.

# Feature Test Cases (New/Changed Functionality)

## Positive
| Test Case ID | Test Case Title | Maps to Acceptance Criteria | Values to be used |
|--------------|-----------------|-----------------------------|-------------------|

## Negative  
| Test Case ID | Test Case Title | Maps to Acceptance Criteria | Values to be used |
|--------------|-----------------|-----------------------------|-------------------|

# Regression Test Cases (Existing Functionality Must Continue Working)

## Positive
| Test Case ID | Test Case Title | Related System Component | Values to be used |
|--------------|-----------------|--------------------------|-------------------|

## Negative
| Test Case ID | Test Case Title | Related System Component | Values to be used |
|--------------|-----------------|--------------------------|-------------------|

Test Plan Requirements:
- Only include test cases that are directly relevant to the user story change.
- Only include test cases that are backed by specific documented facts.
- The test title should be a short description of the business logic being tested.
- The 'Values to be used' column should contain the specific values that will populate the Examples table.
- Design the test plan for Scenario Outline + Examples pattern where it is applicable instead of repetitive test cases.
- Don't include Idempotency tests, performance tests, formatting tests, etc. if there is no documentation to back them up.
- Each test case must reference the source documentation and provide concrete data values, not placeholders or generic descriptions.

User Story: {userInput}
System Boundaries: {system_context_extraction}
Requirements Analysis: {test_requirements_analysis}
Follow-Up Answers: {followup_answers}

Review the test plan and identify issues without fixing them - analysis only.

First, systematically examine each test case for redundancy, classification, data quality, and coverage gaps. Then document your findings.

# Test Plan Review

## Redundant Test Cases
| Test Case ID | Test Case Title | Redundant to | Action |
|--------------|-----------------|--------------|--------|

## Misclassified Test Cases
| Test Case ID | Test Case Title | Current Table | Action |
|--------------|-----------------|---------------|--------|

## Data Quality, Boundary or Scope Issues or Irrelevant Test Cases
| Test Case ID | Test Case Title | Data Issue | Action |
|--------------|-----------------|------------|--------|

## Coverage Gaps
| Missing Coverage Area | Acceptance Criteria Gap | Suggested Test Case |
|-----------------------|-------------------------|---------------------|

Test Plan Requirements:
- Only include test cases that are directly relevant to the user story change.
- Only include test cases that are backed by specific documented facts.
- The test title should be a short description of the business logic being tested.
- The 'Values to be used' column should contain the specific values that will populate the Examples table.
- Design the test plan for Scenario Outline + Examples pattern where it is applicable instead of repetitive test cases.
- Don't include Idempotency tests, performance tests, formatting tests, etc. if there is no documentation to back them up.
- Each test case must reference the source documentation and provide concrete data values, not placeholders or generic descriptions.

User Story: {userInput}
System Boundaries: {system_context_extraction}
Requirements Analysis: {test_requirements_analysis}
Follow-Up Answers: {followup_answers}
Test Plan to Review: {test_plan}

Apply fixes identified in the test plan review to produce the final corrected test plan.

# Test Plan

## Feature Test Cases

### Positive
| Test Case ID | Test Case Title | Example Data |
|--------------|-----------------|--------------|

### Negative
| Test Case ID | Test Case Title | Example Data |
|--------------|-----------------|--------------|

## Regression Test Cases

### Positive
| Test Case ID | Test Case Title | Example Data |
|--------------|-----------------|--------------|

### Negative
| Test Case ID | Test Case Title | Example Data |
|--------------|-----------------|--------------|

Test Plan Requirements:
- Only include test cases that are directly relevant to the user story change.
- Only include test cases that are backed by specific documented facts.
- The test title should be a short description of the business logic being tested.
- The 'Values to be used' column should contain the specific values that will populate the Examples table.
- Design the test plan for Scenario Outline + Examples pattern where it is applicable instead of repetitive test cases.
- Don't include Idempotency tests, performance tests, formatting tests, etc. if there is no documentation to back them up.
- Each test case must reference the source documentation and provide concrete data values, not placeholders or generic descriptions.

User Story: {userInput}
System Boundaries: {system_context_extraction}
Original Test Plan: {test_plan}
Test Plan Review: {test_plan_review}

Generate Gherkin test cases for Feature tests from the final corrected test plan.

For each feature test case:
```gherkin
Feature: [Feature name]
Scenario Outline OR Scenario: [Test title]
  Given [setup for new/changed functionality]
  When [operation testing the change]
  Then [expected outcome]
  Examples:
    | [value 1] | [value 2] | [value 3] |
    | [value 4] | [value 5] | [value 6] |
```

Rules:
- Only include test cases from "feature positive" and "feature negative" sections.
- Do NOT add, remove or adjust the title of the test cases you are generating.
- Do NOT include any test case from "regression positive" or "regression negative" sections.
- Use documented data.

System Boundaries: {system_context_extraction}
Requirements Analysis: {test_requirements_analysis}
Final Test Plan: {final_test_plan}

Generate Gherkin test cases for Regression tests from the final corrected test plan.

For each regression test case:
```gherkin
Feature: [System component]
Scenario Outline OR Scenario: [Test title]
  Given [setup for existing functionality]
  When [operation testing unchanged functionality]
  Then [expected outcome proving it still works]
  Examples:
    | [value 1] | [value 2] | [value 3] |
    | [value 4] | [value 5] | [value 6] |
```

Rules:
- Only include test cases from "regression positive" and "regression negative" sections.
- Do NOT add, remove or adjust the title of the test cases you are generating.
- Do NOT include any test case from "feature positive" or "feature negative" sections.
- Use documented data.

System Boundaries: {system_context_extraction}
Requirements Analysis: {test_requirements_analysis}
Final Test Plan: {final_test_plan}

Combine the test cases into final output format.

# Test Suite

## Feature Positive
```gherkin
Feature: [Feature name]

Scenario Outline OR Scenario: [Test title]
  Given [setup for new/changed functionality]
  When [operation testing the change]
  Then [expected outcome]
  Examples:
    | [value 1] | [value 2] | [value 3] |
    | [value 4] | [value 5] | [value 6] |
```

## Feature Negative

## Regression Positive

## Regression Negative

Output Requirements:
- Present the result in gherkin syntax as clear code blocks for each group
- The groups are: Feature Positive, Feature Negative, Regression Positive, Regression Negative

System Boundaries:
{system_context_extraction}

Test Plan:
{final_test_plan}

Feature Test Cases:
{feature_test_cases}

Regression Test Cases:
{regression_test_cases}