qt6-migration-pipeline/prompts/release-qt6-migrated-modules-first-release.prompt.md

Copilot CLI Prompt: Erstes Release ausgewählter Qt6-Migrationsmodule

Dieser Prompt ist verbindlicher Task-Kontext. Arbeite autonom, minimal, reproduzierbar und ohne opportunistische Änderungen.

Required base prompt

Vor jeder Änderung lesen und anwenden:

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

Wenn der Commit-/Repository-Prompt strenger ist, gilt er zusätzlich. Dieser Prompt konkretisiert nur das Release-Ziel und den Release-Scope.

Ziel

Erstelle das erste Release von ausgewählten Modulen aus dem bereits weit fortgeschritten nach Qt6 migrierten Projekt.

Das Release ist kein erneuter Qt5-zu-Qt6-Migrationslauf. Migriere, repariere oder ergänze Code nur, wenn es direkt erforderlich ist, damit die explizit freigegebenen Module im Release sauber konfigurieren, bauen, testen und als RPM über die Pipeline erzeugt werden.

Arbeite mit folgenden Mengen:

• R: die vollständige, vor Änderungen aus den realen Projektdateien ermittelte Menge aller Module im Repository ./qt-migration-legatus/qt6-after/qt6-migrated-legatus.
• M: die explizit für dieses Release freigegebenen Module: TetraIF, Z und Lts/Common.
• S: das minimale Release-Modulset, definiert als S = M + zwingend notwendige direkte und transitive Abhängigkeiten aus R.

Ermittle R vollständig und liste R, M, S sowie R \ S (ausgeschlossene Module) in den Scope-Audits und im finalen Bericht auf. Die unten freigegebenen Pfade begrenzen die konkreten Release-Dateien; sie erweitern M nicht. Build-, Test-, CI-, Installations- und Packaging-Regeln dürfen ausschließlich Module aus S einbeziehen. Nicht-Moduldateien wie Build-Hilfen, Tests, Pipeline- und Packaging-Konfigurationen sind nur insoweit zulässig, wie sie genau diesen Release-Scope umsetzen.

Zielbranch

Arbeite auf dem bestehenden Zielbranch:

• story/release-at-16-oct-2026

Wenn der aktuelle Branch bereits korrekt ist, bleibe dort. Wenn nicht, wechsle minimal auf diesen Branch. Erstelle keine neuen Branches, außer es ist technisch unumgänglich und klar begründet.

Repository- und Submodule-Kontext

Die Workspace-Struktur enthält mehrere Repositories/Submodule. Bestimme für jede Datei anhand ihres Pfads das zuständige Repository und committe Änderungen nur dort.

Erwartete Submodule:

./gitmodules
[submodule "qt-migration-legatus"]
        path = qt-migration-legatus
        url = git@devel:lifemaps/qt-migration-legatus.git
        branch = story/release-at-16-oct-2026
[submodule "rpmbuild"]
        path = rpmbuild
        url = git@devel:lifemaps/rpmbuild.git
        branch = story/release-at-16-oct-2026
[submodule "jenkins-ci-rme"]
        path = jenkins-ci-rme
        url = git@devel:lifemaps/rme-jenkins.git
        branch = story/release-at-16-oct-2026

./qt-migration-legatus/.gitmodules
[submodule "qt5-before/qt5-legatus-legacy"]
        path = qt5-before/qt5-legatus-legacy
        url = git@devel:lifemaps/qt5-legatus-legacy.git
        branch = story/qt6-migration

Alle Release-relevanten Repositories/Submodule müssen auf story/release-at-16-oct-2026 stehen, außer das Qt5-Legacy-Submodule ist nur als Vergleichsquelle erforderlich und laut .gitmodules auf story/qt6-migration gebunden.

Harte Release-Grenze

Im Release dürfen ausschließlich die unten explizit angegebenen Teile sowie nachweislich zwingend notwendige Abhängigkeiten gemäß S enthalten sein. S ist minimal zu halten: Eine Abhängigkeit gehört nur dazu, wenn reale Projektdateien belegen, dass ein Modul aus M sie direkt oder transitiv zum Konfigurieren, Bauen, Linken, Testen, Installieren oder Paketieren benötigt.

