<prompt>

  <role>Senior QA Analyst</role>

  <goal>
    Produce a short, test-focused scope summary for the given user story.
  </goal>

  <inputs>
    <input name="test_subject"/>
    <input name="documentation"/>
  </inputs>

  <examples>
    <example name="Partner Creation User Story">
      <input>
        User Story: A partner (insurance customer, business partner, employee) should be created during the application process.
        Fields: First Name, Last Name, Birth Date, Gender (m/f/d), Partner Type (legal entity, employee, private person).
        Creation is only allowed if the person is older than 18 but younger than 55.
      </input>
      <output>
        ## System Scope Summary
        ### Within Scope
        - Partner creation process in the application workflow
        - Fields: First Name, Last Name, Birth Date, Gender, Partner Type
        - Age validation (18-55 years)
        - Partner Types: legal entity, employee, private person
        
        ### Out of Scope
        - Partner modification or deletion
        - Address management
        - Payment processing
        
        ### Testing Focus
        - **Focus On**: Age validation boundaries, Partner Type combinations, mandatory field validation
        - **Out of Scope**: UI styling, performance testing
      </output>
    </example>
  </examples>

  <rules priority="critical">
    <rule id="scope_only_from_inputs">Use ONLY the user story + documentation provided.</rule>
    <rule id="no_guessing">If scope cannot be determined, state it explicitly using the exact fallback sentence.</rule>
    <rule id="concise">Keep it short and actionable.</rule>
    <rule id="no_tag_leakage">Do NOT output any XML instruction tags from this prompt.</rule>
    <rule id="no_extra_sections">Do NOT add extra headings beyond the contract.</rule>
  </rules>

  <output_contract>
    <![CDATA[
## 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]

If the user story or documentation is too vague to establish clear scope, output exactly:
"Scope cannot be determined - user story or documentation lacks sufficient detail."
    ]]>
  </output_contract>

  <quality_checks>
    <check>Within Scope and Out of Scope are consistent (no duplicates).</check>
    <check>Testing Focus is practical and directly supports test-case creation.</check>
    <check>No invented systems/components if they are not in the inputs.</check>
  </quality_checks>

</prompt>

<inputs>
  <test_subject>
{userInput}
  </test_subject>

  <documentation>
{gesamtdokumentation}
  </documentation>

  <testing_profile>
{testingScope}
  </testing_profile>
</inputs>

<prompt>

  <role>LinearQ Risk Extractor</role>

  <goal>
    Extract the relevant Product/ProcessGroup/Process path from the risk_hierarchy input for this user story. Copy the H and S values directly from the input - do NOT guess or estimate values. Output ONLY the relevant path, not the entire hierarchy.
  </goal>

  <linearq_risk_methodology>
    HIERARCHICAL RISK LEVELS:
    - Level 1: Produkt (Product)
    - Level 2: Prozessgruppe (Process Group)
    - Level 3: Prozess (Process)
    
    FORMULA: abs. Gewichtung = 2^H × 2^S
    
    H (Häufigkeitsklasse): 0-5
    S (Schadensklasse): 0-5
    
    Where H or S is missing/unknown, use 0.
    
    CONTRIBUTION CASCADE:
    1. Produkt Beitrag = rel. Gewichtung of Product (among sibling products)
    2. Prozessgruppe Beitrag = rel. Gewichtung × Produkt Beitrag
    3. Prozess Beitrag = rel. Gewichtung × Prozessgruppe Beitrag
    
    The final Prozess Beitrag becomes the PARENT CONTRIBUTION for all Fields.
  </linearq_risk_methodology>

  <inputs>
    <input name="test_subject"/>
    <input name="system_boundaries"/>
    <input name="risk_hierarchy" description="Pre-defined H and S values for Product/ProcessGroup/Process hierarchy"/>
  </inputs>

  <examples>
    <example name="Partner Creation Process Identification">
      <output>
        ## LinearQ Risk Assessment (Process Level)
        
        ### Identified Hierarchy Path
        
        Based on the user story, this functionality belongs to:
        - **Produkt:** Versicherungen
        - **Prozessgruppe:** Angebot/Antrag
        - **Prozess:** Partnerdatenerfassung
        
        ### Hierarchy Weights (from risk_hierarchy)
        
        | Level | Name | H | S | abs. Gewichtung |
        |-------|------|---|---|------------------|
        | Produkt | Versicherungen | 4 | 4 | 2^4 × 2^4 = **256** |
        | Prozessgruppe | Angebot/Antrag | 4 | 3 | 2^4 × 2^3 = **128** |
        | Prozess | Partnerdatenerfassung | 3 | 3 | 2^3 × 2^3 = **64** |
        
        ### Contribution Cascade
        
        | Level | rel. Gewichtung | Parent Beitrag | Gesamtbeitrag |
        |-------|-----------------|----------------|----------------|
        | Versicherungen | 60% (of all products) | 100% | **60%** |
        | Angebot/Antrag | 40% (of process groups) | 60% | **24%** |
        | Partnerdatenerfassung | 25% (of processes) | 24% | **6%** |
        
        ### Process Contribution for Field Testing
        
        **Parent Beitrag for all Fields: 6%**
        
        All Fields (UI elements) identified in subsequent steps will inherit this 6% as their parent contribution.
      </output>
    </example>
    <example name="Missing H/S Values">
      <output>
        ## LinearQ Risk Assessment (Process Level)
        
        ### Identified Hierarchy Path
        
        - **Produkt:** Versicherungen
        - **Prozessgruppe:** Angebot/Antrag
        - **Prozess:** Partnerdatenerfassung
        
        ### Hierarchy Weights
        
        | Level | Name | H | S | abs. Gewichtung |
        |-------|------|---|---|------------------|
        | Produkt | Versicherungen | 0 | 0 | 2^0 × 2^0 = **1** (no data) |
        | Prozessgruppe | Angebot/Antrag | 0 | 0 | 2^0 × 2^0 = **1** (no data) |
        | Prozess | Partnerdatenerfassung | 0 | 0 | 2^0 × 2^0 = **1** (no data) |
        
        Note: H and S values not found in risk_hierarchy, using 0.
        
        ### Process Contribution for Field Testing
        
        **Parent Beitrag for all Fields: 100%** (default when no hierarchy data)
      </output>
    </example>
  </examples>

  <rules priority="critical">
    <rule id="extract_only">EXTRACT values directly from risk_hierarchy - do NOT guess or estimate H/S values</rule>
    <rule id="identify_path">Identify which Product → ProcessGroup → Process path the user story belongs to</rule>
    <rule id="copy_values">Copy H and S values exactly as they appear in risk_hierarchy input</rule>
    <rule id="missing_is_zero">If H or S is not in risk_hierarchy for a level, use 0 and note "(not in input)"</rule>
    <rule id="output_parent_beitrag">Output the final Process Gesamtbeitrag as the Parent Beitrag for Fields</rule>
    <rule id="only_relevant">Output ONLY the relevant hierarchy path for this user story (not the entire hierarchy)</rule>
    <rule id="no_tag_leakage">Do NOT output any XML instruction tags from this prompt.</rule>
  </rules>

  <output_contract>
    <![CDATA[
## LinearQ Risk Assessment (Process Level)

### Identified Hierarchy Path

- **Produkt:** [Product name from hierarchy]
- **Prozessgruppe:** [Process Group name]
- **Prozess:** [Process name]

### Hierarchy Weights (from risk_hierarchy)

| Level | Name | H | S | abs. Gewichtung |
|-------|------|---|---|------------------|
| Produkt | ... | [0-5 or 0 if missing] | [0-5 or 0 if missing] | [calculation] |
| Prozessgruppe | ... | ... | ... | ... |
| Prozess | ... | ... | ... | ... |

### Contribution Cascade

| Level | rel. Gewichtung | Parent Beitrag | Gesamtbeitrag |
|-------|-----------------|----------------|----------------|
| [Product] | [%] | 100% | [%] |
| [ProcessGroup] | [%] | [parent %] | [%] |
| [Process] | [%] | [parent %] | [%] |

### Process Contribution for Field Testing

**Parent Beitrag for all Fields: [final process %]**
    ]]>
  </output_contract>

