# Copilot CLI Prompt: Erstes Qt6-Release der freigegebenen Module Dieser Prompt ist verbindlicher Task-Kontext. Arbeite autonom, minimal, reproduzierbar und ohne opportunistische Änderungen. Lies vor jeder Änderung `./prompts/commit-policy.prompt.md`; strengere Repository-Regeln gelten zusätzlich. ## 1. Ziel und Release-Charakter Erstelle das erste Release der bereits nach Qt6 migrierten Module `TetraIF`, `Z` und `Lts/Common`. Dies ist kein erneuter Qt5→Qt6-Migrationslauf. Code darf nur geändert werden, wenn dies unmittelbar für Build, Tests, Installation oder Packaging des Release-Scope erforderlich ist. Dieses Release ist ausdrücklich ein **Entwickler- und Weiterentwicklungsrelease** der Qt6-Migration, kein reines Runtime- oder Endkundenrelease. Deshalb gehören die Release-relevanten CTests ausdrücklich zum Release: sowohl ihre ausführbaren Binaries als auch ihre C++-Quellen müssen ausgeliefert werden. CTests sind trotz des Begriffs „Release Build“ zu bauen, auszuführen und zu paketieren. Das Release muss als eigene, reproduzierbare DEB-Pakete ausliefern: - Binaries und Bibliotheken der freigegebenen Module; - migrierte Qt6-C++-Quellen ausschließlich aus `S`; - ausführbare Release-relevante CTest-Programme, Testdaten und deren C++-Quellen; - benötigte Dockerfiles, Build-, CMake-, CTest-, Jenkins- und DEB-Packaging-Skripte der reproduzierbaren Build-Pipeline. Nicht zum Release gehörende Workspace-Dateien werden physisch nicht gelöscht. Sie bleiben im Repository/Working Tree erhalten, dürfen aber durch explizite Allowlists und Manifeste nicht in DEBs oder andere Release-Artefakte gelangen. ## 2. Begriffe und Scope Ermittle vor jeder Änderung aus realen Projektdateien: - `R`: vollständige Menge aller Module unter `./qt-migration-legatus/qt6-after/qt6-migrated-legatus`; - `M = {TetraIF, Z, Lts/Common}`: explizit freigegebene Module; - `S`: kleinstes Modulset `M` plus zwingend notwendige direkte/transitive Abhängigkeiten aus `R`; - `R \ S`: ausgeschlossene Module. Leite `S` ausschließlich aus realen `CMakeLists.txt`, `add_subdirectory`, Targets, `target_link_libraries`, Includes, Generator-Konfigurationen, Tests, Install- und Packaging-Regeln ab. Dokumentiere jede Abhängigkeit in `S \ M` mit Modul, benötigendem Modul, Grund und konkreter Dateireferenz. ### Verbindliche Interpretation der Ausschlussregel Die Aussage „keine nicht freigegebenen Module bauen, testen, installieren oder paketieren“ bezieht sich **nur auf Module aus `R \ S`**. Sie verbietet nicht die Tests des Entwicklerreleases. Im Gegenteil: - Release-relevante CTests für `M` und nachgewiesene Abhängigkeiten aus `S \ M` müssen gebaut werden; - diese CTests müssen per CTest ausgeführt werden; - ihre Test-Binaries müssen in `qt6-release-ctest-runtime` enthalten sein; - ihre C++-Quellen müssen in `qt6-release-ctest-sources` enthalten sein; - die zugehörigen Testziele dürfen nicht wegen des Release-Charakters deaktiviert, entfernt, ignoriert oder aus CTest entfernt werden. Verboten bleiben nur Tests, Targets, Quellen, Artefakte und Module aus `R \ S` sowie nicht nachgewiesene Inhalte außerhalb des Release-Scope. Bei Unklarheiten keine Abhängigkeit raten. Unklarheit anhand realer Dateien auflösen; falls dies nicht möglich ist, Release nicht als erfolgreich melden und den Blocker exakt dokumentieren. ## 3. Repository-, Branch- und Pfadregeln Arbeite auf dem bestehenden Branch `story/release-at-16-oct-2026`; erstelle keinen neuen Branch, außer dies ist technisch unvermeidbar und begründet. Ermittle zuerst alle Repositories, Remotes, Branches, Working Trees und Submodule und ordne jede Datei dem zuständigen Repository zu. Aus `./qt-migration-legatus/qt6-after/qt6-migrated-legatus` dürfen nur `S` sowie unmittelbar erforderliche gemeinsame Build-/Test-/Packaging-Dateien verwendet werden, insbesondere: - `TetraIF/`, `Z/`, `Lts/Common/`; - `CMakeLists.txt`, `cmake/`, `tests/`, `specs/`, `include/`; - `new_docker_build.sh`; - tatsächlich benötigte Dockerfiles und Skripte. Aus der Pipeline dürfen nur für diesen Release erforderliche Dateien verwendet werden, insbesondere `jenkins-ci-rme/`, `rpmbuild/make_rpm_ubuntu26.py` soweit erforderlich sowie notwendige DEB-Packaging-Dateien, Manifeste und Dockerfiles. ## 4. Build, CTest und Docker Analysiere und passe `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh` minimal an. Der Docker-/CI-Pfad muss: 1. benötigte Systempakete reproduzierbar im Image installieren; 2. ausschließlich `S` konfigurieren und bauen; 3. echte Generator-Flows im Build-Tree ausführen; 4. alle Release-Targets einschließlich der zugehörigen CTest-Targets bauen; 5. alle Tests aus `./tests` ausführen, die `M`, `S \ M` oder erforderliche zentrale CMake-/Generator-Logik betreffen; 6. bei Build-, Link- oder Testfehlern mit Exit-Code ungleich `0` abbrechen; 7. keine Host-Pfade oder Entwicklerannahmen voraussetzen. Tests für `R \ S` sind ausgeschlossen. Tests für `M` und nachgewiesene Tests für `S \ M` sind Pflichtbestandteil des Entwicklerreleases. Generierte Dateien bleiben im Build-Tree und werden nicht als Quellen eingecheckt. Mindestens ausführen, sofern vorhanden: ```bash cd ./qt-migration-legatus/qt6-after/qt6-migrated-legatus ./new_docker_build.sh ``` ## 5. Getrennte DEB-Pakete Ein einziges Sammel-DEB ist nicht zulässig. Erzeuge mindestens diese fünf getrennten Pakete mit eigenen Paketwurzeln, eigenen `DEBIAN/control`-Dateien, eigenen Allowlists und Manifesten: 1. `qt6-release-runtime-.deb` - Runtime-Binaries und Bibliotheken aus `S`; - keine C++-Quellen und keine CTest-Quellen. 2. `qt6-release-sources-.deb` - migrierte Qt6-C++-Quellen und erforderliche Header der Module aus `S`; - keine Qt6-Quellen aus `R \ S` und keine generierten Build-Tree-Dateien. 3. `qt6-release-ctest-runtime-.deb` - alle ausführbaren Release-relevanten CTest-Programme für `M` und nachgewiesene Teile von `S \ M`; - erforderliche Laufzeitdateien und Testdaten; - keine CTest-Binaries aus `R \ S`. 4. `qt6-release-ctest-sources-.deb` - C++-Quellen, Header und Testkonfiguration der enthaltenen Release-relevanten CTests; - keine Testquellen aus `R \ S`. 5. `qt6-release-build-pipeline-.deb` - erforderliche Dockerfiles, `new_docker_build.sh`, CMake-/CTest-/Jenkins-/DEB-Packaging-Skripte, Konfigurationen und Manifeste; - keine nicht benötigten Repository-Dateien und keine Qt6-Quellen außerhalb von `S`. Falls ein weiteres DEB technisch erforderlich ist, dokumentiere vorab Name, Inhalt, Zweck und konkrete Dateireferenzen. ### 5.1 Verbindliches Paketierungs-Kommando Implementiere und validiere: ```bash ./new_docker_build.sh \ --build \ --test \ --package-debs \ --deb-output "${DEB_OUTPUT_DIR}" ``` Das Kommando muss den Scope validieren, `S` einschließlich der Pflicht-CTest-Targets bauen, alle Release-relevanten CTests ausführen, bei Fehlern abbrechen, die fünf DEBs erzeugen und deren tatsächlichen Inhalt gegen die Allowlists prüfen. Erwartete Ausgaben: ```text ${DEB_OUTPUT_DIR}/qt6-release-runtime-.deb ${DEB_OUTPUT_DIR}/qt6-release-sources-.deb ${DEB_OUTPUT_DIR}/qt6-release-ctest-runtime-.deb ${DEB_OUTPUT_DIR}/qt6-release-ctest-sources-.deb ${DEB_OUTPUT_DIR}/qt6-release-build-pipeline-.deb ${DEB_OUTPUT_DIR}/manifests/*.manifest ``` ### 5.2 Paketierungsregeln - Keine unbeschränkten Verzeichnis-Globs verwenden. - Dateien aus `R \ S` dürfen in keinem DEB enthalten sein. - Qt6-Modulquellen dürfen nur in `qt6-release-sources` enthalten sein. - CTest-C++-Quellen dürfen nur in `qt6-release-ctest-sources` enthalten sein. - CTest-Binaries dürfen nur in `qt6-release-ctest-runtime` enthalten sein. - Build-, Docker-, CI- und Packaging-Dateien dürfen nur in `qt6-release-build-pipeline` enthalten sein. - Mehrfachzuordnungen sind nur bei technisch zwingender Notwendigkeit zulässig und zu begründen. - Nicht benötigte Dateien werden nicht physisch gelöscht, aber zuverlässig aus allen DEBs ausgeschlossen. - Temporäre Dateien, Logs, Host-Pfade und nicht deklarierte Build-Tree-Artefakte nicht aufnehmen. Prüfe jedes DEB mindestens mit: ```bash dpkg-deb --info "${deb_file}" dpkg-deb --contents "${deb_file}" dpkg-deb --control "${deb_file}" "${control_output_dir}" ``` Die automatisierte Prüfung muss außerdem bestätigen: gültige Metadaten, Pflichtinhalte vorhanden, Manifest entspricht exakt dem Paketinhalt, keine unerlaubten Überschneidungen, keine Inhalte aus `R \ S`, alle Pflicht-CTest-Binaries vorhanden und alle zugehörigen C++-Testquellen vorhanden. ## 6. Jenkins, RPM und Forward Declarations Jenkins muss den Release-Scope verwenden, `new_docker_build.sh --build --test --package-debs ...` ausführen, CTest-Fehler als Pipeline-Fehler behandeln und die DEB-Erzeugung auslösen. Vorhandene RPM-Unterstützung darf den DEB-Release nicht ersetzen. `make_rpm_ubuntu26.py` nur im nachgewiesenen Umfang anpassen. Forward Declarations dürfen nur aufgenommen werden, wenn sie nachweislich für Build oder Pflicht-CTest von `S` erforderlich sind. Dokumentiere Datei, Target und konkrete Referenz. ## 7. Scope-Audits Vor Implementierung: - `R`, `M`, `S` und `R \ S` vollständig ermitteln und auflisten; - Repository-, Branch-, Remote-, Working-Tree- und Submodulestatus prüfen; - Abhängigkeiten mit Dateireferenzen dokumentieren; - geplante Dateien, Repository, Zweck und DEB-Zuordnung auflisten; - sicherstellen, dass Pflicht-CTest-Binaries und C++-Testquellen eingeplant sind. Vor Abschluss: - Bestandsaufnahme und Audit wiederholen; - tatsächliche DEB-Inhalte und Manifeste prüfen; - bestätigen, dass `R \ S` weder gebaut, getestet, installiert noch paketiert wird; - bestätigen, dass CTests von `M` und nachgewiesene CTests von `S \ M` gebaut, ausgeführt und als Quellen und Binaries ausgeliefert werden; - keine Tests löschen, abschwächen, ignorieren oder wegen des Release-Begriffs ausschließen; - Jenkins-, Docker-, CMake-, Installations- und Packaging-Regeln prüfen. ## 8. Finaler Bericht Berichte kurz und faktisch: - Status: `validiert`, `teilweise validiert` oder `blockiert`; - Branch und Repositories/Submodule; - vollständiges `R`, `M`, `S` und `R \ S`; - jede Abhängigkeit aus `S \ M` mit Grund und Dateireferenz; - Vorher-/Nachher-Scope-Audit und geänderte Dateien; - physisch beibehaltene, aber aus DEBs ausgeschlossene Dateien; - ausgeführte Build-, CTest-, Jenkins- und DEB-Kommandos mit Ergebnis; - erzeugte DEBs und deren Inhalte; - ausgeführte und ausgelieferte CTests einschließlich Binaries und C++-Quellen; - Bestätigung, dass keine Quellen oder Artefakte aus `R \ S` enthalten sind; - verbleibende Blocker und Risiken. Wenn die Validierung wegen Umgebung, Docker, Zugang, Lizenz, Projekt, Jenkins, DEB-Packaging oder Pfad nicht vollständig möglich ist, klassifiziere den Blocker exakt und behaupte keinen Erfolg.