# 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.:

```bash
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