qt6-migration-pipeline/prompts/strict-warning-cleanup-lts-dds-docker-agent.prompt.md

GitHub Copilot Instructions: Strict Warning Cleanup for Lts/DDS with Docker Validation

Bereinige ausschließlich warnings und den konkreten CMake/Include-Path-Fehler im Qt6-Migrationsbaum, mit streng minimalen, seiteneffektarmen Änderungen, und validiere anschließend im Docker-Kontext.

Scope

Primärer Scope:

• /repo/qt-migration-legatus/qt6-after/qt6-migrated-legatus/Lts/DDS

Nur falls zwingend direkt notwendig zur Behebung der konkret gemeldeten Probleme, dürfen zusätzlich diese Stellen geändert werden:

• /repo/qt-migration-legatus/qt6-after/qt6-migrated-legatus/Lts/Common/CodeGen/XmlReader.cpp
• /repo/qt-migration-legatus/qt6-after/qt6-migrated-legatus/include/DDS/Generic/generic_base.h
• /repo/qt-migration-legatus/qt6-after/qt6-migrated-legatus/Z/src/NGLLogger/...
• direkt ursächliche CMakeLists.txt-Dateien
• direkt ursächliche cmake-Helper/Includes, nur wenn der fehlerhafte Include-Pfad sonst nicht an der Wurzel korrigierbar ist

Aktueller Stand

• Der aktuelle Lts/DDS-Build ist bereits erfolgreich.
• Ziel ist nicht die funktionale Migration.
• Ziel ist die strikte Bereinigung von:
  1. dem CMake-/Include-Path-Fehler
  2. deprecated warnings
  3. reorder warnings
  4. unused warnings

Harte Regeln

• Keine funktionalen Änderungen
• Keine Refactorings
• Keine API-Änderungen
• Keine Verhaltensänderungen
• Keine Änderungen am Legacy-Tree
• Keine opportunistischen Fixes
• Keine globalen Suppressions wie -Wno-*, wenn lokale Ursachenbehebung möglich ist
• Keine Entfernung potenziell künftig genutzter Parameter aus Funktionssignaturen
• Keine breitflächigen Warning-Cleanup-Aktionen außerhalb der konkret gemeldeten Stellen
• Keine Änderungen, die nur kosmetisch sind und nicht direkt mit den gemeldeten Warnings zusammenhängen

Konkrete Eingaben / bekannte Probleme

Folgende Punkte sind gezielt zu bereinigen:

• deprecated:
  • QDomDocument::setContent(QIODevice*, QString*, int*, int*)
  • QMultiMap::insertMulti(...)
• reorder:
  • Lts/DDS/DDSConnector/dds_connector.cpp
  • Lts/DDS/DDSConnector/dds_connector.h
• unused:
  • include/DDS/Generic/generic_base.h
  • ggf. lokal ungenutzte Funktion in Z/src/NGLLogger/NGLLogger.cpp
• CMake/configure/include-path problem:
  • ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/build4/Z/src/NGLLogger/Z/src/NGLLogger

Priorität 1: CMake-/Include-Path-Root-Cause beheben

Behandle dies als echten Projektfehler in der Build-Konfiguration.

Pflicht

• finde die Ursache des fehlerhaften Include-Verzeichnisses
• korrigiere die Ursache in CMake oder target-bezogener Include-Konfiguration
• bevorzuge saubere, deterministische Pfade
• prüfe insbesondere:
  • include_directories(...)
  • target_include_directories(...)
  • zusammengesetzte relative Pfade
  • versehentliche Verdopplung von Teilpfaden wie Z/src/NGLLogger
  • source-vs-binary-path-Missbrauch

Verboten

• keine Unterdrückung über Compiler-Flags
• kein Belassen eines kaputten Include-Pfads, wenn er nur zufällig harmlos ist
• keine Workarounds über zusätzliche Dummy-Verzeichnisse
• keine symptomatische Änderung ohne Root-Cause-Verständnis

Erwartung

Wenn der Fehler aus einem Modul außerhalb Lts/DDS kommt, ist nur der minimal notwendige Fix dort erlaubt.

Priorität 2: Deprecated warnings risikominimal bereinigen

QDomDocument::setContent(...)

• auf die Qt6-empfohlene API mit ParseResult umstellen
• Fehlerbehandlung semantisch möglichst identisch halten
• keine größere Parser-Logik ändern
• keine Folgerefactorings

QMultiMap::insertMulti(...)

