Du arbeitest in einem bestehenden Legacy-Repository ./qt-migration-legatus/qt5-before/qt5-legatus-legacy und sollst eine risikoarme Migration des Codegenerators vorbereiten und umsetzen.

## Ziel
Das Projekt verwendet aktuell ein eigenes Codegen-Tool auf Basis von Grantlee5, um aus Service-XML verschiedene Artefakte zu erzeugen, darunter:
- `.idl`
- `.h`
- `.cpp`
- `.sql`
- kopierte `.xml`

Das Legacy-Projekt basiert auf Qt5.
Das Ziel ist Qt6.
Grantlee5 soll durch KDE KTextTemplate ersetzt werden.

Du sollst den bestehenden Generator analysieren, einen minimal-invasiven Migrationspfad entwerfen und den Generator so portieren oder neu implementieren, dass er unter Qt6 mit KTextTemplate funktioniert, ohne die bestehende Build-Integration unnötig zu brechen.

## Wichtiger Kontext
Aus `MacroCodeGenIdl.cmake` geht hervor:
- Es gibt zentrale Codegen-Actions wie:
  - `DDS_TOPICS`
  - `DATABASE`
  - `DATABASE_SERVER`
  - `SQL`
  - `dao`
- Aus XML werden je nach Action mehrere Ausgabedateien erzeugt.
- Die CMake-Makros erwarten bestimmte Dateinamen und Ausgabepfade.
- Templates liegen unter `Lts/Common/CodeGen/*.grantlee`.
- `CODEGEN_TOPIC_TYPEDEFS(...)` verwendet separat ein Python-Skript (`codegen_simple.py`).
- Die `.idl`-Dateien sind hier generierte Textartefakte; sie sind nicht automatisch als C++ zu behandeln.
- C++-Header/Implementierungen, SQL und XML müssen im Generator als unterschiedliche Artefakttypen sauber behandelt werden.

## Deine Aufgaben

### 1) Bestehendes System analysieren
Untersuche zuerst vollständig:
- das aktuelle `codegen`-Tool
- alle Aufrufstellen der Codegen-Actions
- alle `*.grantlee`-Templates
- XML-Parsing und Context-Aufbau
- eventuelle benutzerdefinierte Grantlee-Filter, Tags, Helper, Loader oder Include-Mechanismen
- die CMake-Integration rund um `MacroCodeGenIdl.cmake`

Suche insbesondere nach:
- `codegen`
- `Grantlee`
- `*.grantlee`
- `DDS_TOPICS`
- `DATABASE`
- `DATABASE_SERVER`
- `dao`
- `SQL`
- `codegen_simple.py`

### 2) Zielarchitektur ableiten
Leite auf Basis des Ist-Zustands eine Zielarchitektur ab für einen Qt6-basierten Generator mit KTextTemplate:
- Ein-/Ausgabe-Modell
- Zuordnung Action → Template(s) → Output-Dateien
- XML → internes Datenmodell → Template-Context
- Include-/Partial-Strategie
- Fehlerbehandlung
- deterministische Dateigenerierung
- Encoding/Newline-Verhalten
- Logging/Diagnostik bei Template-Fehlern

### 3) Migration implementieren
Setze die Migration minimal-invasiv um:
- Qt6 statt Qt5
- KTextTemplate statt Grantlee5
- Bestehende Action-Namen und CMake-Aufrufmuster möglichst beibehalten
- Bestehende Dateinamen und Output-Orte beibehalten
- bestehende Template-Logik so weit wie möglich kompatibel halten

Wenn direkte Kompatibilität nicht möglich ist:
- implementiere eine dünne Adapter-/Kompatibilitätsschicht
- oder migriere betroffene Templates kontrolliert und dokumentiert

### 4) Build-System anpassen
Passe CMake so an, dass:
- der neue Generator im Qt6-Setup gebaut wird
- die bestehenden Makros nach Möglichkeit weiter funktionieren
- Incremental Builds nicht unnötig verschlechtert werden
- Abhängigkeiten auf Templates und XML sauber erhalten bleiben

### 5) Dokumentation ergänzen
Erstelle Migrationsnotizen in Markdown:
- bisherige Architektur
- neue Architektur
- Unterschiede Grantlee5 vs. KTextTemplate
- notwendige Template-Anpassungen
- bekannte Inkompatibilitäten
- offene Risiken
- Follow-up-Empfehlungen