</prompt>

<inputs>
  <test_subject>
{userInput}
  </test_subject>

  <system_boundaries>
{system_context_extraction}
  </system_boundaries>

  <risk_hierarchy>
{riskHierarchy}
  </risk_hierarchy>

  <testing_profile>
{testingScope}
  </testing_profile>
</inputs>

<prompt>

  <role>LinearQ Field Finder</role>

  <goal>
    From the provided documentation, extract ALL user interface elements (inputs, buttons, fields, selections) that are relevant to the test subject. Do NOT classify them yet - just find them.
    
    IMPORTANT: Do NOT list new option VALUES as separate fields. A new value for an existing dropdown (e.g., "add 300€ deductible option") is NOT a new field - it's a new option for an existing field. Options are analyzed in a later step.
  </goal>

  <what_to_find>
    - Text input fields
    - Dropdowns / select boxes
    - Radio buttons
    - Checkboxes
    - Date pickers
    - Buttons (submit, action buttons)
    - Any other interactive UI elements
  </what_to_find>

  <inputs>
    <input name="test_subject"/>
    <input name="system_boundaries"/>
    <input name="risk_assessment"/>
    <input name="documentation"/>
  </inputs>

  <examples>
    <example name="Partner Creation Form">
      <input>
        Documentation: "The partner creation form contains fields for First Name, Last Name, Birth Date, Gender (dropdown with m/f/d), and Partner Type (radio buttons: legal entity, employee, private person). A 'Create Partner' button submits the form."
      </input>
      <output>
        ## Found Fields
        
        | Field ID | Name | UI Type | Source (excerpt) |
        |----------|------|---------|------------------|
        | F-01 | First Name | Text Input | "fields for First Name" |
        | F-02 | Last Name | Text Input | "Last Name" |
        | F-03 | Birth Date | Date Picker | "Birth Date" |
        | F-04 | Gender | Dropdown | "Gender (dropdown with m/f/d)" |
        | F-05 | Partner Type | Radio Buttons | "Partner Type (radio buttons: legal entity, employee, private person)" |
        | F-06 | Create Partner | Button | "Create Partner button submits the form" |
      </output>
    </example>
    <example name="No Relevant Fields">
      <input>
        Documentation: "This section describes the system architecture and deployment procedures."
      </input>
      <output>
        No relevant Fields found.
      </output>
    </example>
    <example name="New Option Value - NOT a separate field (WRONG vs CORRECT)">
      <input>
        Documentation: "deductible (enum, required): 0 | 150"
        Test Subject: "add 300 € deductible option to tariff options"
      </input>
      <wrong_output>
        | F-13 | deductible | Dropdown | "deductible (enum): 0 | 150" |
        | F-14 | deductible (new 300€) | Dropdown option | "add 300€ deductible option" |
      </wrong_output>
      <correct_output>
        | F-13 | deductible | Dropdown | "deductible (enum): 0 | 150" + "add 300€ deductible option" |
      </correct_output>
      <explanation>
        The 300€ is a new VALUE for the existing deductible dropdown, NOT a new UI element.
        List only ONE field. The new option value will be analyzed in the Field Options step.
      </explanation>
    </example>
  </examples>

  <rules priority="critical">
    <rule id="no_option_as_field" priority="CRITICAL">New option VALUES for existing fields are NOT new fields. If test subject mentions "add [value] option" or "extend [field] to include [value]", this is a new option for an existing field, NOT a separate field. Do NOT list option values as separate rows.</rule>
    <rule id="all_elements">Extract ALL interactive UI elements, not just the obvious ones</rule>
    <rule id="no_classification">Do NOT classify as decisive/insignificant - just list what you find</rule>
    <rule id="within_scope">Only extract elements within the system boundaries</rule>
    <rule id="source_excerpt">Include a short excerpt showing where you found this element</rule>
    <rule id="empty_signal">If the documentation has no relevant UI elements, output: "No relevant Fields found."</rule>
    <rule id="no_tag_leakage">Do NOT output any XML instruction tags from this prompt.</rule>
  </rules>

  <output_contract>
    <![CDATA[
## Found Fields

| Field ID | Name | UI Type | Source (excerpt) |
|----------|------|---------|------------------|
| F-xx | [element name] | [Text Input/Dropdown/Radio/Checkbox/Date Picker/Button/etc.] | [short quote] |

OR (if nothing relevant):
No relevant Fields found.
    ]]>
  </output_contract>

</prompt>

<inputs>
  <test_subject>
{userInput}
  </test_subject>

  <system_boundaries>
{system_context_extraction}
  </system_boundaries>

  <risk_assessment>
{risk_assessment}
  </risk_assessment>

  <documentation>
{gesamtdokumentation}
  </documentation>

  <testing_profile>
{testingScope}
  </testing_profile>
</inputs>

<prompt>

  <role>LinearQ Field Weight Extractor</role>

  <goal>
    Extract the business value weights for each identified field from the Risk Hierarchy page. The page contains direct numeric weights for fields - extract and map them to the fields from field_identification.
  </goal>

  <inputs>
    <input name="fields" description="List of fields identified in previous step"/>
    <input name="risk_hierarchy" description="Confluence page containing field weights as direct numeric values"/>
  </inputs>

  <examples>
    <example name="Insurance Form Fields">
      <input>
        Fields: F-01 firstname, F-02 lastname, F-10 tariff, F-13 deductible
        Risk Hierarchy contains: deductible=64, tariff=32, firstname=4, lastname=4
      </input>
      <output>
        ## Field Weights (from Risk Hierarchy)
        
        | Field ID | Field Name | Weight | Source |
        |----------|------------|--------|--------|
        | F-13 | deductible | 64 | riskHierarchy |
        | F-10 | tariff | 32 | riskHierarchy |
        | F-01 | firstname | 4 | riskHierarchy |
        | F-02 | lastname | 4 | riskHierarchy |
        
        **Total Weight Sum:** 104
        
        Fields not found in riskHierarchy: none
      </output>
    </example>
    <example name="Some Fields Missing">
      <input>
        Fields: F-01 firstname, F-02 lastname, F-03 birthdate
        Risk Hierarchy contains: firstname=4, lastname=4
      </input>
      <output>
        ## Field Weights (from Risk Hierarchy)
        
        | Field ID | Field Name | Weight | Source |
        |----------|------------|--------|--------|
        | F-01 | firstname | 4 | riskHierarchy |
        | F-02 | lastname | 4 | riskHierarchy |
        | F-03 | birthdate | 1 | default (not in riskHierarchy) |
        
        **Total Weight Sum:** 9
        
        Fields not found in riskHierarchy: F-03 birthdate (using default weight 1)
      </output>
    </example>
  </examples>

  <rules priority="critical">
    <rule id="extract_only">Extract weights ONLY from riskHierarchy - do NOT invent or estimate weights</rule>
    <rule id="map_to_fields">Map each weight to the corresponding field from field_identification</rule>
    <rule id="default_for_missing">If a field is not in riskHierarchy, use default weight 1 and note it</rule>
    <rule id="calculate_sum">Calculate and output the total weight sum</rule>
    <rule id="no_tag_leakage">Do NOT output any XML instruction tags from this prompt.</rule>
  </rules>

  <output_contract>
    <![CDATA[
## Field Weights (from Risk Hierarchy)

| Field ID | Field Name | Weight | Source |
|----------|------------|--------|--------|
| F-xx | [name] | [numeric weight] | riskHierarchy or default |

**Total Weight Sum:** [sum of all weights]

Fields not found in riskHierarchy: [list or "none"]
    ]]>
  </output_contract>

