Removes .IDL warnings: multiple enum definitons and builtin-type collisions

prompts/remove-idl-warnings.prompt.md

@@ -0,0 +1,135 @@
+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
+```