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

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:

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-<version>.deb

   • Runtime-Binaries und Bibliotheken aus S;
   • keine C++-Quellen und keine CTest-Quellen.

2. qt6-release-sources-<version>.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-<version>.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-<version>.deb

   • C++-Quellen, Header und Testkonfiguration der enthaltenen Release-relevanten CTests;
   • keine Testquellen aus R \ S.

5. qt6-release-build-pipeline-<version>.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:

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

${DEB_OUTPUT_DIR}/qt6-release-runtime-<version>.deb
${DEB_OUTPUT_DIR}/qt6-release-sources-<version>.deb
${DEB_OUTPUT_DIR}/qt6-release-ctest-runtime-<version>.deb
${DEB_OUTPUT_DIR}/qt6-release-ctest-sources-<version>.deb
${DEB_OUTPUT_DIR}/qt6-release-build-pipeline-<version>.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:

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.