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.

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 enthalten sein.

Nicht erlaubt:

• zusätzliche Module, Verzeichnisse, Targets oder Tests außerhalb des Release-Scopes
• opportunistische Refactorings, Cleanups oder Modernisierungen
• entfernte oder nicht freigegebene Module wieder einzuführen
• 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

Wenn ein nicht gelisteter Teil technisch erforderlich ist, damit die gelisteten Module bauen oder testen, darf nur die kleinste notwendige Datei/Komponente aufgenommen werden. Begründe jede solche Ausnahme einzeln im finalen Bericht.

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/Application
• ./forward-declarations/ nur soweit für Build und Tests zwingend erforderlich
• ./.forward-declarations/ nur soweit für Build und Tests zwingend erforderlich

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.

Prüfe und dokumentiere, welche Dateien aus ./forward-declarations/ tatsächlich benötigt werden. Nicht benötigte Forward Declarations dürfen nicht im Release verbleiben.

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

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:

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

Passe ./new_docker_build.sh für das Release an.

Das Skript muss:

• nur die freigegebenen Release-Module konfigurieren und bauen
• alle für diese Release-Module relevanten 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 als versteckte Abhängigkeit bauen
• keine host-lokalen Pfade oder Entwicklerannahmen verwenden
• im Docker-/CI-Kontext reproduzierbar laufen

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 TetraIF, Z, Lts/Application, specs, zentrale cmake-Logik oder erforderliche Forward Declarations betreffen.
2. Stelle sicher, dass diese Tests registriert sind.
3. Stelle sicher, dass sie durch ./new_docker_build.sh gebaut und ausgeführt werden.
4. Entferne oder ignoriere keine relevanten Tests, nur um Fehler zu verdecken.
5. Tests für nicht freigegebene Module dürfen nicht Bestandteil des Release-Pfads sein, außer sie sind direkte Integrationsvoraussetzung für die freigegebenen Module und werden begründet.

Jenkins-/RPM-Anforderungen

Die Jenkins-Pipeline in ./jenkins-ci-rme muss für das Release:

• den Release-Scope auschecken oder verwenden
• ./new_docker_build.sh für Build und Tests ausführen
• CTest-Fehler als Pipeline-Fehler behandeln
• RPM-Erzeugung über ./rpmbuild/make_rpm_ubuntu26.py auslösen
• nur die freigegebenen Module 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.

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. Liste jede geplante Dateiänderung auf.
4. Ordne jede geplante Datei exakt einem Repository zu.
5. Stoppe, wenn Repository-Zuordnung, Branch oder Remote nicht eindeutig sind.

Release-Scope-Audit

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

• Liste alle Verzeichnisse/Dateien, die im Release enthalten wären.
• Vergleiche diese Liste gegen den erlaubten Release-Scope.
• Entferne oder schließe nicht erlaubte Teile aus.
• Prüfe CMake-Targets und Install-/Package-Regeln auf nicht erlaubte Module.
• Prüfe Tests auf nicht erlaubte Module.
• Prüfe Jenkins und RPM-Spezifikation/-Script auf nicht erlaubte Artefakte.

Wenn ein nicht erlaubter Teil referenziert wird, behebe die Referenz oder erkläre, warum er direkt und zwingend für die erlaubten Module erforderlich ist.

CMake-/Target-Regeln

Für die erlaubten Module:

• entdecke reale CMake-Targets unter TetraIF, Z und Lts/Application
• erfinde keine Targets
• füge keine Targets hinzu, die nicht existieren
• registriere nur erforderliche Targets im Release-Build
• stelle sicher, dass Parent-CMakeLists.txt nur freigegebene Module aktiviert
• stelle sicher, dass install/package-Regeln nur freigegebene Artefakte 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.

Führe die beiden Verzeichnisse ./forward-declarations/ und ./.forward-declarations/ in ./forward-declarations/ zusammen. Verschiebe bzw. integriere benötigte Dateien aus ./.forward-declarations/ nach ./forward-declarations/, sodass der Release-Pfad final ausschließlich ./forward-declarations/ verwendet. Passe CMake-Include-Pfade und Referenzen entsprechend an. Erzeuge dabei keine generierten Artefakte, Stubs, Dummies oder Fake-Ausgaben.

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 ./tests
• erforderliche Dateien unter ./forward-declarations/
• ./specs
• ./jenkins-ci-rme
• ./rpmbuild/make_rpm_ubuntu26.py

Jede Änderung außerhalb der Modulverzeichnisse muss im finalen Bericht begründet werden.

Validierung

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
• 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:

• der Release-Scope ausschließlich die erlaubten Teile enthält
• TetraIF, Z und Lts/Application im Release konfigurieren, bauen und linken
• ./new_docker_build.sh für das Release angepasst ist
• alle Release-relevanten Tests aus ./tests bauen und per CTest erfolgreich laufen
• Jenkins die Module baut, testet und RPMs erzeugt
• ./rpmbuild/make_rpm_ubuntu26.py nur die freigegebenen Teile 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
• 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ätigte Ausschlüsse nicht freigegebener Module
• verbleibende Blocker oder Risiken