qt6-migration-pipeline/prompts/remove-idl-warnings.prompt.md

Hier ist der **angepasste Prompt** mit der neuen Vorgabe zu `./not_complaint.txt`:

```text
Behebe strikt nur die aktuell auftretenden RTI ndsgen/IDL-Warnungen im Qt6-Migrationsbaum und beachte die Angaben aus diesem Chat als verbindlichen Kontext.

Wichtige Eingabe:
- alle 145 Warnungen liegen in:
  - `./not_complaint.txt`
- nutze diese Datei als vollständige und maßgebliche Ausgangsliste der zu untersuchenden Warnungen
- arbeite die Warnungen nicht nur anhand einzelner Beispiele ab, sondern anhand der vollständigen Liste in `./not_complaint.txt`

Beispielhafte Warnungstypen aus dieser Liste:
- doppelt definierte Enumerator-Namen wie `On`, `Off`, `Normal`, `Undefined`
- Bezeichner-Kollisionen mit IDL-Keywords wie `bitMask`, `typeId`, `eventType`

Verbindlicher Kontext:
- die Migration ist noch nicht abgeschlossen
- der Migrationscontainer ist:
  - `./app/Dockerfile`
- der Validierungscontainer ist:
  - `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/docker_build.sh`
- `/workspace` ist der relevante Mount-Pfad im Validierungscontainer
- frühere IDL-/DDS-Probleme sind zuerst als Pfad-/Codegen-/Artefaktproblem zu behandeln, nicht vorschnell als echter fachlicher IDL-Inhaltsfehler
- Erfolg darf nicht von stale source-tree/build-tree/developer-local Artefakten abhängen

Harte Codegen-Regel:
- `.idl`, `.h` und `.cpp` Dateien, die aus Codegeneratoren entstehen, insbesondere aus:
  - RTI / ndsgen
  - ktexttemplate-app
  müssen aus dem **Build-Folder** erzeugt, inkludiert und verwendet werden
- solche generierten Dateien dürfen **nicht** ins Source-Repository aufgenommen werden
- solche generierten Dateien dürfen **nicht** aus dem Source-Tree konsumiert werden
- Consumer müssen gegen frisch generierte Build-Artefakte kompilieren
- Include-Pfade, Source-Registrierung und Generator-Aufrufe sind entsprechend zu prüfen und falls nötig minimal zu korrigieren

Aufgabe:
- analysiere die vollständige Warnungsliste aus `./not_complaint.txt`
- gruppiere die 145 Warnungen nach Root-Cause-Typen
- finde die kleinste Menge echter Ursachen hinter dieser Gesamtliste
- prüfe zuerst strikt, ob die Warnungen durch falsche Pfade, doppelte Inputs, doppelte Codegen-Quellen, falsche Include-/Import-Reihenfolgen, doppelt referenzierte IDL-Dateien oder Altartefakte entstehen
- behebe die Ursachen robust und minimal
- nur wenn nachweislich echte inhaltliche IDL/XTypes-Konflikte in den real konsumierten Quellen vorliegen, behebe diese minimal und konsistent

Wichtige Diagnose-Priorität:
Behandle die Warnungen zunächst nicht als gesichert fachliche Modellfehler, sondern prüfe zuerst:
- wird dieselbe IDL logisch oder physisch mehrfach in den Build eingespeist?
- werden Inputs zugleich aus alten und neuen Pfaden konsumiert?
- greifen ndsgen-/Generator-Aufrufe noch auf veraltete Verzeichnisse zu?
- existieren doppelte oder redundante enum-/type-Definitionen nur wegen Migrationsartefakten?
- werden generierte oder forward-declaration-nahe Dateien aus dem falschen Ort referenziert?
- werden IDLs mehrfach oder in falscher Reihenfolge importiert?
- hängen die Warnungen von stale generierten Dateien ab?
- liegen generierte `.idl`, `.h` oder `.cpp` fälschlich im Source-Tree oder werden von dort konsumiert?
- sind Build-Ordner-Outputs korrekt in CMake registriert und werden vor der Compilation erzeugt?

Pflichtanalyse:
- lies und nutze `./not_complaint.txt` als vollständige Warnungsquelle
- ermittle daraus wiederkehrende Muster, betroffene Module und wiederholte Symbolnamen
- prüfe alle direkt relevanten `CMakeLists.txt` und cmake-Include-Dateien
- prüfe ndsgen-/RTI-/ktexttemplate-app-Aufrufe
- prüfe `add_custom_command(OUTPUT ...)`, `BYPRODUCTS`, `DEPENDS`, `MAIN_DEPENDENCY`, `WORKING_DIRECTORY`, `COMMAND`, `VERBATIM`
- prüfe `target_sources(...)`, `target_include_directories(...)`, `add_dependencies(...)`
- prüfe betroffene IDL-Dateien, Importketten und generierte Zwischenschritte
- prüfe, ob dieselben Definitionen über unterschiedliche Pfade doppelt gesehen werden
- prüfe explizit, ob generierte Outputs im Build-Ordner landen und von dort konsumiert werden

Harte Regeln:
- nur diese Warnungen und ihre direkte Ursache beheben
- keine opportunistischen Refactorings
- keine Änderungen im Legacy-Tree
- keine Fake-Erfolge
- keine neuen Stubs, Platzhalter oder manuell erfundenen generierten Dateien
- keine pauschale Unterdrückung der Warnungen
- nicht einfach `-strict` abschalten oder Warnungen maskieren
- keine breiten Umbenennungen im gesamten System ohne Nachweis, dass sie wirklich nötig sind
- keine inhaltlichen IDL-Änderungen, solange Pfad-/Codegen-/Artefaktursachen nicht ausgeschlossen sind
- keine generierten `.idl`, `.h`, `.cpp` ins Repository einchecken oder dauerhaft im Source-Tree ablegen

Wenn ein echter Inhaltskonflikt nachgewiesen ist:
- ändere nur die minimal nötigen realen IDL-Quellen
- achte darauf, dass die Änderung IDL/XTypes-konform ist
- bevorzuge kleinste lokale Änderungen, die mehrere Warnungen auf einmal sauber beseitigen
- passe Folgepfade/CMake/Generatoren nur insoweit an, wie für konsistente Generierung nötig
- vermeide weitreichende ABI-/API-Folgen, soweit im Migrationsstand möglich

Container-Regeln:
- Migration muss mit dem Migrationscontainer weiter möglich bleiben:
  - `./app/Dockerfile`
- Validierung erfolgt mit:
  - `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/docker_build.sh`
- nutze keine Host-Annahmen
- Erfolg muss im Container reproduzierbar sein

Pflichtvalidierung:
- relevanten Build-/Codegen-Zustand bereinigen, sodass stale Artefakte ausgeschlossen sind
- Configure im Validierungscontainer ausführen
- Build im Validierungscontainer ausführen
- vergleiche die Warnungen vor/nachher anhand von `./not_complaint.txt` bzw. neu erzeugtem Build-Output
- nachweisen, dass die Warnungsanzahl sinkt oder die Warnungen vollständig verschwinden
- falls Codegenerierung beteiligt ist, nachweisen, dass die aktuell konsumierten Inputs und Outputs aus dem Build-Folder stammen
- Abschluss-Check:
  - `./docker-build.h`
  - `BUILD_RTI=OFF ./docker_build.sh`

Erfolgskriterien:
- die 145 Warnungen aus `./not_complaint.txt` wurden vollständig oder root-cause-basiert weitgehend bereinigt
- die Lösung hängt nicht von Altartefakten oder falschen Pfaden ab
- generierte `.idl`, `.h`, `.cpp` werden aus dem Build-Folder erzeugt und von dort konsumiert
- keine solchen generierten Dateien werden ins Source-Repository aufgenommen
- die wichtigsten Root Causes aus `./not_complaint.txt` sind identifiziert und minimal korrigiert
- Validierungscontainer funktioniert
- Migrationscontainer bleibt konsistent für die Fortsetzung der Migration
- keine Scheinlösung durch Warnungsunterdrückung

Wenn nicht vollständig lösbar:
- nichts vortäuschen
- exakt angeben, welche Warnungsgruppen aus `./not_complaint.txt` gelöst wurden und welche nicht
- angeben, ob Projektproblem, Artefaktproblem, Pfadproblem oder Umgebungsproblem
- die verbleibenden Warnungen bzw. Warnungsgruppen präzise benennen
- den exakten Blocker benennen

Abschlussbericht nur kurz:
- validiert, teilweise validiert oder blockiert
- Anzahl Warnungen vorher/nachher
- Root Causes
- geänderte Dateien
- geänderte CMake-/Generator-Aufrufe
- ob `./app/Dockerfile` angepasst wurde
- ob `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/docker_build.sh` angepasst wurde
- exakte Docker-/Build-Kommandos
- Ergebnis von:
  - `./docker-build.h`
  - `BUILD_RTI=OFF ./docker_build.sh`
- verbleibende Blocker oder Risiken
```