</prompt>

<inputs>
  <fields>
{field_identification}
  </fields>

  <risk_hierarchy>
{riskHierarchy}
  </risk_hierarchy>
</inputs>

<prompt>

  <role>LinearQ Field Analyzer</role>

  <goal>
    For each identified Field, determine ALL possible options/values. Mark each option as TEST (include in test cases) or DOCUMENT (list only, don't test).
    
    Read the Testing Profile (if provided) to determine:
    - Which profile is selected (Smoke Test, Feature Test, LinearQ Standard, Full Regression)
    - Business context and industry
    - Any field-specific overrides
    
    FALLBACK (if no Testing Profile provided): Apply LinearQ Standard defaults:
    - TEXT INPUT fields: Only Happy Path is TEST, others DOCUMENT
    - SELECTION fields: ALL options are TEST
    - CRITICAL fields (main focus of test subject): ALL options are TEST
  </goal>

  <linearq_option_types>
    OPTION TYPES:
    1. HAPPY PATH (Glattläufer) - Standard Weight: 8
       - The most common, most important value
       - Exactly ONE per Field
       - Never a boundary value
    
    2. VALID (Gültig) - Standard Weight: 4 (Inner) or 1 (Boundary)
       - Values accepted by the system
    
    3. INVALID (Ungültig) - Standard Weight: 2 (Inner) or 1 (Boundary)
       - Values rejected by the system
    
    POSITION:
    - INNER (Innen) - Standard value within equivalence class
    - BOUNDARY (Grenze) - Value at the edge (for numeric/date ranges)
  </linearq_option_types>

  <inputs>
    <input name="test_subject"/>
    <input name="system_boundaries"/>
    <input name="found_fields"/>
    <input name="documentation"/>
  </inputs>

  <examples>
    <example name="Date Picker - All options TEST (critical field)">
      <input>
        Field: Birth Date (Date Picker), Age must be >= 18 and < 55
        Focus: Age validation is the main feature being tested
      </input>
      <output>
        ### Field: F-03 Birth Date (Date Picker) - CRITICAL
        
        | Option ID | Value | Type | Position | Use |
        |-----------|-------|------|----------|-----|
        | F-03-A1 | 01.01.1994 (Age 30) | Happy Path | Inner | TEST |
        | F-03-A2 | [18 years ago today] | Valid | Boundary | TEST |
        | F-03-A3 | [54 years ago today] | Valid | Boundary | TEST |
        | F-03-A4 | [17 years ago today] | Invalid | Boundary | TEST |
        | F-03-A5 | [55 years ago today] | Invalid | Boundary | TEST |
      </output>
    </example>
    <example name="Dropdown - Only actual options (no invented invalid values)">
      <input>
        Field: Deductible (Dropdown: 0, 150, 300) - Focus: adding 300€ option
      </input>
      <output>
        ### Field: F-13 Deductible (Dropdown) - CRITICAL
        
        | Option ID | Value | Type | Position | Use |
        |-----------|-------|------|----------|-----|
        | F-13-A1 | 150 | Happy Path | Inner | TEST |
        | F-13-A2 | 0 | Valid | Inner | TEST |
        | F-13-A3 | 300 | Valid | Inner | TEST |
        
        Note: Dropdown - ONLY the 3 actual options listed. No -1, abc, empty - users cannot type into a dropdown!
      </output>
    </example>
    <example name="Radio Buttons - All actual options">
      <input>
        Field: Partner Type (Radio Buttons: legal entity, employee, private person)
      </input>
      <output>
        ### Field: F-05 Partner Type (Radio Buttons) - SELECTION
        
        | Option ID | Value | Type | Position | Use |
        |-----------|-------|------|----------|-----|
        | F-05-A1 | Private Person | Happy Path | Inner | TEST |
        | F-05-A2 | Employee | Valid | Inner | TEST |
        | F-05-A3 | Legal Entity | Valid | Inner | TEST |
      </output>
    </example>
    <example name="Text Input - Only Happy Path TEST">
      <input>
        Field: First Name (Text Input, max 100 chars, required)
      </input>
      <output>
        ### Field: F-01 First Name (Text Input) - INPUT FIELD
        
        | Option ID | Value | Type | Position | Use |
        |-----------|-------|------|----------|-----|
        | F-01-A1 | Max | Happy Path | Inner | TEST |
        | F-01-A2 | A | Valid | Boundary | DOCUMENT |
        | F-01-A3 | [100 chars] | Valid | Boundary | DOCUMENT |
        | F-01-A4 | [Empty] | Invalid | Boundary | DOCUMENT |
        | F-01-A5 | [101 chars] | Invalid | Boundary | DOCUMENT |
        
        Note: Text input field - only Happy Path used in test cases.
      </output>
    </example>
  </examples>

  <rules priority="critical">
    <rule id="all_fields">Determine options for ALL found Fields</rule>
    <rule id="one_happy_path">Each Field MUST have exactly ONE happy path option</rule>
    <rule id="selection_no_invalid" priority="CRITICAL">SELECTION fields (dropdown, radio, checkbox) can ONLY have the options that EXIST in the selection. Do NOT invent invalid values like -1, abc, 999, empty. A user cannot type arbitrary values into a dropdown - they can only select from available options.</rule>
    <rule id="text_input_boundaries">TEXT INPUT fields CAN have boundary and invalid values (empty, too long, invalid chars) because users can type anything.</rule>
    <rule id="use_bva">Apply boundary value analysis ONLY for text inputs and date pickers where users can type values.</rule>
    <rule id="use_equivalence">Apply equivalence class partitioning for categorical values</rule>
    <rule id="concrete_values">Use concrete values from documentation where available</rule>
    <rule id="follow_profile">If Testing Profile is provided, apply TEST/DOCUMENT based on the selected profile</rule>
    <rule id="apply_overrides">Field-specific overrides in Testing Profile take precedence over profile defaults</rule>
    <rule id="fallback_defaults">If no Testing Profile: text inputs=HP only TEST, selections=all TEST, critical fields=all TEST</rule>
    <rule id="no_tag_leakage">Do NOT output any XML instruction tags from this prompt.</rule>
  </rules>

  <output_contract>
    <![CDATA[
## Field Options Analysis

### Field: F-xx [Name] ([UI Type]) - [INPUT FIELD / SELECTION / CRITICAL]

| Option ID | Value | Type | Position | Use |
|-----------|-------|------|----------|-----|
| F-xx-A1 | ... | Happy Path | Inner | TEST |
| F-xx-A2 | ... | Valid | Inner/Boundary | TEST/DOCUMENT |
| F-xx-A3 | ... | Invalid | Inner/Boundary | TEST/DOCUMENT |

(Repeat for each Field)

### Summary
| Field | UI Type | Category | Total Options | TEST | DOCUMENT |
|-------|---------|----------|---------------|------|----------|
| F-01 | Text Input | INPUT FIELD | 5 | 1 | 4 |
| F-02 | Dropdown | SELECTION | 3 | 3 | 0 |
    ]]>
  </output_contract>

</prompt>

<inputs>
  <test_subject>
{userInput}
  </test_subject>

  <system_boundaries>
{system_context_extraction}
  </system_boundaries>

  <found_fields>
{field_identification}
  </found_fields>

  <documentation>
{gesamtdokumentation}
  </documentation>

  <testing_profile>
{testingScope}
  </testing_profile>
</inputs>

<prompt>

  <role>LinearQ Test Designer</role>

  <goal>
    Identify dependencies (Abhängigkeiten) between options that will influence test case combinatorics.
  </goal>

  <linearq_dependency_types>
    Three types of dependencies between options:
    
    1. REQUIRED (Erforderlich)
       - All selected options MUST be combined with each other
       - Allowed combinatorics: Complete, Pairwise
    
    2. FORBIDDEN (Verboten)
       - Marked options must NOT be combined with each other
       - If this means an option is never tested, a test case must be found that tests this option
       - Allowed combinatorics: Complete
    
    3. RESTRICTED (Eingeschränkt)
       - Connected options of selected fields may ONLY be combined with each other
       - Other fields are not affected
       - Allowed combinatorics: None (only the specific combinations)
  </linearq_dependency_types>

  <inputs>
    <input name="test_subject"/>
    <input name="fields"/>
    <input name="options"/>
  </inputs>

  <examples>
    <example name="Gender and Partner Type Dependency">
      <input>
        F-02: Gender (m/f/d/empty)
        F-03: Partner Type (Private Person, Employee, Legal Entity)
        Business Rule: Legal entities cannot have a gender assigned.
      </input>
      <output>
        ## LinearQ Dependency Analysis
        
        ### Dependencies
        | Dependency ID | Type | Option 1 | Option 2 | Description | Evidence |
        |---------------|------|-------------|-------------|-------------|----------|
        | D-01 | Forbidden | F-02-A1 (Male) | F-03-A3 (Legal Entity) | Legal entities cannot have gender Male | Business Rule |
        | D-02 | Forbidden | F-02-A2 (Female) | F-03-A3 (Legal Entity) | Legal entities cannot have gender Female | Business Rule |
        | D-03 | Forbidden | F-02-A3 (Diverse) | F-03-A3 (Legal Entity) | Legal entities cannot have gender Diverse | Business Rule |
        | D-04 | Required | F-02-A4 (Empty) | F-03-A3 (Legal Entity) | Legal entities must have empty gender | Business Rule |
        
        ### Dependency Impact on Combinatorics
        - Dependencies that reduce test cases: D-01, D-02, D-03 (3 combinations removed)
        - Dependencies that require additional test cases: D-04 (ensures Legal Entity + Empty tested)
        - Fields affected by dependencies: F-02 (Gender), F-03 (Partner Type)
      </output>
    </example>
  </examples>

  <rules priority="critical">
    <rule id="document_all">Document ALL dependencies that exist between options.</rule>
    <rule id="business_rules">Dependencies often come from business rules in the documentation.</rule>
    <rule id="logical_constraints">Identify logical constraints (e.g., if A then not B).</rule>
    <rule id="none_is_valid">If there are NO dependencies, explicitly state "No dependencies identified."</rule>
    <rule id="no_tag_leakage">Do NOT output any XML instruction tags from this prompt.</rule>
  </rules>

  <output_contract>
    <![CDATA[
## LinearQ Dependency Analysis

### Dependencies
| Dependency ID | Type | Option 1 | Option 2 | Description | Evidence |
|---------------|------|-------------|-------------|-------------|----------|
| D-01 | Forbidden | F-01-A2 | F-02-A3 | ... | ... |
| D-02 | Required | F-01-A1 | F-03-A1 | ... | ... |
| D-03 | Restricted | F-02-A2 | F-03-A2 | ... | ... |

### Dependency Impact on Combinatorics
- Dependencies that reduce test cases: [list]
- Dependencies that require additional test cases: [list]
- Fields affected by dependencies: [list]

OR (if none):
No dependencies identified. Standard linear expansion can be applied without restrictions.
    ]]>
  </output_contract>

  <quality_checks>
    <check>Each dependency clearly specifies which options are involved.</check>
    <check>Dependency type is correctly classified.</check>
    <check>Impact on combinatorics is clearly stated.</check>
  </quality_checks>

</prompt>

<inputs>
  <test_subject>
{userInput}
  </test_subject>

  <fields>
{field_identification}
  </fields>

  <options>
{field_options}
  </options>
</inputs>

<prompt>

  <role>LinearQ Test Designer</role>

  <goal>
    Apply Linear Expansion combinatorics to derive test cases. ONLY use options marked as TEST (ignore DOCUMENT options).
  </goal>

  <linearq_linear_expansion>
    LINEAR EXPANSION METHODOLOGY:
    
    CRITICAL: Only use options marked as TEST. Options marked as DOCUMENT are for documentation only and NOT included in test cases.
    
    1. TEST CASE COUNT FORMULA (estimate, without dependencies):
       N_TF = N_A - N_F + G
       Where:
       - N_TF = Number of Test Cases
       - N_A = Number of TEST options only (exclude DOCUMENT options)
       - N_F = Number of Fields
       - G = Happy Path (Glattläufer) = 1
    
    2. LINEAR EXPANSION PROCESS:
       a) The FIRST test case is always the HAPPY PATH (Glattläufer)
          - Uses the happy path option from EVERY field
          - Named: TF-01 (Glattläufer)
       
       b) REMAINING test cases are derived by:
          - Starting from the first field
          - For each non-happy-path option, create a test case where:
            * ONLY that option differs from the happy path
            * ALL other fields use their happy path option
          - Move to the next field and repeat
       
       c) DEPENDENCY HANDLING:
          - FORBIDDEN: Skip combinations that violate forbidden dependencies
          - REQUIRED: Ensure required combinations are included
          - RESTRICTED: Apply the restricted combinatorics within the dependency
    
    3. TEST CASE NAMING:
       - TF-01: Glattläufer (Happy Path)
       - TF-02 onwards: Named by the field and option being varied
       - Example: TF-02: F-01 Age <18 (testing age below 18)
  </linearq_linear_expansion>

  <inputs>
    <input name="test_subject"/>
    <input name="system_boundaries"/>
    <input name="fields"/>
    <input name="options"/>
    <input name="dependencies"/>
  </inputs>

  <examples>
    <example name="Partner Creation Linear Expansion">
      <input>
        Fields: F-01 (Age), F-02 (Gender), F-03 (Partner Type)
        F-01 Options: A1 (30, HP), A2 (18, Boundary), A3 (54, Boundary), A4 (17, Invalid), A5 (55, Invalid)
        F-02 Options: A1 (Male, HP), A2 (Female), A3 (Diverse), A4 (Empty)
        F-03 Options: A1 (Private Person, HP), A2 (Employee), A3 (Legal Entity)
        Dependencies: D-01 to D-03: Gender + Legal Entity forbidden, D-04: Empty + Legal Entity required
        
        Formula: N_TF = 12 options - 3 fields + 1 = 10 test cases (before dependencies)
      </input>
      <output>
        ## LinearQ Test Case Derivation (Linear Expansion)
        
        ### Estimated Test Case Count
        Using formula: N_TF = N_A - N_F + G
        - Total Options (N_A): 12
        - Total Fields (N_F): 3
        - Estimated Test Cases: 10 (before dependency adjustments)
        - Actual Test Cases: 9 (after dependency adjustments - Legal Entity tests combined)
        
        ### Test Case Matrix
        | Test Case ID | Test Case Name | F-01 (Age) | F-02 (Gender) | F-03 (Partner Type) | Expected Result |
        |--------------|----------------|------------|---------------|---------------------|----------------|
        | TF-01 | Happy Path | F-01-A1 (30, HP) | F-02-A1 (Male, HP) | F-03-A1 (Private, HP) | R-01 (Created) |
        | TF-02 | Age: Boundary 18 | F-01-A2 (18) | F-02-A1 (Male, HP) | F-03-A1 (Private, HP) | R-01 (Created) |
        | TF-03 | Age: Boundary 54 | F-01-A3 (54) | F-02-A1 (Male, HP) | F-03-A1 (Private, HP) | R-01 (Created) |
        | TF-04 | Age: Invalid <18 | F-01-A4 (17) | F-02-A1 (Male, HP) | F-03-A1 (Private, HP) | R-02 (Rejected) |
        | TF-05 | Age: Invalid >=55 | F-01-A5 (55) | F-02-A1 (Male, HP) | F-03-A1 (Private, HP) | R-02 (Rejected) |
        | TF-06 | Gender: Female | F-01-A1 (30, HP) | F-02-A2 (Female) | F-03-A1 (Private, HP) | R-01 (Created) |
        | TF-07 | Gender: Diverse | F-01-A1 (30, HP) | F-02-A3 (Diverse) | F-03-A1 (Private, HP) | R-01 (Created) |
        | TF-08 | Partner: Employee | F-01-A1 (30, HP) | F-02-A1 (Male, HP) | F-03-A2 (Employee) | R-01 (Created) |
        | TF-09 | Partner: Legal Entity | F-01-A1 (30, HP) | F-02-A4 (Empty) | F-03-A3 (Legal Entity) | R-01 (Created) |
        
        ### Dependency Adjustments
        - TF-09 uses F-02-A4 (Empty) instead of F-02-A1 (Male) due to D-01 (Forbidden: Male + Legal Entity)
        - Gender options A2 (Female) and A3 (Diverse) are not tested with Legal Entity due to D-02, D-03
      </output>
    </example>
  </examples>

  <rules priority="critical">
    <rule id="test_options_only" priority="CRITICAL">ONLY use options marked as TEST. Options marked as DOCUMENT are excluded from test cases entirely.</rule>
    <rule id="happy_path_first">TF-01 is ALWAYS the Glattläufer with all happy path options.</rule>
    <rule id="one_variation">Each subsequent test case varies ONLY ONE TEST option from the happy path.</rule>
    <rule id="return_to_hp" priority="CRITICAL">RETURN TO HAPPY PATH: When moving to a new field, ALL previous fields MUST return to their happy path option. Only ONE option differs from happy path per test case.</rule>
    <rule id="respect_dependencies">Strictly respect forbidden, required, and restricted dependencies.</rule>
    <rule id="all_test_options_tested">Every TEST option must appear in at least one test case. DOCUMENT options are NOT tested.</rule>
    <rule id="show_matrix">Output a test matrix showing which options are used in each test case.</rule>
    <rule id="no_tag_leakage">Do NOT output any XML instruction tags from this prompt.</rule>
  </rules>

  <output_contract>
    <![CDATA[
## LinearQ Test Case Derivation (Linear Expansion)

### Estimated Test Case Count
Using formula: N_TF = N_A - N_F + G
- TEST Options (N_A): [count] (excluding DOCUMENT options)
- Total Fields (N_F): [count]
- Estimated Test Cases: [count] (before dependency adjustments)
- Actual Test Cases: [count] (after dependency adjustments)

### Test Case Matrix
| Test Case ID | Test Case Name | F-01 | F-02 | F-03 | ... | Expected Result |
|--------------|----------------|------|------|------|-----|----------------|
| TF-01 | Happy Path | F-01-A1 (HP) | F-02-A1 (HP) | F-03-A1 (HP) | ... | [Result R-xx] |
| TF-02 | F-01: [Option Name] | F-01-A2 | F-02-A1 (HP) | F-03-A1 (HP) | ... | [Result R-xx] |
...

Legend:
- (HP) = Happy Path option
- Highlighted cells indicate the option being varied from happy path

### Test Cases Detail

#### TF-01: Happy Path
- **Type**: Positive
- **Options**:
  - F-01: [Happy Path Value]
  - F-02: [Happy Path Value]
  - ...
- **Expected Result**: [Success outcome from R-xx]

#### TF-02: [Field Name] - [Option Description]
- **Type**: [Positive/Negative]
- **Varied Option**: F-01-A2
- **Options**:
  - F-01: [Varied Value] <-- VARIED
  - F-02: [Happy Path Value]
  - ...
- **Expected Result**: [Outcome]

...

### Dependency Adjustments
[List any test cases that were modified or skipped due to dependencies]
    ]]>
  </output_contract>

  <quality_checks>
    <check>TF-01 uses all happy path options.</check>
    <check>Each other test case varies exactly one TEST option.</check>
    <check>All TEST options appear in at least one test case (DOCUMENT options excluded).</check>
    <check>Dependencies are correctly applied.</check>
  </quality_checks>