• lokal auf insert(...) umstellen, sofern semantisch gleichwertig für QMultiMap
• keine Container-Umstrukturierung
• keine Logikänderung

Priorität 3: Reorder warnings exakt bereinigen

Für dds_connector.* gilt:

• bevorzuge nur die Anpassung der Initializer-Liste an die Deklarationsreihenfolge im Header
• ändere Member-Deklarationen nicht, außer es wäre der einzige saubere Weg
• keine neue Initialisierungslogik
• keine inhaltliche Änderung

Priorität 4: Unused warnings strikt seiteneffektarm bereinigen

Ungenutzte Parameter

Insbesondere in:

• /repo/qt-migration-legatus/qt6-after/qt6-migrated-legatus/include/DDS/Generic/generic_base.h

Pflicht:

• Signaturen nicht ändern
• Parameter nicht entfernen
• Q_UNUSED(parameter) verwenden
• so platzieren, dass keinerlei Laufzeitverhalten geändert wird
• robust gegenüber späterer tatsächlicher Nutzung bleiben

Ungenutzte Funktion

Für:

• Z/src/NGLLogger/NGLLogger.cpp: findConfigFile(...)

gilt:

• nur entfernen, wenn zweifelsfrei lokal ungenutzt und ohne Seiteneffekt
• andernfalls risikoärmste lokale Lösung wählen
• keine unnötigen Sichtbarkeits- oder API-Änderungen

Arbeitsweise

Arbeite autonom bis zum Ende:

1. Ursachenanalyse der gemeldeten warnings und des Include-Pfad-Fehlers
2. minimal nötige Änderungen
3. Reconfigure
4. Rebuild
5. Warning-Review
6. Docker-Validierung
7. knapper Abschlussbericht

Docker ist Pflicht

Nutze ausschließlich dieses Dockerfile als autoritativ:

• /repo/app/Dockerfile

Repo im Container als:

• /repo

Docker-Anforderungen

Im Container verfügbar machen:

• Repository root auf /repo
• /repo/external
• /repo/external/rti_connext_dds-7.7.0
• ./rti_license.dat read-only gemountet

Falls RTI-/Lizenz-Umgebungsvariablen nötig sind:

• minimal
• explizit
• keine impliziten Host-Annahmen

Validierung

Mindestens validieren:

1. regulärer Konfigurations-/Buildlauf

Bevorzugt mit sauberem Build-Verzeichnis, z. B.:

cmake -S /repo/qt-migration-legatus/qt6-after/qt6-migrated-legatus \
      -B /repo/build-warning-cleanup \
      -G Ninja \
      -DCMAKE_BUILD_TYPE=Debug
cmake --build /repo/build-warning-cleanup --parallel
ctest --test-dir /repo/build-warning-cleanup --output-on-failure

2. Docker-validierter Lauf

Baue und teste im Container mit demselben Repo-Mount-Prinzip.

Wenn es Build-Optionen wie BUILD_RTI=ON/OFF gibt und sie für den Warning-Pfad relevant sind, prüfe mindestens die Variante, die den gemeldeten Warning-Kontext reproduziert.
Wenn ohne Mehrkosten möglich, prüfe zusätzlich beide Varianten.

Strikte Erfolgsdefinition

Nur als erfolgreich melden, wenn alle folgenden Punkte erfüllt sind:

• fehlerhafter Include-/CMake-Pfad ist an der Ursache korrigiert
• gemeldete deprecated warnings sind lokal und risikominimal bereinigt, soweit im Scope möglich
• reorder warnings sind bereinigt
• unused parameter warnings sind seiteneffektarm via Q_UNUSED(...) oder gleichwertig bereinigt
• Build bleibt erfolgreich
• Docker-Validierung wurde ausgeführt
• keine funktionalen Änderungen eingeführt

Wenn ein Punkt nicht sauber lösbar ist

Dann:

• keine riskante Änderung erzwingen
• keine globale Warning-Unterdrückung einführen
• keine Scheinerfolge melden
• den Punkt als bewusst offen berichten, mit präziser Begründung

Abschlussbericht

Berichte nur das Wesentliche:

• bereinigt oder teilweise bereinigt
• Root Cause des Include-/CMake-Pfad-Fehlers
• ob Docker-Validierung erfolgreich war
• exakte Docker-Kommandos
• exakte Build-Kommandos
• geänderte Dateien
• beseitigte Warnings
• bewusst nicht beseitigte Warnings mit Begründung
• Projektfehler vs. Umgebungsfehler
• Restrisiken