- Removes Grantlee5 from build pipeline

- Moves prompts to another side

Entire-Checkpoint: 01M1PYACGS4RVW2T93Z7WCQH2X

.github/prompts/codegen-grantlee5-migration-to-ktexttemplate.prompt.md

@@ -1,179 +0,0 @@
-Du arbeitest in einem bestehenden Legacy-Repository ./qt-migration-legatus/qt5-before/qt5-legatus-legacy und sollst eine risikoarme Migration des Codegenerators vorbereiten und umsetzen.
-
-## Ziel
-Das Projekt verwendet aktuell ein eigenes Codegen-Tool auf Basis von Grantlee5, um aus Service-XML verschiedene Artefakte zu erzeugen, darunter:
-- `.idl`
-- `.h`
-- `.cpp`
-- `.sql`
-- kopierte `.xml`
-
-Das Legacy-Projekt basiert auf Qt5.
-Das Ziel ist Qt6.
-Grantlee5 soll durch KDE KTextTemplate ersetzt werden.
-
-Du sollst den bestehenden Generator analysieren, einen minimal-invasiven Migrationspfad entwerfen und den Generator so portieren oder neu implementieren, dass er unter Qt6 mit KTextTemplate funktioniert, ohne die bestehende Build-Integration unnötig zu brechen.
-
-## Wichtiger Kontext
-Aus `MacroCodeGenIdl.cmake` geht hervor:
-- Es gibt zentrale Codegen-Actions wie:
-  - `DDS_TOPICS`
-  - `DATABASE`
-  - `DATABASE_SERVER`
-  - `SQL`
-  - `dao`
-- Aus XML werden je nach Action mehrere Ausgabedateien erzeugt.
-- Die CMake-Makros erwarten bestimmte Dateinamen und Ausgabepfade.
-- Templates liegen unter `Lts/Common/CodeGen/*.grantlee`.
-- `CODEGEN_TOPIC_TYPEDEFS(...)` verwendet separat ein Python-Skript (`codegen_simple.py`).
-- Die `.idl`-Dateien sind hier generierte Textartefakte; sie sind nicht automatisch als C++ zu behandeln.
-- C++-Header/Implementierungen, SQL und XML müssen im Generator als unterschiedliche Artefakttypen sauber behandelt werden.
-
-## Deine Aufgaben
-
-### 1) Bestehendes System analysieren
-Untersuche zuerst vollständig:
-- das aktuelle `codegen`-Tool
-- alle Aufrufstellen der Codegen-Actions
-- alle `*.grantlee`-Templates
-- XML-Parsing und Context-Aufbau
-- eventuelle benutzerdefinierte Grantlee-Filter, Tags, Helper, Loader oder Include-Mechanismen
-- die CMake-Integration rund um `MacroCodeGenIdl.cmake`
-
-Suche insbesondere nach:
-- `codegen`
-- `Grantlee`
-- `*.grantlee`
-- `DDS_TOPICS`
-- `DATABASE`
-- `DATABASE_SERVER`
-- `dao`
-- `SQL`
-- `codegen_simple.py`
-
-### 2) Zielarchitektur ableiten
-Leite auf Basis des Ist-Zustands eine Zielarchitektur ab für einen Qt6-basierten Generator mit KTextTemplate:
-- Ein-/Ausgabe-Modell
-- Zuordnung Action → Template(s) → Output-Dateien
-- XML → internes Datenmodell → Template-Context
-- Include-/Partial-Strategie
-- Fehlerbehandlung
-- deterministische Dateigenerierung
-- Encoding/Newline-Verhalten
-- Logging/Diagnostik bei Template-Fehlern
-
-### 3) Migration implementieren
-Setze die Migration minimal-invasiv um:
-- Qt6 statt Qt5
-- KTextTemplate statt Grantlee5
-- Bestehende Action-Namen und CMake-Aufrufmuster möglichst beibehalten
-- Bestehende Dateinamen und Output-Orte beibehalten
-- bestehende Template-Logik so weit wie möglich kompatibel halten
-
-Wenn direkte Kompatibilität nicht möglich ist:
-- implementiere eine dünne Adapter-/Kompatibilitätsschicht
-- oder migriere betroffene Templates kontrolliert und dokumentiert
-
-### 4) Build-System anpassen
-Passe CMake so an, dass:
-- der neue Generator im Qt6-Setup gebaut wird
-- die bestehenden Makros nach Möglichkeit weiter funktionieren
-- Incremental Builds nicht unnötig verschlechtert werden
-- Abhängigkeiten auf Templates und XML sauber erhalten bleiben
-
-### 5) Dokumentation ergänzen
-Erstelle Migrationsnotizen in Markdown:
-- bisherige Architektur
-- neue Architektur
-- Unterschiede Grantlee5 vs. KTextTemplate
-- notwendige Template-Anpassungen
-- bekannte Inkompatibilitäten
-- offene Risiken
-- Follow-up-Empfehlungen
-
-## Harte Randbedingungen
-- Keine unnötige Komplett-Neuschreibung.
-- Keine großflächigen Refactorings außerhalb des Codegen-Bereichs.
-- Keine Änderung der fachlichen XML-Semantik ohne klare Notwendigkeit.
-- Keine Änderung der erwarteten Output-Dateinamen ohne sehr gute Begründung.
-- Keine Änderung der öffentlichen CMake-Makro-Schnittstellen, wenn vermeidbar.
-- Python-basierten Teil (`codegen_simple.py`) nur dann anfassen, wenn er für Qt6-/Build-Kompatibilität relevant ist.
-
-## Erwartetes Vorgehen
-1. Zuerst analysieren, nicht blind umschreiben.
-2. Dann eine kurze Migrationsstrategie formulieren.
-3. Danach gezielte Codeänderungen durchführen.
-4. Änderungen klein und reviewbar halten.
-5. Wenn möglich vorhandene Tests/Build-Ziele nutzen oder ergänzen.
-6. Falls keine Tests existieren, mindestens Plausibilitätschecks für die Generierung einbauen.
-
-## Explizit zu prüfende Risiken
-Prüfe und dokumentiere ausdrücklich:
-- benutzerdefinierte Grantlee-Filter/Tags
-- Unterschiede bei Schleifen, Includes, Escaping und Kontextauflösung
-- Mehrfachgenerierung pro Action
-- Pfad- und Dateinamenskonventionen
-- Reihenfolge/Stabilität generierter Inhalte
-- UTF-8 / Zeilenenden
-- Verhalten bei fehlenden XML-Feldern
-- Fehlerdiagnose bei Template-Rendering-Problemen
-- CMake-Dependencies und Rebuild-Verhalten
-
-## Akzeptanzkriterien
-Die Aufgabe ist erst dann fertig, wenn mindestens Folgendes erfüllt ist:
-
-1. Ein Qt6-basierter Generator existiert oder der alte Generator ist erfolgreich auf Qt6 portiert.
-2. Grantlee5-Abhängigkeit ist im migrierten Pfad entfernt oder isoliert ersetzt.
-3. KTextTemplate wird für das Rendering verwendet.
-4. Die bisherigen zentralen Actions sind weiterhin abbildbar:
-   - `DDS_TOPICS`
-   - `DATABASE`
-   - `DATABASE_SERVER`
-   - `SQL`
-   - `dao`
-5. Die generierten Output-Dateien bleiben in Namen und Verzeichnisstruktur kompatibel, soweit technisch möglich.
-6. Die CMake-Integration funktioniert weiterhin mit den vorhandenen Makros oder mit minimalen kompatiblen Anpassungen.
-7. Die Migration ist dokumentiert.
-8. Bekannte Inkompatibilitäten und Restarbeiten sind klar benannt.
-
-## Definition of Done
-Am Ende liefere bitte:
-
-1. **Kurze Architekturzusammenfassung**
-   - Alt
-   - Neu
-   - wichtigste Unterschiede
-
-2. **Umgesetzte Migrationsentscheidungen**
-   - warum KTextTemplate so eingebunden wurde
-   - ob Adapter oder direkte Template-Migration gewählt wurde
-   - warum
-
-3. **Liste aller geänderten Dateien**
-
-4. **Konkrete Codeänderungen**
-   - inklusive CMake-Anpassungen
-   - Generator-Code
-   - Template-Anpassungen
-   - Doku
-
-5. **Validierung**
-   - was gebaut/getestet wurde
-   - was nur statisch geprüft wurde
-   - was noch offen ist
-
-6. **Offene Risiken / Follow-ups**
-
-## Bevorzugte Ergebnisqualität
-Bevorzuge eine inkrementelle, robuste Migration über eine elegante, aber riskante Neuentwicklung.
-Wenn mehrere Wege möglich sind, entscheide dich für den mit:
-- geringstem Integrationsrisiko
-- geringster Build-Störung
-- bester Nachvollziehbarkeit im Review
-
-Wenn Annahmen notwendig sind:
-- triff sie explizit,
-- dokumentiere sie,
-- und halte Änderungen reversibel.
-
-Bitte arbeite repository-basiert und leite Entscheidungen aus dem tatsächlich vorhandenen Code ab, nicht aus allgemeinen Annahmen über Grantlee oder KTextTemplate.