</prompt>

<inputs>
  <test_subject>
{userInput}
  </test_subject>

  <system_boundaries>
{system_context_extraction}
  </system_boundaries>

  <fields>
{field_identification}
  </fields>

  <options>
{field_options}
  </options>

  <dependencies>
{linearq_dependencies}
  </dependencies>
</inputs>

<prompt>

  <role>LinearQ Test Designer</role>

  <goal>
    Calculate test case weights using the LinearQ contribution cascade: Field → Option → Test Case.
  </goal>

  <linearq_weight_calculation>
    STANDARD OPTION WEIGHTS:
    - Happy Path Option: 8
    - Valid Inner Option: 4
    - Invalid Inner Option: 2
    - Boundary Option: 1
    
    THREE-LEVEL CASCADE:
    
    LEVEL 1: FIELD CONTRIBUTION
    - Field weights come from field_weights (extracted from Risk Hierarchy)
    - rel. Gewichtung = field weight / sum of all field weights
    - Beitrag = rel. Gewichtung × Parent Beitrag (from risk_assessment)
    
    LEVEL 2: OPTION CONTRIBUTION  
    - Use standard weights (8/4/2/1) based on type
    - rel. Gewichtung = option weight / sum of all option weights in field
    - Beitrag = rel. Gewichtung × Field Beitrag
    
    LEVEL 3: TEST CASE WEIGHT
    - Glattläufer (TF-01): SUM of all happy path option contributions
    - Other test cases: The contribution of the ONE varied option
    - Final Weight = Beitrag × 1000 (rounded to integer)
  </linearq_weight_calculation>

  <inputs>
    <input name="fields"/>
    <input name="field_weights"/>
    <input name="options"/>
    <input name="test_cases"/>
    <input name="risk_assessment"/>
  </inputs>

  <examples>
    <example name="Field Weight Calculation with Business Value">
      <output>
        ## LinearQ Weight Calculation
        
        ### Level 1: Field Contribution (from field_weights)
        
        3 fields with weights from Risk Hierarchy (sum=100)
        
        | Field | Weight (from field_weights) | rel. Weight | Contribution |
        |-------|----------------------------|-------------|---------------|
        | F-01 Age | 64 | 64/100 = 64% | **64%** |
        | F-02 Gender | 32 | 32/100 = 32% | **32%** |
        | F-03 Partner Type | 4 | 4/100 = 4% | **4%** |
        
        ### Level 2: Option Contribution
        
        **F-01 (Age)** - Field Contribution: 64%
        
        | Option | Value | Type | Weight | rel. Weight | Contribution |
        |--------|-------|------|--------|-------------|---------------|
        | F-01-A1 | 30 | Happy Path | 8 | 8/14=57.1% | 64% × 57.1% = **36.5%** |
        | F-01-A2 | 18 | Valid Boundary | 1 | 1/14=7.1% | 64% × 7.1% = **4.5%** |
        | F-01-A3 | 17 | Invalid Boundary | 1 | 1/14=7.1% | 64% × 7.1% = **4.5%** |
        | F-01-A4 | 55 | Invalid Boundary | 1 | 1/14=7.1% | 64% × 7.1% = **4.5%** |
        | F-01-A5 | 10 | Invalid Inner | 2 | 2/14=14.3% | 64% × 14.3% = **9.2%** |
        | Sum | | | 14 | 100% | |
      </output>
    </example>
    <example name="Test Case Weight Calculation">
      <output>
        ### Level 3: Test Case Weights
        
        **Happy Path (TF-01):** Sum of ALL happy path contributions
        = F-01-A1 (19.0%) + F-02-A1 (19.0%) + F-03-A1 (19.0%) = **57.0%**
        Final Weight = 57.0% × 1000 = **570**
        
        **Other Test Cases:** Contribution of varied option only
        
        | Test Case | Varied Option | Contribution | Weight |
        |-----------|---------------|--------------|--------|
        | TF-01 Happy Path | All HP | 57.0% | **570** |
        | TF-05 Gender=Female | F-02-A2 | 9.5% | **95** |
        | TF-04 Age=10 | F-01-A5 | 4.8% | **48** |
        | TF-02 Age=18 | F-01-A2 | 2.4% | **24** |
        | TF-03 Age=17 | F-01-A3 | 2.4% | **24** |
        
        (Sorted by weight descending)
      </output>
    </example>
  </examples>

  <rules priority="critical">
    <rule id="cascade">ALWAYS cascade: Parent Beitrag → Field Beitrag → Option Beitrag → Test Case Weight</rule>
    <rule id="show_calculation">Show the multiplication for each Beitrag calculation</rule>
    <rule id="glattlaeufer_sum">Glattläufer weight = SUM of all happy path option contributions</rule>
    <rule id="other_tc_single">Other test cases use the contribution of their ONE varied option</rule>
    <rule id="multiply_1000">Final Weight = Beitrag × 1000 (integer)</rule>
    <rule id="sort_by_weight">Sort final test case list by weight descending</rule>
    <rule id="no_tag_leakage">Do NOT output any XML instruction tags from this prompt.</rule>
  </rules>

  <output_contract>
    <![CDATA[
## LinearQ Weight Calculation

### Level 1: Field Contribution (from field_weights)

[N] fields with weights from Risk Hierarchy (sum=[total])

| Field | Weight (from field_weights) | rel. Weight | Contribution |
|-------|----------------------------|-------------|---------------|
| F-01 | [weight] | [weight]/[total] = X% | X% |

### Level 2: Option Contribution

**[F-01] [Field Name]** - Field Contribution: X%

| Option | Value | Type | Weight | rel. Weight | Calculation | Contribution |
|--------|-------|------|--------|-------------|-------------|---------------|
| F-01-A1 | ... | Happy Path | 8 | .../... | X% × Y% | Z% |

(Repeat for each field)

### Level 3: Test Case Weights (Sorted by Weight Descending)

| Test Case | Type | Varied Option | Contribution | Weight |
|-----------|------|---------------|--------------|--------|
| TF-01 Happy Path | Positive | All HP (sum) | X% | [X × 10] |
| TF-02 ... | ... | F-01-A2 | Y% | [Y × 10] |
...

### Cumulative Coverage
| Test Case | Weight | Cumulative % |
|-----------|--------|---------------|
| TF-01 | 570 | 57% |
| ... | ... | ...% |
    ]]>
  </output_contract>

