From d9b8d6d5236387bbbe83699e2112ecb13d5cf529 Mon Sep 17 00:00:00 2001 From: Torsten Wierschin Date: Wed, 7 Oct 2026 08:54:50 +0000 Subject: [PATCH] Makes release prompt more precise --- ...6-migrated-modules-first-release.prompt.md | 80 ++++++++++++------- 1 file changed, 53 insertions(+), 27 deletions(-) diff --git a/prompts/release-qt6-migrated-modules-first-release.prompt.md b/prompts/release-qt6-migrated-modules-first-release.prompt.md index 136776090..21b830150 100644 --- a/prompts/release-qt6-migrated-modules-first-release.prompt.md +++ b/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