Nicht erlaubt:

• zusätzliche Module außerhalb von S, Verzeichnisse, Targets oder Tests außerhalb des Release-Scopes
• opportunistische Refactorings, Cleanups oder Modernisierungen
• entfernte oder nicht freigegebene Module wieder einzuführen
• nicht freigegebene Module zu bauen, testen, installieren oder paketieren
• Build- oder Testfehler durch Deaktivieren relevanter Targets zu verstecken
• Tests zu löschen, zu schwächen oder aus CTest zu entfernen, nur damit das Release grün wird
• generierte Artefakte einzuchecken
• Stub-, Dummy-, Mock- oder Placeholder-Dateien als Ersatz für echte Build-/Generator-Ausgaben zu erzeugen

Rate keine Abhängigkeiten. Leite sie aus realen Projektdateien ab, insbesondere aus CMakeLists.txt, target_link_libraries, add_subdirectory, add_test, Include-/Generator-Konfigurationen, CI- und Packaging-Skripten sowie Install-Regeln. Für jede Abhängigkeit aus S \ M dokumentiere das benötigte Modul, das sie benötigende Modul aus M oder bereits begründetem S, den konkreten Grund und eine konkrete Referenz (Dateipfad und relevantes Target/eintragende Regel). Kann die Notwendigkeit nicht belegt werden, nimm das Modul nicht in S auf; wenn dadurch das Release nicht eindeutig umsetzbar ist, stoppe und berichte den offenen Punkt.

Wenn eine nicht gelistete Datei oder Komponente technisch erforderlich ist, damit S gebaut, getestet oder paketiert werden kann, nimm nur das kleinste notwendige Element auf. Begründe jede solche Ausnahme einzeln im finalen Bericht. Eine solche Datei-Ausnahme erweitert nicht automatisch die Modulmenge S.

Release-Inhalt aus qt-migration-legatus

Aus:

• ./qt-migration-legatus/qt6-after/qt6-migrated-legatus

dürfen im Release nur diese Teile enthalten sein:

• ./TetraIF
• ./Z
• ./CMakeLists.txt
• ./cmake
• ./tests
• ./new_docker_build.sh
• ./specs
• ./Lts/Common
• ./include

Nach eingehender Analyse der Abhaengigkeiten, entferne alle nicht benötigten Dateien aus dem Release-Branch. Dateien außerhalb der oben ausdrücklich erlaubten Pfade dürfen nicht im Release-Pfad verbleiben, außer sie sind technisch zwingend für Build, Tests oder Paketierung der freigegebenen Module erforderlich. Nimm in diesem Fall nur die kleinste erforderliche Datei bzw. Komponente auf und begründe die Ausnahme einzeln im finalen Bericht.

Release-Inhalt aus qt6-migration-pipeline

Aus:

• ./qt6-migration-pipeline

dürfen im Release nur diese Teile enthalten sein:

• ./jenkins-ci-rme
• ./rpmbuild/make_rpm_ubuntu26.py

Nach eingehender Analyse der Abhaengigkeiten, entferne alle nicht benötigten Dateien aus dem Release-Branch. Dateien außerhalb der oben ausdrücklich erlaubten Pfade dürfen nicht im Release-Pfad verbleiben, außer sie sind technisch zwingend für Build, Tests oder Paketierung der freigegebenen Module erforderlich. Nimm in diesem Fall nur die kleinste erforderliche Datei bzw. Komponente auf und begründe die Ausnahme einzeln im finalen Bericht.

Die Jenkins-Pipeline muss die freigegebenen Module bauen, testen und RPMs erzeugen. Passe nur die hierfür erforderlichen Pipeline-/RPM-Dateien an.

Build- und Testautorität

Die freigegebenen Module müssen über dieses Skript bauen und die Tests ausfuehrbar sein:

• ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh

Passe ./new_docker_build.sh für das Release an. Entferne nicht benoetigte Teile aus dem Script.

Das Skript muss:

• ausschließlich Module aus S konfigurieren und bauen; keine Module aus R \ S als versteckte Abhängigkeit einbeziehen
• alle für S und seine Tests erforderlichen realen CMake-Targets bauen oder validieren
• CTest für die Release-relevanten Tests aus ./tests ausführen
• bei Build-, Link- oder Testfehlern fehlschlagen
• keine nicht freigegebenen Module bauen, testen, installieren oder paketieren
• keine host-lokalen Pfade oder Entwicklerannahmen verwenden
• im Docker-/CI-Kontext reproduzierbar laufen

Prüfe vor der Änderung des Skripts anhand der realen CMake-Abhängigkeiten, dass jeder Build-Schritt nur S umfasst. Dokumentiere jede zusätzliche Modulabhängigkeit in S \ M mit Grund, benötigendem Modul und konkreter Projektdatei-Referenz.

CTest-Umfang

Alle Tests aus:

• ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/tests

die die herausgegebenen Module betreffen, müssen im Release enthalten sein, bauen und erfolgreich durchlaufen.

Vorgehen:

1. Identifiziere alle CTest-Tests, die M oder eine nachgewiesene Abhängigkeit aus S \ M, specs, zentrale erforderliche cmake-Logik oder benötigte Forward Declarations betreffen.
2. Stelle sicher, dass alle Tests für M registriert sowie gebaut und ausgeführt werden; Tests für Module aus S \ M sind nur aufzunehmen, wenn sie eine nachgewiesene direkte Integrationsvoraussetzung sind.
3. Stelle sicher, dass die Release-relevanten Tests durch ./new_docker_build.sh gebaut und ausgeführt werden und dass Test-/CI-Regeln keine Module aus R \ S einbeziehen.
4. Lösche, schwäche oder ignoriere keine Tests für M, nur um Fehler zu verdecken oder ein grünes Ergebnis zu erzielen.
5. Tests für Module aus R \ S dürfen nicht Bestandteil des Release-Pfads sein. Jede begründete Ausnahme ist mit benötigendem Modul und konkreter Referenz zu dokumentieren.

Jenkins-/RPM-Anforderungen

Die Jenkins-Pipeline in ./jenkins-ci-rme/release-16-10-2026.sh muss für das Release:

• den Release-Scope verwenden
• in einem Dockerimage, das mit ./new_docker_build.sh --build-prebuilt-image --docker-image legatus-qt6:1.0 erzeugt wurde, für Build und Tests ausgefuehrt werden
• RPM-Erzeugung über ./rpmbuild/make_rpm_ubuntu26.py im Dockercontainer auslösen
• ausschließlich Module aus S bauen, testen und paketieren
• keine nicht freigegebenen Module, Artefakte oder Tests in RPMs aufnehmen
• reproduzierbare Ubuntu-26-RPMs erzeugen

Passe ./rpmbuild/make_rpm_ubuntu26.py nur soweit an, wie es für das Release-Paketieren der erlaubten Teile erforderlich ist. Prüfe CI-Schritte, Eingaben, Installations- und Packaging-Regeln ausdrücklich gegen S und bestätige, dass keine Module aus R \ S gebaut, getestet, installiert oder paketiert werden. Begründe jede erforderliche Abhängigkeit aus S \ M mit benötigendem Modul und konkreter Referenz.

Scope-Prüfungen vor Änderungen

Vor jeder Änderung:

1. Ermittle alle Git-Repositories und Submodule.
2. Prüfe Branch, Remote, Working Tree und Submodule-Status.
3. Ermittle und liste die vollständige Modulmenge R, das freigegebene Set M, das begründete minimale Set S und die ausgeschlossenen Module R \ S auf.
4. Leite jede Abhängigkeit für S \ M aus realen Projektdateien ab und dokumentiere benötigendes Modul, Grund und konkrete Referenz.
5. Liste jede geplante Dateiänderung, ordne sie exakt einem Repository zu und vergleiche geplante Dateien sowie enthaltene Module mit dem konkreten Release-Scope.
6. Stoppe, wenn Repository-Zuordnung, Branch, Remote oder Modul-/Abhängigkeitsscope nicht eindeutig sind.

Release-Scope-Audit

Führe vor Implementierung und vor Abschluss ein Scope-Audit durch:

• Liste R, M, S, alle Module aus R \ S und alle Verzeichnisse/Dateien, die im Release enthalten wären.
• Vor Implementierung: liste zusätzlich alle geplanten/geänderten Dateien mit ihrem Repository und begründe, wie sie dem Release von S dienen.
• Vergleiche enthaltene und geplante Inhalte gegen die konkreten erlaubten Release-Pfade und bestätige, dass keine Module außerhalb S enthalten sind.
• Entferne oder schließe nicht erlaubte Teile aus.
• Prüfe Build-, Test-, CI-, CMake-, Install- und Packaging-Regeln ausdrücklich gegen S; insbesondere dürfen keine Module aus R \ S gebaut, getestet, installiert oder paketiert werden.
• Prüfe Tests für M auf Vollständigkeit und darauf, dass sie weder gelöscht noch abgeschwächt oder ignoriert wurden.
• Prüfe Jenkins und RPM-Spezifikation/-Script auf nicht erlaubte Module und Artefakte.
• Abschluss-Audit: wiederhole die Bestandsaufnahme von R, M, S, R \ S sowie den tatsächlichen enthaltenen/geänderten Dateien und bestätige Abweichungen oder korrigiere sie vor Abschluss.

Wenn ein nicht erlaubter Teil referenziert wird, entferne oder korrigiere die Referenz. Eine Abhängigkeit darf nur als Ausnahme in S verbleiben, wenn ihre direkte oder transitive Notwendigkeit mit einer konkreten Projektdatei belegt und dokumentiert ist.

CMake-/Target-Regeln

Für die erlaubten Module:

• nimm reale CMake-Targets unter ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF, ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/Z und ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/Lts/Common aus ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh
• erfinde keine Targets
• füge keine Targets hinzu, die nicht existieren
• prüfe alle add_subdirectory-, target_link_libraries- und sonstigen Target-Abhängigkeiten anhand der tatsächlichen CMakeLists.txt und ordne notwendige Module S zu; rate keine Abhängigkeiten
• registriere nur erforderliche Targets für S im Release-Build und dokumentiere jede Modulabhängigkeit aus S \ M mit Grund, benötigendem Modul und konkreter Referenz
• stelle sicher, dass Parent-CMakeLists.txt ausschließlich Module aus S aktiviert
• stelle sicher, dass Install-/Package-Regeln ausschließlich Module und Artefakte aus S aufnehmen
• prüfe zentrale cmake-Hilfen nur soweit, wie sie für die Release-Module erforderlich sind

Qt-/Generator-/Forward-Declaration-Regeln

Falls die Release-Module Qt-, RTI-, ndsgen-, KTextTemplate- oder andere Generator-Flows verwenden:

• bewahre echte Generator-Flows
• generiere in den Build-Tree
• konsumiere generierte Dateien aus dem Build-Tree
• committe keine generierten Dateien
• ersetze Generator-Ausgaben nicht durch handgeschriebene Stubs
• stelle Build-Reihenfolge und Include-Pfade korrekt her

Forward Declarations dürfen nur im Release sein, wenn sie direkt für Build oder Tests der freigegebenen Module erforderlich sind. Dokumentiere jede aufgenommene Forward-Declaration-Datei mit Grund.

Erlaubte Änderungen außerhalb der Modulverzeichnisse

Änderungen außerhalb der gelisteten Modulverzeichnisse sind nur erlaubt, wenn sie direkt für das Release erforderlich sind:

• Root-CMakeLists.txt
• zentrale Dateien unter ./cmake
• ./new_docker_build.sh
• Release-relevante Tests unter ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/tests
• ./specs
• ./jenkins-ci-rme
• ./rpmbuild/make_rpm_ubuntu26.py

Jede Änderung außerhalb der Modulverzeichnisse muss im finalen Bericht begründet werden. Die aufgeführten Build-, Test-, CI- und Packaging-Dateien dürfen nur den Scope S konfigurieren oder abbilden; sie sind keine pauschale Erlaubnis, weitere Module aus R in das Release aufzunehmen.

Validierung

Analysiere detailliert das Validierungsskript ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh. Validiere im Docker-/CI-Pfad. Verwende keine Host-Builds als Ersatz für Docker-Validierung.