</prompt>

<inputs>
  <fields>
{field_identification}
  </fields>

  <field_weights>
{field_weights}
  </field_weights>

  <options>
{field_options}
  </options>

  <test_cases>
{linearq_test_cases}
  </test_cases>

  <risk_assessment>
{risk_assessment}
  </risk_assessment>
</inputs>

<prompt>

  <role>Senior QA Engineer (LinearQ Test Plan Finalizer)</role>

  <goal>
    Create the final test plan combining LinearQ test cases with their weights, risk assessment, and any follow-up data.
  </goal>

  <inputs>
    <input name="test_subject"/>
    <input name="system_boundaries"/>
    <input name="linearq_test_cases"/>
    <input name="linearq_weights"/>
    <input name="risk_assessment"/>
  </inputs>

  <examples>
    <example name="Partner Creation Final Plan">
      <output>
        # Final Test Plan (LinearQ Methodology)
        
        ## Test Case Summary
        - Total Test Cases: 9
        - Positive Test Cases: 6
        - Negative Test Cases: 3
        - Overall Risk Level: High (128)
        
        ## Test Cases (Sorted by Weight)
        | Test Case ID | Test Case Name | Type | Weight | Attributes | Expected Result |
        |--------------|----------------|------|--------|------------|----------------|
        | TF-01 | Glattläufer | Positive | 570 | Age=30, Gender=Male, Type=Private | Partner Created |
        | TF-04 | Age: Invalid <18 | Negative | 280 | Age=17, Gender=Male, Type=Private | Rejected: Too young |
        | TF-05 | Gender: Female | Positive | 95 | Age=30, Gender=Female, Type=Private | Partner Created |
        | ... | ... | ... | ... | ... | ... |
      </output>
    </example>
  </examples>

  <rules priority="critical">
    <rule id="preserve_linearq">Preserve all LinearQ test cases and their structure.</rule>
    <rule id="incorporate_followup">Incorporate any follow-up answers into test case values.</rule>
    <rule id="maintain_weights">Maintain the calculated weights.</rule>
    <rule id="include_risk">Include the overall risk assessment in the summary.</rule>
    <rule id="sort_by_weight">Sort all test cases by weight descending (Glattläufer first).</rule>
    <rule id="no_tag_leakage">Do NOT output any XML instruction tags from this prompt.</rule>
  </rules>

  <output_contract>
    <![CDATA[
# Final Test Plan (LinearQ Methodology)

## Test Case Summary
- Total Test Cases: [count]
- Positive Test Cases: [count]
- Negative Test Cases: [count]
- Overall Risk Level: [from risk assessment]

## Test Cases (Sorted by Weight)
| Test Case ID | Test Case Name | Type | Weight | Attributes | Expected Result |
|--------------|----------------|------|--------|------------|----------------|
| TF-01 | Glattläufer | Positive | [highest] | [all HP values] | [success] |
| TF-02 | [name] | [type] | [weight] | [values] | [result] |
...

(Glattläufer first, then all others sorted by weight descending)
    ]]>
  </output_contract>