## Harte Randbedingungen
- Keine unnötige Komplett-Neuschreibung.
- Keine großflächigen Refactorings außerhalb des Codegen-Bereichs.
- Keine Änderung der fachlichen XML-Semantik ohne klare Notwendigkeit.
- Keine Änderung der erwarteten Output-Dateinamen ohne sehr gute Begründung.
- Keine Änderung der öffentlichen CMake-Makro-Schnittstellen, wenn vermeidbar.
- Python-basierten Teil (`codegen_simple.py`) nur dann anfassen, wenn er für Qt6-/Build-Kompatibilität relevant ist.

## Erwartetes Vorgehen
1. Zuerst analysieren, nicht blind umschreiben.
2. Dann eine kurze Migrationsstrategie formulieren.
3. Danach gezielte Codeänderungen durchführen.
4. Änderungen klein und reviewbar halten.
5. Wenn möglich vorhandene Tests/Build-Ziele nutzen oder ergänzen.
6. Falls keine Tests existieren, mindestens Plausibilitätschecks für die Generierung einbauen.

## Explizit zu prüfende Risiken
Prüfe und dokumentiere ausdrücklich:
- benutzerdefinierte Grantlee-Filter/Tags
- Unterschiede bei Schleifen, Includes, Escaping und Kontextauflösung
- Mehrfachgenerierung pro Action
- Pfad- und Dateinamenskonventionen
- Reihenfolge/Stabilität generierter Inhalte
- UTF-8 / Zeilenenden
- Verhalten bei fehlenden XML-Feldern
- Fehlerdiagnose bei Template-Rendering-Problemen
- CMake-Dependencies und Rebuild-Verhalten

## Akzeptanzkriterien
Die Aufgabe ist erst dann fertig, wenn mindestens Folgendes erfüllt ist:

1. Ein Qt6-basierter Generator existiert oder der alte Generator ist erfolgreich auf Qt6 portiert.
2. Grantlee5-Abhängigkeit ist im migrierten Pfad entfernt oder isoliert ersetzt.
3. KTextTemplate wird für das Rendering verwendet.
4. Die bisherigen zentralen Actions sind weiterhin abbildbar:
   - `DDS_TOPICS`
   - `DATABASE`
   - `DATABASE_SERVER`
   - `SQL`
   - `dao`
5. Die generierten Output-Dateien bleiben in Namen und Verzeichnisstruktur kompatibel, soweit technisch möglich.
6. Die CMake-Integration funktioniert weiterhin mit den vorhandenen Makros oder mit minimalen kompatiblen Anpassungen.
7. Die Migration ist dokumentiert.
8. Bekannte Inkompatibilitäten und Restarbeiten sind klar benannt.

## Definition of Done
Am Ende liefere bitte:

1. **Kurze Architekturzusammenfassung**
   - Alt
   - Neu
   - wichtigste Unterschiede

2. **Umgesetzte Migrationsentscheidungen**
   - warum KTextTemplate so eingebunden wurde
   - ob Adapter oder direkte Template-Migration gewählt wurde
   - warum

3. **Liste aller geänderten Dateien**

4. **Konkrete Codeänderungen**
   - inklusive CMake-Anpassungen
   - Generator-Code
   - Template-Anpassungen
   - Doku

5. **Validierung**
   - was gebaut/getestet wurde
   - was nur statisch geprüft wurde
   - was noch offen ist

6. **Offene Risiken / Follow-ups**

## Bevorzugte Ergebnisqualität
Bevorzuge eine inkrementelle, robuste Migration über eine elegante, aber riskante Neuentwicklung.
Wenn mehrere Wege möglich sind, entscheide dich für den mit:
- geringstem Integrationsrisiko
- geringster Build-Störung
- bester Nachvollziehbarkeit im Review

Wenn Annahmen notwendig sind:
- triff sie explizit,
- dokumentiere sie,
- und halte Änderungen reversibel.

Bitte arbeite repository-basiert und leite Entscheidungen aus dem tatsächlich vorhandenen Code ab, nicht aus allgemeinen Annahmen über Grantlee oder KTextTemplate.