.github/prompts/combined-migration-compact.prompt.md

@@ -1,167 +0,0 @@
-# GitHub Copilot Instructions: Qt5/C++11 to Qt6/C++17 Migration
-
-## Mission
-Migrate the legacy Qt5/C++11 desktop application to Qt6/C++17, preserve behavior unless change is strictly required, and validate the result completely in the repository’s Docker-based CI workflow.
-
-## Operating Mode
-- Work autonomously from analysis through validation.
-- Do not stop after editing code.
-- Continue until configure, build, tests, and policy checks have been attempted in Docker.
-- Do not ask for confirmation during normal implementation.
-- Stop early only if required source material is missing, the task is impossible, or a destructive action would be required.
-
-## Boundaries
-- Read the legacy project from `./qt-migration-legatus/qt5-before/qt5-legatus-legacy`.
-- Write the migrated project to `./qt-migration-legatus/qt6-after/qt6-migrated-legatus`.
-- Do not modify the legacy source tree in place.
-- Limit changes to the target tree and only the CI/build/test files needed to support migration and validation.
-
-## Main Migration Targets
-- Upgrade Qt5 to Qt6.
-- Upgrade C++11/14/17 code to C++17.
-- Keep Qt Core, Gui, and Widgets explicitly linked.
-- Replace `QRegExp` with `QRegularExpression`.
-- Replace `QDesktopWidget` and `QApplication::desktop()` with `QScreen`-based Qt6 APIs.
-- Remove legacy `QTextCodec` usage and adopt Qt6-safe text handling.
-- Replace old `SIGNAL`/`SLOT` syntax with function-pointer connect syntax.
-- Replace `0`/`NULL` pointer literals with `nullptr`.
-- Preserve `.ui` and `.qrc` integration.
-- Preserve behavior unless Qt6 compatibility requires adaptation.
-
-## C++17 Modernization Rules
-- Preserve semantics first; modernize second.
-- Use `auto` when the type is obvious; avoid it when it hides important type information.
-- Prefer structured bindings where clearer.
-- Replace raw owning pointers/manual `delete` with RAII, usually `std::unique_ptr`.
-- Use `std::make_unique` / `std::make_shared`; use `std::shared_ptr` only for real shared ownership.
-- Use `std::string_view` only when lifetime safety is clear.
-- Prefer `std::span` for non-owning contiguous data; use `std::mdspan` only when multidimensional access clearly benefits.
-- Prefer `.contains()` over `find(...) != end()` where available.
-- Prefer algorithms and ranges over manual loops when readability improves.
-- Use `[[nodiscard]]` when ignoring a result is likely a bug.
-- Prefer early returns over deeply nested control flow.
-- Use `std::optional` monadic operations (`and_then`, `transform`, `or_else`) when clearer.
-- Prefer `constexpr`, `if constexpr`, concepts, and `requires` over legacy `std::enable_if`/SFINAE where practical.
-- Add `noexcept`, `override`, `final`, `= default`, and `= delete` where correct and useful.
-- Prefer `enum class` over unscoped enums where practical.
-- Prefer `std::print` / `std::println` when supported by the toolchain.
-- Prefer typed `std::chrono` durations and `std::jthread` where appropriate.
-
-## Safety Rules
-- Do not change business logic unless explicitly requested or required for Qt6 compatibility.
-- Do not introduce unsupported Qt6/C++17 features.
-- Do not silently change ABI, ownership, lifetime, exception behavior, performance, UI behavior, or event ordering.
-- Do not worsen readability for the sake of modernization.
-- Do not refactor code.
-- Avoid dangling references, dangling `std::string_view`, and ownership ambiguity.
-- Keep includes minimal and preserve repository-local formatting/style.
-- no code cleanup
-- no renaming
-- no extraction of functions/classes
-- no restructuring of logic
-- no stylistic rewrites
-- no dependency modernization
-- no opportunistic improvements
-- no behavior changes beyond path/build necessity
-
-## Tests
-- For every code change inside a method, add at least three tests covering the changed behavior.
-- Place generated tests in `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/tests`.
-- Use policy-compatible test filenames such as:
-  - `test_<name>.cpp`
-  - `<name>_test.cpp`
-  - `<name>test.cpp`
-  - `<name>gtest.cpp`
-  as searched for in `./qt-migration-legatus/ci/check_pr_policies.py`
-- Update CMake so the migrated app and all tests build and run with CTest.
-- Ensure all tests are registered with CTest.
-
-## Docker-First Validation
-Use `lifemaps/ci-cpp:latest` as the authoritative environment. Do not substitute host tools for missing container tools. Treat `./qt-migration-legatus/ci/Dockerfile.ci` as the source of truth for CI dependencies.
-
-### Required validation sequence
-1. Configure in Docker
-2. Build in Docker
-3. Run tests in Docker
-4. If tests pass, run `python3 ci/check_pr_policies.py` in Docker
-
-### Recommended commands
-- Configure:
-  `cmake -S ./qt-migration-legatus/qt6-after/qt6-migrated-legatus -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug`
-- Build:
-  `cmake --build build --parallel`
-- Test:
-  `ctest --test-dir build --output-on-failure`
-- Policy:
-  `python3 ./qt-migration-legatus/ci/check_pr_policies.py`
-
-Adapt paths/flags only if repository inspection proves they must differ.
-
-## Missing-Tool Remediation
-If Docker validation fails because a required tool/package is missing:
-- identify the exact missing dependency
-- update `./qt-migration-legatus/ci/Dockerfile.ci` minimally
-- rebuild `lifemaps/ci-cpp:latest`
-- rerun the full validation sequence
-
-Continue until:
-- validation succeeds, or
-- the next blocker is a genuine project/code issue
-
-## Failure Classification
-Environment failures:
-- command not found
-- missing compiler/toolchain utility
-- missing Qt dev package
-- missing CMake/Ninja/CTest support tool
-- missing dependency required by `./qt-migration-legatus/ci/check_pr_policies.py`
-
-Project failures:
-- compile errors
-- linker errors
-- failing tests
-- formatting/policy failures caused by migration changes
-
-## Policy Awareness
-- `./qt-migration-legatus/ci/check_pr_policies.py` checks formatting for changed C/C++ files, expects related tests, and verifies commit-signature conditions in its diff range.
-- Ensure Docker validation runs with mounted workspace and git metadata available.
-- Do not claim success unless the policy script passes.
-
-## Execution Plan
-1. Inspect `./qt-migration-legatus/` and the target tree.
-2. Identify Qt5 and legacy C++ constructs to migrate.
-3. Migrate incrementally in `qt6-after/qt6-migrated-legatus`.
-4. Add/update tests with each behavior-relevant change.
-5. Update CMake/test registration.
-6. Validate in Docker.
-7. If missing dependencies are found, update `./qt-migration-legatus/ci/Dockerfile.ci`, rebuild, and rerun.
-8. Repeat until success or a real project defect remains.
-
-## Reporting
-Group change explanations by:
-- CMake / build-system migration
-- Qt API replacements
-- C++ modernization
-- UI/resource preservation
-- tests added
-- `./qt-migration-legatus/ci/Dockerfile.ci` / container updates
-
-Also provide a concise changed-files summary.
-
-## Completion Criteria
-Success requires:
-- migrated project exists under `./qt-migration-legatus/qt6-after/qt6-migrated-legatus`
-- configure succeeds in Docker
-- build succeeds in Docker
-- tests succeed in Docker
-- `python3 ci/check_pr_policies.py` succeeds in Docker after tests pass
-
-## Final Response
-- State whether migration is fully validated or which blocker remains.
-- List the exact Docker commands used for image rebuild, configure, build, test, and policy check.
-- For every failed attempt, include:
-  - exact command
-  - key error
-  - environment vs project classification
-  - fix applied
-- End with a short summary of any remaining blocker.