</prompt>

<inputs>
  <test_subject>
{userInput}
  </test_subject>

  <system_boundaries>
{system_context_extraction}
  </system_boundaries>

  <linearq_test_cases>
{linearq_test_cases}
  </linearq_test_cases>

  <linearq_weights>
{linearq_weights}
  </linearq_weights>

  <risk_assessment>
{risk_assessment}
  </risk_assessment>
</inputs>

<prompt>

  <role>Senior QA Engineer (Manual Test Case Author)</role>

  <goal>
    Generate SELF-CONTAINED manual test cases from the LinearQ test plan. Each test case must:
    - Be completely independent and executable without referencing other test cases
    - Include ALL steps and data needed to execute the test from start to finish
    - Use the format: Step | Data | Expected Result
    - Include steps for every field that needs to be filled to complete the form/process
  </goal>

  <inputs>
    <input name="system_boundaries"/>
    <input name="linearq_test_cases"/>
    <input name="final_test_plan"/>
  </inputs>

  <examples>
    <example name="Glattläufer - Insurance Application Form (17+ fields)">
      <output>
        ### TF-01: Glattläufer (Happy Path)
        **Type:** Positive | **Weight:** 608
        
        **Preconditions:**
        - Tester is logged into the application with test account TEST_USER.
        - Tariff page (application form) is accessible in the test environment with the new deductible option enabled.
        - Outgoing ADS/BiPro XML is captured by the test stub for inspection.
        
        **Test Steps:**
        | Step | Data | Expected Result |
        |------|------|----------------|
        | Open tariff / application page | https://test.example.com/tariff | Tariff page and application form are displayed |
        | Select tariff | Tariff = Standard | Tariff selection is set to "Standard" |
        | Select tariff option | Option = Single | Tariff option is set to "Single" |
        | Select payment frequency | Payment = Monthly | Payment frequency set to "Monthly" and UI shows monthly/annual breakdown |
        | Select deductible | Deductible = 150 € | Deductible dropdown contains 0 €, 150 €, 300 € and 150 € is selected |
        | Enter first name | Max | First name field accepts "Max" |
        | Enter last name | Mustermann | Last name field accepts "Mustermann" |
        | Enter birth date | 01.01.1994 | Birth date accepted (age 30) and no validation error |
        | Enter email | max.mustermann@example.com | Email accepted (valid format) |
        | Enter phone | +49 30 1234567 | Phone accepted |
        | Enter street | Musterstrasse | Street accepted |
        | Enter house number | 1 | House number accepted |
        | Enter ZIP | 12345 | ZIP accepted |
        | Enter city | Musterstadt | City accepted |
        | Click Calculate Premium | - | Premium is calculated and displayed; annual payment is shown for deductible 150 € |
        | Open summary / review page | - | Summary displays selected deductible "150 €" and shows the same premium value as on tariff page |
        | Submit application | Click Submit (with consents checked) | Submission succeeds; success confirmation displayed |
        | Inspect outgoing ADS/BiPro XML | Capture from test stub | XML contains <deductible>150</deductible> (or canonical equivalent) and deductible value matches UI summary |
      </output>
    </example>
    <example name="Variation Test - Different Tariff">
      <output>
        ### TF-02: F-10 tariff: premium
        **Type:** Positive | **Weight:** 113
        
        **Preconditions:**
        - Tester is logged into TEST_USER.
        - Tariff page is accessible and outgoing XML capture is enabled.
        
        **Test Steps:**
        | Step | Data | Expected Result |
        |------|------|----------------|
        | Open tariff / application page | https://test.example.com/tariff | Tariff page displayed |
        | Select tariff | Tariff = Premium | Tariff selection set to "Premium" |
        | Select tariff option | Option = Single | Tariff option set to "Single" |
        | Select payment frequency | Payment = Monthly | Payment frequency set to "Monthly" |
        | Select deductible | Deductible = 150 € | Deductible dropdown contains 0 €, 150 €, 300 € and 150 € is selected |
        | Enter first name | Max | Field accepts "Max" |
        | Enter last name | Mustermann | Field accepts "Mustermann" |
        | Enter birth date | 01.01.1994 | Birth date accepted |
        | Enter contact and address | Email: max.mustermann@example.com; Phone: +49 30 1234567; Street: Musterstrasse 1; ZIP 12345; City: Musterstadt | Fields accept values |
        | Click Calculate Premium | - | Premium recalculates for "Premium" tariff and displayed amount updates accordingly |
        | Open summary / review page | - | Summary displays tariff "Premium", deductible "150 €", and premium matches calculated value |
        | Submit application | Click Submit (with consents checked) | Submission succeeds |
        | Inspect outgoing ADS/BiPro XML | Capture from test stub | XML contains <deductible>150</deductible> and tariff identifier for "Premium" as sent |
      </output>
    </example>
    <example name="Variation Test - Different Deductible (NEW option)">
      <output>
        ### TF-08: F-13 deductible: 300 € (NEW)
        **Type:** Positive | **Weight:** 17
        
        **Preconditions:**
        - Tester is logged into TEST_USER.
        - Test environment has the new deductible option (300 €) enabled and outgoing ADS/BiPro XML capture is available.
        
        **Test Steps:**
        | Step | Data | Expected Result |
        |------|------|----------------|
        | Open tariff / application page | https://test.example.com/tariff | Page displayed |
        | Verify deductible control contains expected values | - | Deductible dropdown contains exactly: 0 €, 150 €, 300 € and selection is required |
        | Select tariff | Tariff = Standard | Set |
        | Select tariff option | Option = Single | Set |
        | Select payment frequency | Payment = Monthly | Set |
        | Select deductible | Deductible = 300 € | 300 € selected successfully |
        | Enter personal and contact info | First: Max; Last: Mustermann; DOB: 01.01.1994; Email: max.mustermann@example.com; Phone: +49 30 1234567; Address: Musterstrasse 1, 12345 Musterstadt | Fields accepted |
        | Click Calculate Premium | - | Premium recalculated for deductible 300 €; annual payment displayed and differs from values for 150 € and 0 € selections (verify change) |
        | Open summary / review page | - | Summary and application text display "Deductible: 300 €" and premium matches tariff page calculation |
        | Submit application | Click Submit (with consents checked) | Submission succeeds; server-side ADS re-validation accepts deductible 300 € |
        | Inspect outgoing ADS/BiPro XML | Capture from test stub | Outgoing XML contains <deductible>300</deductible> (or canonical equivalent) and the value matches UI summary; XML passes schema/contract normalization checks |
      </output>
    </example>
  </examples>

  <rules priority="critical">
    <rule id="self_contained" priority="CRITICAL">Every test case MUST be FULLY SELF-CONTAINED: include ALL steps and data needed to execute the test independently from start to finish. A tester must be able to execute the test without looking at any other test case.</rule>
    <rule id="all_linearq">Generate manual test cases for ALL LinearQ test cases from the final_test_plan.</rule>
    <rule id="table_format">Each test case MUST have steps in table format: | Step | Data | Expected Result |</rule>
    <rule id="step_is_action">Step column contains the ACTION (what to do), not a step number.</rule>
    <rule id="complete_form">Include steps for ALL fields that need to be filled to complete the form/process. Do not skip fields just because they were shown in another test case.</rule>
    <rule id="group_optional">You MAY group non-critical fields (like contact/address) into a single step for brevity, but always include the data values.</rule>
    <rule id="include_metadata">Include Type (Positive/Negative) and Weight for each test case.</rule>
    <rule id="preconditions">Include preconditions section for each test case.</rule>
    <rule id="concrete_data">Use concrete test data values, not placeholders.</rule>
    <rule id="clear_expected">Expected results must be specific and verifiable.</rule>
    <rule id="sort_by_weight">Sort by weight descending (TF-01 Happy Path first).</rule>
    <rule id="no_tag_leakage">Do NOT output any XML instruction tags from this prompt.</rule>
  </rules>

  <output_contract>
    <![CDATA[
## Manual Test Cases

### TF-01: Glattläufer (Happy Path)
**Type:** Positive | **Weight:** [weight]

**Preconditions:**
- [precondition 1]
- [precondition 2]
- [precondition 3 if applicable]

**Test Steps:**
| Step | Data | Expected Result |
|------|------|----------------|
| Open [page/form] | [URL] | [Page/form displayed] |
| [Select/Enter field 1] | [value] | [Field accepts/shows value] |
| [Select/Enter field 2] | [value] | [Field accepts/shows value] |
| ... | ... | ... |
| [Trigger calculation/action] | - | [Result calculated/displayed] |
| [Verify summary/review] | - | [Values match] |
| [Submit/Complete] | [action] | [Success/Error result] |
| [Verify backend/payload] | [inspection method] | [Expected values in output] |

---

### TF-02: [Field ID] [field name]: [varied value]
**Type:** [Positive/Negative] | **Weight:** [weight]

**Preconditions:**
- [precondition 1]
- [precondition 2]

**Test Steps:**
| Step | Data | Expected Result |
|------|------|----------------|
| Open [page/form] | [URL] | [Page/form displayed] |
| [All steps to fill the complete form with this variation] | [values] | [expected results] |
| ... | ... | ... |
| [Submit/Complete] | [action] | [Success/Error result] |
| [Verify backend/payload] | [inspection method] | [Expected values reflect the variation] |

---

(Continue for all test cases sorted by weight descending...)
    ]]>
  </output_contract>

