Revises release prompt

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

@@ -85,13 +85,10 @@ dürfen im Release nur diese Teile enthalten sein:
 - `./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
+- `./Lts/Common`
+- `./include`
 
-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.
+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`
 
@@ -104,17 +101,17 @@ 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.
+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:
+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.
+Passe `./new_docker_build.sh` für das Release an. Entferne nicht benoetigte Teile aus dem Script.
 
 Das Skript muss:
 
@@ -136,7 +133,7 @@ die die herausgegebenen Module betreffen, müssen im Release enthalten sein, bau
 
 Vorgehen:
 
-1. Identifiziere alle CTest-Tests, die `TetraIF`, `Z`, `Lts/Application`, `specs`, zentrale `cmake`-Logik oder erforderliche Forward Declarations betreffen.
+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.
@@ -183,7 +180,7 @@ Wenn ein nicht erlaubter Teil referenziert wird, behebe die Referenz oder erklä
 
 Für die erlaubten Module:
 
-- entdecke reale CMake-Targets unter `TetraIF`, `Z` und `Lts/Application`
+- 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
@@ -204,8 +201,6 @@ Falls die Release-Module Qt-, RTI-, ndsgen-, KTextTemplate- oder andere Generato
 
 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:
@@ -213,8 +208,7 @@ Führe die beiden Verzeichnisse `./forward-declarations/` und `./.forward-declar
 - Root-`CMakeLists.txt`
 - zentrale Dateien unter `./cmake`
 - `./new_docker_build.sh`
-- Release-relevante Tests unter `./tests`
-- erforderliche Dateien unter `./forward-declarations/`
+- Release-relevante Tests unter `./qt-migration-legatus/qt6-after/qt6-migrated-legatus/tests`
 - `./specs`
 - `./jenkins-ci-rme`
 - `./rpmbuild/make_rpm_ubuntu26.py`
@@ -223,7 +217,7 @@ Jede Änderung außerhalb der Modulverzeichnisse muss im finalen Bericht begrün
 
 ## Validierung
 
-Validiere im Docker-/CI-Pfad. Verwende keine Host-Builds als Ersatz für Docker-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.
 
@@ -248,9 +242,9 @@ 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
-- `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
+- `./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
 - 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