.github/prompts/commit-policy.prompt.md

@@ -1,94 +0,0 @@
-Task: Work in this workspace with multiple Git repositories. Before making any changes, determine the correct target repository for each file based strictly on its path, then perform changes, validation, and commits only in the matching repository.
-
-Repository layout detected under `./`:
-- `./.git`
-- `./qt-migration-legatus/.git`
-- `./qt-migration-legatus/qt5-before/qt5-legatus-legacy/.git`
-- `./jenkins-ci-rme/.git`
-- `./rpmbuild/.git`
-
-Critical constraint:
-There are multiple Git repositories in this workspace. You must first determine for each planned change which repository root it belongs to, based strictly on the file path. Each change must be made and committed in the matching Git repository only.
-
-Repository mapping in this workspace:
-- files under `./qt-migration-legatus/` -> commit only in `./qt-migration-legatus`
-- files under `./jenkins-ci-rme/` -> commit only in `./jenkins-ci-rme`
-- files under `./rpmbuild/` -> commit only in `./rpmbuild`
-- files at workspace root `./...` not inside one of the sub-repositories -> commit only in `./`
-
-Rules derived from this:
-- Never commit a file from one repository into another repository.
-- Never use `./` as the commit target for files that belong to `./qt-migration-legatus`, `./qt-migration-legatus/qt5-before/qt5-legatus-legacy/`, `./jenkins-ci-rme`, or `./rpmbuild`.
-- Never use a sub-repository as the commit target for files that belong to workspace root `./`.
-- Before changing any file, determine its owning repository from its path and show that mapping explicitly.
-- If a planned change spans multiple repositories, handle each repository separately.
-- Create separate status checks, validation runs, and commits per repository.
-- If repository ownership for any file is ambiguous, stop and report it instead of guessing.
-
-Signed commit requirement:
-- Only signed commits are allowed.
-- Do not create unsigned commits.
-- Before committing in any repository, verify that commit signing is configured and usable for that repository context.
-- Check at minimum:
-  - `git config --global --list`
-  - `cd <repo> && git config --get commit.gpgsign`
-  - `cd <repo> && git config --get user.signingkey`
- - If repository-local signing settings exist, inspect and respect them as well.
- - If signing is required but not configured or not functional, stop and report the exact reason.
- - When committing, create a signed commit only.
- - After committing, show evidence that the created commit is signed by running:
-   - `cd <repo> && git log -1 --show-signature`
-        
-Required checks before making any changes:
-1. `ssh -T devel`
-2. `git config --global --list`
-3. `find . -type d -name .git -prune | sort`
-
-Then, for each repository that will actually be modified, run these checks in that repository before making changes:
-1. `cd <repo> && pwd`
-2. `cd <repo> && git rev-parse --is-inside-work-tree`
-3. `cd <repo> && git rev-parse --show-toplevel`
-4. `cd <repo> && git remote -v`
-5. `cd <repo> && git branch --show-current`
-6. `cd <repo> && git status --short`
-7. `cd <repo> && git config --get remote.origin.url`
-
-Repository-selection procedure:
-- List every file you plan to modify.
-- For each file, map it to exactly one repository root using the path rules above.
-- Group planned changes by repository before making any edits.
-- Show the grouping explicitly before changing files.
-
-Hard rules:
-- Do not guess. Do not silently switch repositories.
-- Do not modify files before their owning repository has been identified and checked.
-- If any repository check fails: stop for that repository and report the exact reason.
-- If a file would be committed from the wrong repository: stop.
-- If `git rev-parse --show-toplevel` does not match the expected repository root for a file: stop.
-- If there is no sensible remote or no plausible write access for a repository: stop for that repository.
-- Do not combine changes from different repositories into one commit.
-- Do not skip validation for any repository being changed.
-
-Validation:
-- Run all relevant tests for the changes in each affected repository.
-- Run all locally checkable check-in policies for each affected repository.
-- Keep validation scoped to the repository being changed.
-- If tests or policies fail, or cannot be executed, do not commit in that repository.
-
-Automatic commit:
-- If all checks, tests, and check-in policies pass for a repository, commit automatically in that repository.
-- Before committing, show: `cd <repo> && git status --short`
-- After committing, output:
-  - `cd <repo> && git rev-parse HEAD`
-  - current branch
-  - remote URL
-  - changed files
-
-Output format:
-- Show every global check command with raw output.
-- Show the discovered `.git` directories.
-- Show the list of planned changed files and the repository mapping for each file.
-- Show all per-repository check commands with raw output.
-- Show all test and policy results per repository.
-- On failure in any repository: stop committing in that repository, do not guess, and report exact reasons.
-- On success: commit separately per repository and print commit hash, branch, remote, and changed files for each commit.

