Checks merge-in of Niklas remove modules list branch

2026-09-15 08:38:32 +00:00
1 parent 4b6ef4a176
commit 1f478174ff
@@ -0,0 +1,166 @@
 Hier ist ein **robuster Copilot-CLI-Prompt**, in den ich die nötigen Entscheidungs- und Interpretationshinweise direkt eingebaut habe:
 ```text
 Nutze die Prompts, 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
 ```