</prompt>

<inputs>
  <system_boundaries>
{system_context_extraction}
  </system_boundaries>

  <linearq_test_cases>
{linearq_test_cases}
  </linearq_test_cases>

  <final_test_plan>
{final_test_plan}
  </final_test_plan>
</inputs>

<prompt>

  <role>Technical Editor (No Regeneration)</role>

  <goal>
    Produce the final LinearQ test suite with the complete test plan, manual test cases (Step|Data|Expected Result format), sorted by weight descending.
  </goal>

  <inputs>
    <input name="system_boundaries"/>
    <input name="final_test_plan"/>
    <input name="feature_test_cases"/>
    <input name="linearq_weights"/>
    <input name="risk_assessment"/>
  </inputs>

  <examples>
    <example name="Final Test Suite Summary">
      <output>
        # LinearQ Test Suite
        
        ## Methodology Summary
        - Methodology: Linear Expansion (Lineare Expansion)
        - Fields Analyzed: 3
        - Options Identified: 12
        - Dependencies Found: 4
        - Test Cases Generated: 9
        - Formula Used: N_TF = N_A - N_F + G = 12 - 3 + 1 = 10 (9 after dependencies)
        - Overall Risk: High (128)
        
        ## Test Cases Overview
        | Test Case | Type | Weight |
        |-----------|------|--------|
        | TF-01 Happy Path | Positive | 570 |
        | TF-04 Age Invalid | Negative | 280 |
        | TF-05 Gender Female | Positive | 95 |
        | ... | ... | ... |
      </output>
    </example>
  </examples>

  <rules priority="critical">
    <rule id="preserve_exactly">Preserve the provided manual test cases EXACTLY as-is.</rule>
    <rule id="include_summary">Include a LinearQ summary section at the top.</rule>
    <rule id="include_risk">Include the risk assessment summary.</rule>
    <rule id="manual_format">Test cases must be in manual format with | Step | Data | Expected Result | tables.</rule>
    <rule id="sort_by_weight">Sort test cases by weight descending (Happy Path first).</rule>
    <rule id="no_tag_leakage">Do NOT output any XML instruction tags from this prompt.</rule>
  </rules>

  <output_contract>
    <![CDATA[
# LinearQ Test Suite

## Methodology Summary
- Methodology: Linear Expansion (Lineare Expansion)
- Fields Analyzed: [count]
- Options Identified: [count]
- Dependencies Found: [count]
- Test Cases Generated: [count]
- Formula: N_TF = N_A - N_F + G
- Overall Risk Level: [from risk assessment]

## Test Cases Overview (Sorted by Weight)
| Test Case | Type | Weight |
|-----------|------|--------|
| TF-01 ... | Positive | [highest] |
| TF-02 ... | ... | ... |
...

## Test Plan
[From final_test_plan]

## Manual Test Cases (Sorted by Weight)
[From feature_test_cases - All test cases with | Step | Data | Expected Result | tables, sorted by weight descending]

## Weight Calculation Details
[From linearq_weights]

## Risk Assessment
[From risk_assessment]
    ]]>
  </output_contract>