.github/prompts/continue-qt6-migration-after-resume-loop.prompt.md

@@ -1,64 +0,0 @@
-# Continue Qt6 migration after broken resume
-
-Setze die Qt6-Migration fort.
-
-## Kontext
-Die vorherige Copilot-CLI-Session wurde nach einem `pkill` resumed und ist in einer Endlosschleife hängen geblieben. Sie hat wiederholt nur den Arbeitsstand gelesen/zusammengefasst und nicht weiter implementiert. Dieses Verhalten darf sich nicht wiederholen.
-
-Ein partieller Zwischenstand ist in `./MIGRATION_STATUS.md` gesichert.
-
-Unter `./.github/prompts/` liegen bestehende Prompt-Dateien, die die ursprüngliche Migrationsaufgabe beschreiben. Diese Arbeit ist bereits in Bearbeitung und soll fortgesetzt, nicht neu aufgesetzt werden.
-
-## Verzeichnisrollen
-- `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/`
-  - primärer Arbeitsort
-  - hier werden die Migrationsergebnisse umgesetzt
-- `./qt-migration-legatus/qt5-before/qt5-legatus-legacy/`
-  - **read-only**
-  - nur als Referenz für Vergleich, Verhalten und Portierung nutzen
-  - **keine Änderungen**
-- `./external/`
-  - externe Abhängigkeiten
-  - nur anfassen, wenn es für einen echten Qt6-Build-/Compile-Blocker zwingend nötig ist
-
-## Strikte Arbeitsregeln
-1. `./MIGRATION_STATUS.md` genau einmal am Anfang lesen.
-2. Die Prompt-Dateien unter `./.github/prompts/` genau einmal als Kontext lesen.
-3. Danach den tatsächlichen Codezustand prüfen.
-4. Nicht in erneute Statusanalyse oder Wiederholungszusammenfassungen verfallen.
-5. Nicht mehrfach dieselben Statusdateien oder Prompts lesen.
-6. Der aktuelle Codezustand hat Vorrang vor älteren Notizen.
-7. Wenn Notizen und Code voneinander abweichen, dem Code folgen.
-8. `./MIGRATION_STATUS.md` nur am Ende aktualisieren.
-
-## Verpflichtende Arbeitsreihenfolge
-1. `./MIGRATION_STATUS.md` einmal lesen
-2. die vorhandenen Prompts einmal lesen
-3. den Ist-Zustand in `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/` prüfen
-4. die nächsten 1-3 konkreten Qt6-Migrationsprobleme identifizieren
-5. diese Probleme direkt im Code beheben
-6. bei Bedarf gezielt mit `./qt-migration-legatus/qt5-before/qt5-legatus-legacy/` vergleichen
-7. `./external/` nur bei echtem Blocker prüfen
-8. am Ende `./MIGRATION_STATUS.md` aktualisieren
-
-## Was nicht passieren darf
-- keine Endlosschleife aus Lesen und Zusammenfassen
-- keine lange Bestandsaufnahme
-- kein reines Re-Planning ohne Codeänderungen
-- keine Änderungen im Read-only-Referenzbaum
-- keine unnötigen Änderungen unter `./external/`
-
-## Priorität
-1. Build-/Compile-Blocker im Zielcode beheben
-2. veraltete Qt5-APIs im Zielcode auf Qt6 umstellen
-3. Signal/Slot-, Header-, Modul- und CMake-Anpassungen umsetzen
-4. danach Statusdatei aktualisieren
-
-## Ausgabeformat
-Nach jeder relevanten Änderung kurz ausgeben:
-- Geändert:
-- Grund:
-- Nächster Schritt:
-
-## Ziel
-Nicht den Stand verwalten, sondern die Qt6-Migration konkret in `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/` weiter implementieren.

