qt6-migration-pipeline/prompts/merge-qt6-migration-removes-niklas-unneeded-modules-list-from-repo-check.prompt.md

Hier ist ein robuster Copilot-CLI-Prompt, in den ich die nötigen Entscheidungs- und Interpretationshinweise direkt eingebaut habe:

Nutze die harten Regeln und Diagnosehinweise aus diesem Chat als verbindlichen Detailkontext und bearbeite folgende Aufgabe robust, minimal und reproduzierbar.

Git-Kontext:
- Zielbranch:
  - feature/qt6-migration-basis-modules
- aktueller Branch:
  - feature/qt6-migration-basis-modules

Relevante Commits:
- 44fdf2ac9
  - aktueller HEAD / Merge-Stand
  - enthält die Modul-Löschungen aus dem Mergekontext
- 92ad7d468
  - remove all unneeded module listed from Niklas
- be912de9d
  - Removes .IDL warnings: multiple enum definitons and builtin-type collisions

Aufgabe:
- prüfe, ob Änderungen aus Commit `be912de9d` durch Commit `92ad7d468` oder durch den Merge-Stand `44fdf2ac9` verworfen, überschrieben oder effektiv entkoppelt wurden
- behandle dies als Regressionssuche
- stelle die in `be912de9d` beabsichtigte Behebung der `.IDL`-Warnungen im aktuellen HEAD wieder her, **aber ohne** die in `92ad7d468` gelöschten Module zurückzubringen
- die Modul-Löschungen aus `92ad7d468` müssen vollständig erhalten bleiben

Wichtige Arbeitsregel:
- `44fdf2ac9` ist der Arbeitsstand
- `be912de9d` ist nur Referenz-Fix, nicht blind replayen
- `92ad7d468` ist die harte Erhaltungsgrenze für gelöschte Module
- übernimm nur die Teile von `be912de9d`, die im aktuellen Tree noch fachlich/technisch relevant sind
- wenn Pfade, CMake-Struktur, Generatorpfade oder Modullisten sich geändert haben, adaptiere die frühere Lösung minimal auf den aktuellen Tree
- keine Wiederherstellung gelöschter Module
- keine Abhängigkeit auf entfernte Dateien, Targets oder Verzeichnisse einführen

Pflicht: nutze die Warnungsliste als Wahrheitstest
- alle 145 Warnungen liegen in:
  - `./not_complaint.txt`
- nutze `./not_complaint.txt` als vollständige und maßgebliche Liste
- verifiziere vor und nach den Änderungen, welche Warnungsgruppen tatsächlich betroffen sind

Verbindlicher Build-/Migrationskontext:
- die Migration ist noch nicht abgeschlossen
- Migrationscontainer:
  - `./app/Dockerfile`
- Validierungscontainer:
  - `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/docker_build.sh`
- `/workspace` ist der relevante Mount-Pfad im Validierungscontainer
- generierte `.idl`, `.h`, `.cpp` Dateien aus RTI / ndsgen / ktexttemplate-app müssen im **Build-Folder** entstehen und von dort 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
- 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

Konkreter Warnungskontext:
- multiple enum definitions / duplicate enumerators
- builtin-type / keyword collisions
- Beispieltypen:
  - `On`, `Off`, `Normal`, `Undefined`
  - `bitMask`, `typeId`, `eventType`

Pflichtanalyse:
1. untersuche die Diffs und Wirkungen von:
   - `be912de9d`
   - `92ad7d468`
   - `44fdf2ac9`
2. ermittle präzise:
   - welche Teile von `be912de9d` die `.IDL`-Warnungen behoben haben
   - welche dieser Änderungen durch `92ad7d468` entfernt, überschrieben oder unwirksam gemacht wurden
   - welche dieser Änderungen im aktuellen HEAD `44fdf2ac9` noch fehlen
3. prüfe dabei zuerst strikt:
   - ob die Warnungen durch doppelte Inputs, Altpfade, doppelte Codegen-Quellen, falsche Include-/Import-Reihenfolgen, stale Artefakte oder entfernte-aber-noch-referenzierte Module entstehen
   - erst danach, ob ein echter fachlicher IDL/XTypes-Konflikt verbleibt
4. nutze `./not_complaint.txt`, um Warnungen nach Root-Cause-Gruppen zu clustern und mit dem damaligen Fix abzugleichen

Verbindliche Entscheidungslogik für `be912de9d`:
- **nicht blind replayen**
- wenn eine von `be912de9d` geänderte Datei heute noch existiert und noch relevant ist:
  - sie ist Kandidat für direkte oder fast direkte Übernahme
- wenn eine von `be912de9d` geänderte Datei heute fehlt, weil ihr Modul durch `92ad7d468` gelöscht wurde:
  - nicht wiederherstellen
  - keinen Patchteil dafür übernehmen, der gelöschte Module zurückbringen würde
- wenn eine von `be912de9d` geänderte Datei heute noch fachlich relevant ist, aber der Pfad/Buildkontext sich geändert hat:
  - die damalige Fix-Absicht manuell/adaptiert auf die heutige Struktur übertragen
