Hier ist ein **robuster Copilot-CLI-Prompt**, in den ich die nötigen Entscheidungs- und Interpretationshinweise direkt eingebaut habe: ```text 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 ```