.github/prompts/legacyrti_to_rti77_migration_prompt.md

@@ -1,198 +0,0 @@
-You are working on a migration from RTI Connext 6 to RTI 7.7.
-
-IMPORTANT:
-Work in two strictly separated phases:
-1. Analysis
-2. Patching
-
-Do not modify files before you have completed the analysis and written down a migration classification.
-
-Your task is to compare:
-- step-1 Copilot-created fallback/reconstructed RTI-related files created while `BUILD_RTI=OFF`
-with
-- real RTI 7.7 generated DDS/RTI artifacts created while `BUILD_RTI=ON`
-
-Then update only the manually maintained / Copilot-created files so they correctly reflect the RTI 7.7 generated output.
-
-## Main Goal
-Make the codebase cleanly support the real RTI 7.7 generation in the `BUILD_RTI=ON` path, while preserving `BUILD_RTI=OFF` fallbacks only where truly necessary.
-
-## Hard Rules
-- Treat RTI 7.7 generated files as source of truth for `BUILD_RTI=ON`.
-- Do not edit generated RTI files unless absolutely unavoidable and explicitly justified.
-- Prefer adapting manual files, wrappers, compatibility headers, includes, and guards.
-- Remove or isolate reconstructed definitions if they duplicate RTI 7.7 generated types.
-- Keep fallback logic only for `BUILD_RTI=OFF`.
-- Do not perform unrelated refactoring.
-- Do not guess generated API shapes; inspect actual generated files.
-
-## Required Workflow
-
-# Phase 1 — Analysis only
-
-## A. Identify migration-related files
-Find:
-- reconstructed RTI headers
-- compiler guards added in step 1
-- fallback DDS/RTI type definitions
-- wrappers/adapters around DDS/RTI types
-- include indirection layers
-- files conditionally compiled for `BUILD_RTI`
-
-Use repository inspection commands such as:
-- `git status`
-- `git diff --name-only`
-- `git log --stat`
-- `rg -n "BUILD_RTI|RTI|DDS|Connext|ifdef|ifndef|pragma once" .`
-- `rg -n "#if.*BUILD_RTI|#ifdef.*BUILD_RTI|#ifndef.*BUILD_RTI" .`
-- `find . -iname "*dds*" -o -iname "*rti*"`
-
-If available, inspect step-1-related changes via:
-- `git diff <baseline>...HEAD`
-- `git log --grep="RTI\|DDS\|BUILD_RTI"`
-- targeted diffs for migration commits
-
-## B. Identify real RTI 7.7 generated artifacts
-Locate the generated files produced with `BUILD_RTI=ON`.
-
-Inspect:
-- build directories
-- generated include folders
-- CMake-generated outputs
-- RTI codegen output directories
-- custom generation scripts
-
-Use commands such as:
-- `find build -type f | rg "dds|rti|idl|type|Support|Plugin"`
-- `find . -type f | rg "Support\.h$|Plugin\.h$|Plugin\.cxx$|\.idl|\.xml"`
-- `rg -n "rtiddsgen|connext|idl" CMakeLists.txt cmake/ .`
-- `rg -n "GENERATED|AUTO_GENERATED|DO NOT EDIT" .`
-
-## C. Compare reconstructed vs generated artifacts
-For each reconstructed/manual RTI-related file, compare against the generated RTI 7.7 counterpart.
-
-Check:
-- file names
-- include paths
-- header guards / `#pragma once`
-- macros
-- namespaces
-- class / struct / enum / typedef / alias definitions
-- forward declarations
-- helper APIs / traits / adapters
-- symbol names
-- expected include order
-- conditional compilation behavior under `BUILD_RTI=ON` vs `BUILD_RTI=OFF`
-
-Use comparison commands where helpful:
-- `diff -u <manual-file> <generated-file>`
-- `git diff --no-index <manual-file> <generated-file>`
-- `rg -n "<TypeName>" .`
-- `rg -n "#include <...>|#include \"...\"" <relevant paths>`
-
-## D. Trace usage
-Find all places that still reference the reconstructed step-1 artifacts.
-
-Use:
-- `rg -n "<header-name>|<type-name>|<guard-name>" .`
-- `rg -n "#include .*<reconstructed-header>|#include .*\"<reconstructed-header>\"" .`
-
-Determine:
-- which files still depend on old reconstructed headers
-- which guards still activate old fallback definitions
-- which paths could conflict with generated RTI 7.7 types
-
-## E. Build-path analysis
-Inspect build logic and conditional compilation paths.
-
-Check:
-- `CMakeLists.txt`
-- `*.cmake`
-- generation scripts
-- target include directories
-- compile definitions
-- `compile_commands.json` if present
-
-Use:
-- `rg -n "BUILD_RTI|target_include_directories|target_compile_definitions|add_definitions|include_directories" .`
-- `find build -name compile_commands.json`
-- inspect compile commands for affected targets
-
-Goal:
-Determine exactly how `BUILD_RTI=ON` and `BUILD_RTI=OFF` select different headers and definitions.
-
-## F. Produce migration classification
-Before patching, classify findings into:
-- **REMOVE** = obsolete step-1 artifact replaced by RTI 7.7 generation
-- **KEEP_OFF_ONLY** = still needed only when `BUILD_RTI=OFF`
-- **PATCH** = manual file must be changed
-- **VERIFY** = uncertain; validate before touching
-
-Do not patch before this list is explicit.
-
-# Phase 2 — Patching only after analysis
-
-## Allowed patch types
-- replace old includes with RTI 7.7 generated includes
-- restrict fallback type definitions to `BUILD_RTI=OFF`
-- tighten or invert guards so `BUILD_RTI=ON` always prefers generated output
-- remove duplicate type declarations
-- update wrappers/adapters to use actual RTI 7.7 generated types
-- isolate obsolete reconstructed headers so they no longer affect `BUILD_RTI=ON`
-- adjust build include paths only if necessary to stop wrong header selection
-
-## Patch objectives
-- `BUILD_RTI=ON` uses actual RTI 7.7 generated headers/types
-- no old fallback header shadows generated output
-- no duplicate definitions remain
-- no stale RTI Connext 6 assumptions remain where RTI 7.7 differs
-- `BUILD_RTI=OFF` stays supported only where explicitly needed
-
-## Explicitly avoid
-- editing generated files first
-- broad renames
-- non-migration-related cleanup
-- speculative API rewrites
-- silently dropping `BUILD_RTI=OFF` support
-
-# Verification after patching
-
-Run or propose the most relevant checks:
-- `rg -n "<obsolete-header-or-type>" .`
-- `rg -n "redefinition|redeclaration" <build logs if available>`
-- project build with `BUILD_RTI=ON`
-- if supported, project build with `BUILD_RTI=OFF`
-- inspect compiler errors for include-order or duplicate-type issues
-
-If build commands are available, use them. Typical examples:
-- `cmake -S . -B build -DBUILD_RTI=ON`
-- `cmake --build build -j`
-- `cmake -S . -B build-off -DBUILD_RTI=OFF`
-- `cmake --build build-off -j`
-
-If tests exist and are relevant, run targeted tests only after the migration patches are in place.
-
-## Output Format
-First output:
-
-1. **Analysis summary**
-2. **Migration classification**
-   - REMOVE
-   - KEEP_OFF_ONLY
-   - PATCH
-   - VERIFY
-
-Then patch files only after the analysis is complete.
-
-For every changed file, report and write to ./RTI_MIGRATION_STATUS.md:
-1. file path
-2. category
-3. problem found
-4. exact change made
-5. rationale
-6. follow-up validation / residual risk
-
-When uncertain, prefer minimal safe changes and document the uncertainty.
-
-Start now with Phase 1 only.
-Do not patch anything until the analysis and classification are complete.