Makes release prompt more precise

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

@@ -16,6 +16,14 @@ Erstelle das erste Release von ausgewählten Modulen aus dem bereits weit fortge
 
 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:
@@ -56,19 +64,22 @@ Alle Release-relevanten Repositories/Submodule müssen auf `story/release-at-16-
 
 ## Harte Release-Grenze
 
-Im Release dürfen ausschließlich die unten explizit angegebenen Teile enthalten sein.
+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, Verzeichnisse, Targets oder Tests außerhalb des Release-Scopes
+- 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
 
-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.
+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`
 
@@ -115,14 +126,16 @@ Passe `./new_docker_build.sh` für das Release an. Entferne nicht benoetigte Tei
 
 Das Skript muss:
 
-- nur die freigegebenen Release-Module konfigurieren und bauen
-- alle für diese Release-Module relevanten CMake-Targets bauen oder validieren
+- 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 als versteckte Abhängigkeit bauen
+- 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:
@@ -133,11 +146,11 @@ die die herausgegebenen Module betreffen, müssen im Release enthalten sein, bau
 
 Vorgehen:
 
-1. Identifiziere alle CTest-Tests, die `TetraIF`, `Z`, `Lts/Common`, `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.
+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
 
@@ -147,11 +160,12 @@ Die Jenkins-Pipeline in `./jenkins-ci-rme` muss für das Release:
 - `./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
+- 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
 
@@ -159,22 +173,25 @@ 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.
+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 alle Verzeichnisse/Dateien, die im Release enthalten wären.
-- Vergleiche diese Liste gegen den erlaubten Release-Scope.
+- 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 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.
+- 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, behebe die Referenz oder erkläre, warum er direkt und zwingend für die erlaubten Module erforderlich ist.
+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
 
@@ -183,9 +200,10 @@ 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
-- 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 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
@@ -214,6 +232,7 @@ Forward Declarations dürfen nur im Release sein, wenn sie direkt für Build ode
 - `./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
 
@@ -241,12 +260,16 @@ Wenn eine Validierung wegen Umgebung, Zugang, Lizenz, Docker oder fehlender Infr
 
 Das Release gilt nur als erfolgreich, wenn:
 
-- der Release-Scope ausschließlich die erlaubten Teile enthält
+- `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` nur die freigegebenen Teile paketiert
+- `./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
@@ -274,11 +297,14 @@ 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ätigte Ausschlüsse nicht freigegebener Module
+- Bestätigung, dass Module aus `R \ S` nicht gebaut, getestet, installiert oder paketiert werden, sowie bestätigte Ausschlüsse
 - verbleibende Blocker oder Risiken