Clarify developer release CTest inclusion and excluded-module rule

Entire-Checkpoint: 01M4RRA4X5M8F3DVW1QV3CTJR7

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

@@ -1,309 +1,194 @@
-# Copilot CLI Prompt: Erstes Release ausgewählter Qt6-Migrationsmodule
+# Copilot CLI Prompt: Erstes Qt6-Release der freigegebenen Module
 
-Dieser Prompt ist verbindlicher Task-Kontext. Arbeite autonom, minimal, reproduzierbar und ohne opportunistische Änderungen.
+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.
 
-## Required base prompt
+## 1. Ziel und Release-Charakter
 
-Vor jeder Änderung lesen und anwenden:
+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.
 
-- `./prompts/commit-policy.prompt.md`
+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.
 
-Wenn der Commit-/Repository-Prompt strenger ist, gilt er zusätzlich. Dieser Prompt konkretisiert nur das Release-Ziel und den Release-Scope.
+Das Release muss als eigene, reproduzierbare DEB-Pakete ausliefern:
 
-## Ziel
+- 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.
 
-Erstelle das erste Release von ausgewählten Modulen aus dem bereits weit fortgeschritten nach Qt6 migrierten Projekt.
+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.
 
-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.
+## 2. Begriffe und Scope
 
-Arbeite mit folgenden Mengen:
+Ermittle vor jeder Änderung aus realen Projektdateien:
 
-- `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`.
+- `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.
 
-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.
+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.
 
-## Zielbranch
+### Verbindliche Interpretation der Ausschlussregel
 
-Arbeite auf dem bestehenden Zielbranch:
+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:
 
-- `story/release-at-16-oct-2026`
+- 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.
 
-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.
+Verboten bleiben nur Tests, Targets, Quellen, Artefakte und Module aus `R \ S` sowie nicht nachgewiesene Inhalte außerhalb des Release-Scope.
 
-## Repository- und Submodule-Kontext
+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.
 
-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.
+## 3. Repository-, Branch- und Pfadregeln
 
-Erwartete Submodule:
+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.
 
-```text
-./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
+Aus `./qt-migration-legatus/qt6-after/qt6-migrated-legatus` dürfen nur `S` sowie unmittelbar erforderliche gemeinsame Build-/Test-/Packaging-Dateien verwendet werden, insbesondere:
 
-./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
-```
+- `TetraIF/`, `Z/`, `Lts/Common/`;
+- `CMakeLists.txt`, `cmake/`, `tests/`, `specs/`, `include/`;
+- `new_docker_build.sh`;
+- tatsächlich benötigte Dockerfiles und Skripte.
 
-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.
+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.
 
-## Harte Release-Grenze
+## 4. Build, CTest und Docker
 
-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.
+Analysiere und passe `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/new_docker_build.sh` minimal an. Der Docker-/CI-Pfad muss:
 
-Nicht erlaubt:
+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.
 
-- 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
+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.
 
-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:
+Mindestens ausführen, sofern vorhanden:
 
 ```bash
 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.
+## 5. Getrennte DEB-Pakete
 
-Zusätzlich Jenkins/RPM-Pfad prüfen:
+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:
 
-- Pipeline-Konfiguration in `./jenkins-ci-rme/release-16-10-2026.sh`
-- RPM-Erzeugung mit `./rpmbuild/make_rpm_ubuntu26.py`
+1. `qt6-release-runtime-<version>.deb`
+   - Runtime-Binaries und Bibliotheken aus `S`;
+   - keine C++-Quellen und keine CTest-Quellen.
 
-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.
+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.
 
-## Erfolgskriterien
+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`.
 
-Das Release gilt nur als erfolgreich, wenn:
+4. `qt6-release-ctest-sources-<version>.deb`
+   - C++-Quellen, Header und Testkonfiguration der enthaltenen Release-relevanten CTests;
+   - keine Testquellen aus `R \ S`.
 
-- `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
+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`.
 
-## Wenn nicht vollständig lösbar
+Falls ein weiteres DEB technisch erforderlich ist, dokumentiere vorab Name, Inhalt, Zweck und konkrete Dateireferenzen.
 
-Fälsche keinen Erfolg. Berichte exakt:
+### 5.1 Verbindliches Paketierungs-Kommando
 
-- 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
+Implementiere und validiere:
 
-## Finaler Bericht
+```bash
+./new_docker_build.sh \
+  --build \
+  --test \
+  --package-debs \
+  --deb-output "${DEB_OUTPUT_DIR}"
+```
 
-Halte den finalen Bericht kurz und faktisch:
+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.
 
-- 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
+Erwartete Ausgaben:
+
+```text
+${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:
+
+```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.