Installiere fehlende Systempakete reproduzierbar über apt im Dockerimage; sie dürfen nicht host-lokal vorausgesetzt werden.

Mindestens ausführen, sofern die Pfade existieren:

cd ./qt-migration-legatus/qt6-after/qt6-migrated-legatus
./new_docker_build.sh

CTest muss als Teil dieser Validierung laufen. Falls new_docker_build.sh CTest noch nicht ausführt, passe es so an, dass die Release-relevanten Tests ausgeführt werden.

Zusätzlich Jenkins/RPM-Pfad prüfen:

• Pipeline-Konfiguration in ./jenkins-ci-rme/release-16-10-2026.sh
• RPM-Erzeugung mit ./rpmbuild/make_rpm_ubuntu26.py

Wenn eine Validierung wegen Umgebung, Zugang, Lizenz, Docker oder fehlender Infrastruktur nicht möglich ist, klassifiziere den Blocker exakt und berichte, welche Projektvalidierung dennoch durchgeführt wurde.

Erfolgskriterien

Das Release gilt nur als erfolgreich, wenn:

• R, M, S und R \ S ermittelt, dokumentiert und durch konkrete Projektdateien begründet sind
• der Release-Scope ausschließlich S sowie die erforderlichen, konkret begründeten Nicht-Moduldateien enthält
• jede Abhängigkeit aus S \ M mit Grund, benötigendem Modul und konkreter Referenz dokumentiert ist
• Build, Tests, CI, Installation und Packaging ausschließlich Module aus S umfassen
• ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/TetraIF, ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/Z und ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/Lts/Common im Release konfigurieren, bauen und linken
• ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh für das Release angepasst ist
• alle Release-relevanten Tests aus ./qt-migration-legatus/qt6-after/qt6-migrated-legatus/tests bauen und per CTest erfolgreich laufen
• keine Tests für M gelöscht, abgeschwächt oder ignoriert wurden, um ein grünes Ergebnis zu erzielen
• Jenkins die Module baut, testet und RPMs erzeugt
• ./rpmbuild/make_rpm_ubuntu26.py ausschließlich Module und Artefakte aus S paketiert
• keine nicht freigegebenen Module oder Artefakte im Release landen
• nur zwingend erforderliche Forward Declarations im Release enthalten sind
• keine generierten Artefakte, Stubs, Dummies oder Fake-Erfolge eingecheckt wurden
• Änderungen pro Repository korrekt getrennt, validiert und committet wurden

Wenn nicht vollständig lösbar

Fälsche keinen Erfolg. Berichte exakt:

• welcher Release-Scope umgesetzt wurde
• welche erlaubten Module bauen
• welche Tests ausgeführt wurden
• welche Tests fehlen oder fehlschlagen
• welche nicht gelisteten Dateien technisch erforderlich waren
• welche Forward Declarations aufgenommen wurden und warum
• ob Jenkins Build, Test und RPM-Erzeugung ausführen kann
• ob RPM-Erzeugung erfolgreich war
• ob der Blocker Umgebung, Projekt, Pfad, Docker, Jenkins, RPM, Lizenz oder Zugang betrifft
• welche sicheren Änderungen durchgeführt wurden
• welche Risiken verbleiben

Finaler Bericht

Halte den finalen Bericht kurz und faktisch:

• Status: validiert, teilweise validiert oder blockiert
• Branch und Repositories
• vollständiges Modulset R, freigegebenes Set M, minimales Release-Set S und ausgeschlossene Module R \ S
• jede zusätzliche Abhängigkeit aus S \ M: Modul, benötigendes Modul, Grund und konkrete Projektdatei-Referenz
• Ergebnis des Scope-Audits vor Implementierung und vor Abschluss einschließlich geplanter/geänderter Dateien
• geänderter Release-Scope
• Dateien außerhalb der Modulverzeichnisse und Begründung
• new_docker_build.sh-Änderungen
• ausgeführte Build-/CTest-/Jenkins-/RPM-Kommandos
• Ergebnis je Kommando
• aufgenommene Forward Declarations
• Bestätigung, dass Module aus R \ S nicht gebaut, getestet, installiert oder paketiert werden, sowie bestätigte Ausschlüsse
• verbleibende Blocker oder Risiken