feat: Update seed yaml skill

This commit is contained in:
2026-02-16 19:43:12 +01:00
parent fed3a2e574
commit c05ffa964b

View File

@@ -1,34 +1,62 @@
---
name: seed-yaml-sync
description: Use when modifying initial_application_form_template.yaml or initial_application_form.yaml seed files - ensures structural consistency, visibility condition correctness, and test data synchronization between template and demo form
description: Use when modifying seed files in template/ or demo/ directories - ensures structural consistency, visibility condition correctness, and test data synchronization between template and demo form
---
# Seed YAML Synchronization
## Overview
The Legal Consent Hub has two interdependent YAML seed files that must stay synchronized:
The Legal Consent Hub has two interdependent seed file directories that must stay synchronized:
1. **Template** (`initial_application_form_template.yaml`) - `isTemplate: true` - defines the form structure, element types, options, visibility conditions, section spawn triggers, and template sections.
2. **Demo form** (`initial_application_form.yaml`) - `isTemplate: false` - a realistic SAP S/4HANA application form with pre-filled values derived from the template. Used for development testing and UI validation.
1. **Template** (`seed/template/`) - `isTemplate: true` - defines the form structure, element types, options, visibility conditions, section spawn triggers, and template sections.
2. **Demo form** (`seed/demo/`) - `isTemplate: false` - a realistic SAP S/4HANA application form with pre-filled values derived from the template. Used for development testing and UI validation.
Changes to either file can break the other. This skill ensures consistency.
Changes to either directory can break the other. This skill ensures consistency.
## File Locations
## File Structure
```
legalconsenthub-backend/src/main/resources/seed/
initial_application_form_template.yaml # Template (source of truth for structure)
initial_application_form.yaml # Demo form (SAP S/4HANA test data)
├── template/ # Template (source of truth for structure)
├── _main.yaml # Main file: isTemplate, name, !include directives
│ ├── section_01_angaben_zum_itsystem.yaml
│ ├── section_02_modulbeschreibung.yaml
│ ├── ... (16 sections total)
│ └── section_16_informationen_zur_kuenstlichen_intelligenz.yaml
└── demo/ # Demo form (SAP S/4HANA test data)
├── _main.yaml # Main file: isTemplate, name, !include directives
├── section_01_angaben_zum_itsystem.yaml
├── section_02_rollen_und_berechtigungen.yaml
├── ... (11 sections total)
└── section_11_informationen_zur_kuenstlichen_intelligenz.yaml
```
### File Format
**`_main.yaml`** contains form metadata and includes section files:
```yaml
isTemplate: true # or false for demo
name: Name des IT-Systems
formElementSections:
- !include section_01_angaben_zum_itsystem.yaml
- !include section_02_modulbeschreibung.yaml
# ... more sections
```
**Section files** contain a single section definition (title, subSections, elements).
The `SplitYamlLoader` class merges these files before deserialization.
## When to Use
- Adding, removing, or modifying form elements in the template
- Adding, removing, or modifying form elements in template sections
- Changing visibility conditions, section spawn triggers, or options
- Adding or modifying template sections
- Changing element types, references, or clonable settings
- Any edit to either seed file
- Any edit to files in either `template/` or `demo/` directory
## The Synchronization Rules
@@ -67,7 +95,7 @@ The demo form simulates a realistic "SAP S/4HANA Einfuehrung" (introduction) sce
- `art_der_massnahme` = "Einfuehrung" selected
- `luv_beabsichtigt` = "Ja" (performance/behavior monitoring intended)
- `personenbezogene_daten_verarbeitet` = "Ja"
- Modules: FI/CO, HCM, SCM (3 cloned modules)
- Modules: FI/CO, HCM, SCM (3 spawned module sections)
- 5 processing operations (V001-V005)
- 5 roles (R001-R005), 6 permissions (P001-P006), 4 scopes (S001-S004)
- 5 interfaces (IF001-IF005)
@@ -88,7 +116,7 @@ When changing visibility conditions:
### Rule 4: Section spawn triggers must reference existing templates
Every `sectionSpawnTriggers[].templateReference` must match a section's `templateReference` in the template file where `isTemplate: true`.
Every `sectionSpawnTriggers[].templateReference` must match a section's `templateReference` in the template directory where `isTemplate: true` in `_main.yaml`.
### Rule 5: Table cross-references must be valid
@@ -111,29 +139,44 @@ When new elements or sections are added to the template:
- The element belongs to a template section that wouldn't spawn in the demo scenario
- Adding data would be contradictory to the existing demo context (e.g., adding "Nein" data where parent says "Ja")
### Rule 7: Cloned elements in the demo form
### Rule 7: Section naming conventions
The demo form demonstrates cloning with 3 modules (modul_1, modul_2, modul_3). When the template changes `modul_1`:
- Apply the same structural change to modul_2 and modul_3 in the demo form
- Each clone keeps its own realistic values
**Template sections** are named by functional purpose:
- `section_01_angaben_zum_itsystem.yaml`
- `section_07_rollen_und_berechtigungen.yaml`
- `section_02_modulbeschreibung.yaml` (template section for spawned modules)
**Demo sections** include spawned section instances:
- `section_07_modul_sap_finance_and_controlling_fico.yaml` (spawned from template)
- `section_08_modul_sap_human_capital_management_hcm.yaml` (spawned from template)
- `section_09_modul_sap_supply_chain_management_scm.yaml` (spawned from template)
### Rule 8: _main.yaml must include all sections
When adding a new section file:
1. Create the section file with appropriate naming
2. Add the `!include` directive to the corresponding `_main.yaml`
3. Maintain logical section ordering
## Checklist for Template Changes
When you modify the **template file**, verify each item:
When you modify files in the **template/ directory**, verify each item:
- [ ] **Structural sync**: Every changed element's structure (type, options labels, visibility conditions, spawn triggers) is mirrored in the demo form for elements that exist there
- [ ] **Structural sync**: Every changed element's structure (type, options labels, visibility conditions, spawn triggers) is mirrored in the corresponding demo section for elements that exist there
- [ ] **New elements**: If a new element is visible in the "Einfuehrung" path, add it to the demo form with appropriate SAP S/4HANA test data
- [ ] **Removed elements**: If an element is removed from the template, remove it from the demo form
- [ ] **Visibility chain integrity**: If you changed a visibility condition's source reference or expected value, trace all downstream dependencies
- [ ] **Spawn trigger integrity**: If you changed spawn triggers, verify the template section references still exist
- [ ] **Table column consistency**: If you added/removed/reordered table columns, update all tables that cross-reference this table (check `sourceTableReference`, `sourceColumnIndex`, `filterCondition.sourceColumnIndex`)
- [ ] **Option label changes**: If you renamed an option label, update all visibility conditions that reference that label as `formElementExpectedValue`
- [ ] **_main.yaml update**: If you added/removed a section file, update `template/_main.yaml`
## Checklist for Demo Form Changes
When you modify the **demo form**, verify:
When you modify files in the **demo/ directory**, verify:
- [ ] **No structural drift**: You haven't changed any structural property that should come from the template (types, labels, visibility conditions, spawn triggers)
- [ ] **Value consistency**: New values are consistent with the SAP S/4HANA "Einfuehrung" context
- [ ] **Table data alignment**: Table JSON arrays all have the same length within a single table element
- [ ] **Cross-reference integrity**: Table values that reference other tables use valid IDs from those tables
- [ ] **Cross-reference integrity**: Table values that reference other tables use valid IDs from those tables
- [ ] **_main.yaml update**: If you added/removed a section file, update `demo/_main.yaml`