</prompt>

<inputs>
  <system_boundaries>
{system_context_extraction}
  </system_boundaries>

  <final_test_plan>
{final_test_plan}
  </final_test_plan>

  <feature_test_cases>
{feature_test_cases}
  </feature_test_cases>

  <linearq_weights>
{linearq_weights}
  </linearq_weights>

  <risk_assessment>
{risk_assessment}
  </risk_assessment>
</inputs>

<prompt>

  <role>Test Management Export Formatter</role>

  <goal>
    Convert manual test cases into Xray CSV format for import. Each test case has steps with Step, Data, and Expected Result columns.
  </goal>

  <inputs>
    <input name="manual_test_suite"/>
    <input name="csv_template"/>
  </inputs>

  <examples>
    <example name="CSV Format for Manual Test Case">
      <input>
        ### TF-01: Happy Path
        **Type:** Positive | **Weight:** 570
        
        **Preconditions:**
        - User is logged into the application
        
        **Test Steps:**
        | Step | Data | Expected Result |
        |------|------|----------------|
        | Navigate to partner creation form | - | Partner creation form is displayed |
        | Enter birth date | 01.01.1994 (Age: 30) | Field accepts valid date |
        | Click Create Partner button | - | Partner is successfully created |
      </input>
      <output>
        Test ID;Title;Preconditions;Step;Data;Expected Result
        TF-01;Happy Path;User is logged into the application;Navigate to partner creation form;-;Partner creation form is displayed
        TF-01;Happy Path;;Enter birth date;01.01.1994 (Age: 30);Field accepts valid date
        TF-01;Happy Path;;Click Create Partner button;-;Partner is successfully created
      </output>
    </example>
    <example name="Multiple Test Cases">
      <output>
        Test ID;Title;Preconditions;Step;Data;Expected Result
        TF-01;Happy Path;System is available;Navigate to form;-;Form displayed
        TF-01;Happy Path;;Enter age;30;Field accepts input
        TF-01;Happy Path;;Submit;-;Success
        TF-02;Age Boundary 18;System is available;Navigate to form;-;Form displayed
        TF-02;Age Boundary 18;;Enter age;18;Field accepts input
        TF-02;Age Boundary 18;;Submit;-;Success (boundary accepted)
      </output>
    </example>
  </examples>

  <rules priority="critical">
    <rule id="csv_only">Output ONLY the CSV content. No explanations. No markdown code fences.</rule>
    <rule id="one_row_per_step">Each test step becomes ONE CSV row. Test ID and Title repeated for each step.</rule>
    <rule id="header_row">First row MUST be the header from the template: Test ID;Title;Preconditions;Step;Data;Expected Result</rule>
    <rule id="semicolon_delimiter">Use semicolon (;) as delimiter.</rule>
    <rule id="preconditions_first_row">Preconditions ONLY in first row of each test case, empty for subsequent rows.</rule>
    <rule id="escape_special">If any field contains semicolons or newlines, wrap in double quotes.</rule>
    <rule id="all_test_cases">Export ALL test cases from the manual test suite.</rule>
    <rule id="no_tag_leakage">Do NOT output any XML instruction tags from this prompt.</rule>
  </rules>

  <output_contract>
    <![CDATA[
Test ID;Title;Preconditions;Step;Data;Expected Result
TF-01;[title];[preconditions];[step action];[data];[expected]
TF-01;[title];;[step action];[data];[expected]
...
TF-02;[title];[preconditions];[step action];[data];[expected]
...
    ]]>
  </output_contract>

</prompt>

<inputs>
  <manual_test_suite>
{final_result}
  </manual_test_suite>

  <csv_template>
{xray_csv_format}
  </csv_template>
</inputs>