- wenn die heutigen Warnungen eher aus Pfad-/Codegen-/Artefaktproblemen stammen:
  - nur die Idee aus `be912de9d` übernehmen, nicht seinen Patch blind nachbauen

Praktische Interpretationsregel:
- wenn du feststellst: „gleiche Ursache wie früher, aber heute andere/kleinere Modulmenge oder andere Pfade“
  - dann `be912de9d` **partiell manuell/adaptiert replayen**
- wenn du feststellst: „der alte Fix betraf gelöschte Module“
  - diese Teile **nicht** übernehmen
- wenn du feststellst: „das Problem ist heute primär Build-/Codegen-Pfad statt IDL-Inhalt“
  - Root Cause im Build-/Generator-Setup beheben, nicht den alten Inhaltsfix blind kopieren

Pflichtumsetzung:
- implementiere die minimal nötigen Änderungen im aktuellen Branch, um die Warnungen wieder zu beseitigen
- erhalte dabei strikt den Modullösch-Stand aus `92ad7d468`
- passe frühere Fixes aus `be912de9d` an den aktuellen Tree an, statt sie blind zurückzukopieren
- wenn frühere Fixes Dateien oder Module berühren, die in `92ad7d468` gelöscht wurden, extrahiere nur die noch relevanten Teile und übertrage sie sauber auf die verbleibenden Module
- ändere nur direkt betroffene Dateien, CMake-Skripte und Generator-Aufrufe

Spezielle Prüfregeln für Codegen/IDL:
- prüfe, ob dieselben IDL-Definitionen mehrfach in den aktuellen Build eingespeist werden
- prüfe, ob entfernte Module aus `92ad7d468` indirekt noch über Listen, Imports, Templates oder Generatorpfade referenziert werden
- prüfe, ob die Warnungen durch verbliebene Altpfade oder doppelte Inputs entstehen
- prüfe, ob generierte Outputs korrekt im Build-Folder landen und von dort konsumiert werden
- prüfe `add_custom_command(OUTPUT ...)`, `BYPRODUCTS`, `DEPENDS`, `WORKING_DIRECTORY`, `COMMAND`, `VERBATIM`, `target_sources(...)`, `target_include_directories(...)`, `add_dependencies(...)`

Harte Regeln:
- gelöschte Module aus `92ad7d468` dürfen nicht wiederhergestellt werden
- keine Refactorings
- keine opportunistischen Fixes
- keine Änderungen im Legacy-Tree
- keine Warnungsunterdrückung statt echter Ursachenbehebung
- keine Fake-Erfolge
- keine neuen Stubs, Platzhalter oder erfundenen generierten Dateien
- keine generierten `.idl`, `.h`, `.cpp` ins Repository einchecken
- keine inhaltlichen IDL-Großumbauten, solange Pfad-/Codegen-/Artefaktursachen nicht ausgeschlossen sind

Container-Regeln:
- Migration muss mit `./app/Dockerfile` weiter möglich bleiben
- Validierung erfolgt mit `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/docker_build.sh`
- falls nötig, passe Migrationscontainer und/oder Validierungscontainer minimal an, aber nur wenn dies direkt für den Fix oder die fortgesetzte Migration nötig ist
- nutze keine Host-Annahmen

Pflichtvalidierung:
- stale Build-/Codegen-Artefakte ausschließen
- die betroffenen Generatoren im aktuellen Kontext erneut laufen lassen
- im Validierungscontainer konfigurieren und bauen
- vor/nachher anhand von `./not_complaint.txt` und neuem Build-Output prüfen, ob die Warnungen verschwunden oder reduziert sind
- Abschluss-Checks ausführen:
  - `./docker-build.h`
  - `BUILD_RTI=OFF ./docker_build.sh`

Erfolgskriterien:
- die durch `be912de9d` ursprünglich behobenen `.IDL`-Warnungen sind im aktuellen HEAD `44fdf2ac9` wieder beseitigt oder root-cause-basiert minimal korrigiert
- die Modul-Löschungen aus `92ad7d468` bleiben vollständig erhalten
- keine entfernten Module wurden wieder eingeführt
- generierte Dateien werden nur aus dem Build-Folder verwendet
- keine Scheinlösung durch Warnungsunterdrückung

Wenn nicht vollständig lösbar:
- nichts vortäuschen
- exakt angeben:
  - welche Teile von `be912de9d` noch relevant waren
  - welche davon wegen `92ad7d468` nicht direkt übernehmbar waren
  - welche Warnungsgruppen aus `./not_complaint.txt` gelöst wurden und welche nicht
  - ob der Blocker ein Projekt-, Pfad-, Artefakt-, Merge- oder Umgebungsproblem ist

Abschlussbericht nur kurz:
- validiert, teilweise validiert oder blockiert
- welche Änderungen aus `be912de9d` effektiv wiederhergestellt/adaptiert wurden
- Bestätigung, dass gelöschte Module aus `92ad7d468` nicht zurückgebracht wurden
- 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