Ein Repository mit Server- und Oberflächenmodulen ändern, ohne den Build zu beschädigen

## Im Stammverzeichnis beginnen und die Regeln jedes betroffenen Moduls lesen Öffnen und koordinieren Sie das Projekt vom Repository-Stammverzeichnis aus, auch wenn eine Aufgabe auf ein einziges Teilprojekt beschränkt zu sein scheint. Behandeln Sie die Agentenanweisungen auf Stammebene als Grundlage und verschachtelte Anweisungsdateien als ergänzende lokale Regeln. Ermitteln Sie vor der Bearbeitung jedes Modul, das von der Aufgabe betroffen sein kann, und laden Sie dessen jeweilige Anweisungsdatei. Eine modulübergreifende Aufgabe muss alle einschlägigen lokalen Regeln einhalten, nicht nur die Regeln der Datei, die der zuerst vorgeschlagenen Änderung am nächsten liegt. ## Klären, wofür jedes Modul zuständig ist, und Server und Oberfläche gemeinsam ändern Pflegen Sie eine Zuständigkeitsübersicht für die wesentlichen Bereiche: - das öffentliche API-Modul ist für Erweiterungspunkte, Dienstverträge und Sicherheitsabstraktionen zuständig; - die serverseitige Anwendung ist für Geschäftslogik, reaktive Dienste, Weiterleitung, Sicherheit, Migrationen und Paketierung zuständig; - der Arbeitsbereich der Benutzeroberfläche ist für Verwaltungs- und Benutzeroberflächen, gemeinsam genutzte Pakete und den erzeugten API-Client zuständig; - die Module der Abhängigkeitsplattform sind für Vorgaben an die Anwendung und nachgelagerte Erweiterungen zuständig; - die Entwicklerdokumentation ist für menschenlesbare Architektur- und Arbeitsablaufanleitungen zuständig. Behandeln Sie Änderungen an Serverseite und Benutzeroberfläche als eine einzige schichtenübergreifende Aufgabe, sobald Verträge, Nutzdaten, Authentifizierung, Navigation oder Benutzererlebnis die Grenze überschreiten. Halten Sie öffentliche Verträge, serverseitige Verarbeitungsfunktionen und deren Nutzung in der Benutzeroberfläche innerhalb derselben Änderung synchron. ## Den API-Client bei API-Änderungen neu erzeugen, nie von Hand ändern Bewerten Sie die Auswirkungen auf die Benutzeroberfläche, sobald sich öffentliche Anfrage- oder Antworttypen, Routen, Routerverträge, API-Schemaanmerkungen, erzeugte Schemata, Authentifizierung oder Sitzungsverhalten ändern. Erzeugen Sie nach der Aktualisierung des Quellvertrags die API-Beschreibung und den Client mit den vom Repository vorgeschriebenen Befehlen neu. Bearbeiten Sie erzeugte Clientdateien niemals direkt. Korrigieren Sie den Vertrag oder die Eingabe des Generators, erzeugen Sie die Ausgabe neu und prüfen Sie den entstandenen Unterschied. Holen Sie eine Bestätigung ein, bevor Sie die erzeugte Ausgabe destruktiv verändern oder eine öffentliche API ändern, von der nachgelagerte Nutzer abhängig sein könnten. ## Prüfen, wie die Ausgabe der Oberfläche in den serverseitigen Build verpackt wird Verstehen Sie, wie die Ausgabe der Benutzeroberfläche in das bereitstellbare serverseitige Artefakt gelangt. Wenn der serverseitige Erstellungsprozess die kompilierte Oberfläche in die Anwendungsressourcen einbettet, wirkt sich jede Änderung ihrer Ausgabe auch auf den serverseitigen Paketierungsweg aus und muss dort geprüft werden. Führen Sie die schichtenübergreifende Koordination vom Stammverzeichnis aus, damit serverseitige Kompilierung, Paketierung der Oberfläche und Tests denselben Abhängigkeitsgraphen verwenden. Behandeln Sie Downloads während der Erstellung, voreingestellte Erweiterungen und kopierte Verteilungsartefakte als Bestandteil des Erstellungsvertrags und nicht als beiläufige Dateien. ## Versionen und Formatregeln aus den dafür vorgesehenen Dateien lesen Lesen Sie Abhängigkeitsversionen, Projektversion, Sprachversion, Plugin-Versionen und Abhängigkeiten der Benutzeroberfläche aus den dafür vorgesehenen Katalogen, Eigenschaftsdateien, Erstellungsskripten und Paketmanifesten. Schreiben Sie keine Version fest in den Code, für die bereits eine maßgebliche Quelle besteht. Verwenden Sie die konfigurierten Formatierer und Linter als maßgebliche Grundlage für Einrückung, Zeilenbreite und unterstützte Syntax. Halten Sie die deklarierte Sprachversion ein, einschließlich `release 21`, wenn diese angegeben ist, und belassen Sie Formatierungsregeln der Stammebene in dem Geltungsbereich, in dem der Erstellungsprozess sie erwartet. ## Keine blockierende Ein- und Ausgabe in reaktiven Code bringen und Datenbankpfade einhalten Führen Sie keine blockierende Ein- oder Ausgabe in reaktive Ausführungspfade ein, auch wenn an anderer Stelle virtuelle Threads aktiviert sind. Behalten Sie das vom Projekt gewählte Migrationswerkzeug bei, statt es stillschweigend durch ein anderes zu ersetzen, und belassen Sie dialektspezifische Migrationen in den dafür vorgesehenen Datenbankverzeichnissen. Belassen Sie Erweiterungsschemata, JSON-Laufzeitdaten, profilspezifische Konfiguration und das überschreibbare Arbeitsverzeichnis an den jeweils zuständigen Stellen. Verwenden Sie für eingebettete dateibasierte Datenbanken absolute Dateipfade; ein relativer URI kann unerwünschte Verzeichnisse unter dem Anwendungsmodul erzeugen und ändern, welche Datenbank geöffnet wird. ## Tests danach wählen, ob Server, Oberfläche oder beides geändert wurde Wählen Sie die Prüfungen entsprechend dem tatsächlichen Umfang aus: - rein serverseitige Änderungen erfordern die Repository-Formatierung und die betroffenen serverseitigen Tests; - Änderungen ausschließlich an der Benutzeroberfläche erfordern deren Formatierung, Typprüfung, statische Prüfung und einschlägige Komponententests; - Vertragsänderungen erfordern die Erzeugung der API-Beschreibung, die Neuerzeugung des Clients, die Prüfung der Benutzeroberfläche und serverseitige Tests; - schichtenübergreifende Änderungen erfordern zusätzlich zu beiden Seiten des Vertrags die Prüfung des endgültig paketierten Artefakts. Führen Sie zuerst die gezielten Prüfungen aus und erweitern Sie den Umfang anschließend nach Bedarf. Ergänzen oder aktualisieren Sie Tests für jedes geänderte Verhalten und reichen Sie die Arbeit nicht ein, solange erforderliche Prüfungen der kontinuierlichen Integration fehlschlagen. ## Vor dem Push das richtige Upstream-Repository prüfen und nur Dateien der Aufgabe stagen Ermitteln Sie das aktuelle Repository und prüfen Sie seine entfernten Gegenstellen, bevor Sie Änderungen übertragen oder eine Begutachtung eröffnen. Verwenden Sie das für diesen Arbeitsstand richtige Ursprungs-Repository; die Nutzung des Ursprungs eines verwandten öffentlichen oder proprietären Repositorys kann nur mit hohem Aufwand rückgängig gemacht werden. Beginnen Sie die Arbeit auf der vorgesehenen Ausgangsbasis des Ursprungs-Repositorys und verwenden Sie dessen Zweigkonventionen, etwa `upgrade/gradle-X`, `feat/name`, `fix/name` oder `improvement/name`. Merken Sie nur die zur Aufgabe gehörenden Dateien zur Übernahme vor; verwenden Sie niemals `git add -A` oder `git add .`, wenn Erstellungsausgaben oder Datenbankartefakte vorhanden sein könnten. Wenn ein veralteter Arbeitsbaum den Hauptzweig sperrt, prüfen Sie die Liste der Arbeitsbäume und entfernen Sie ausdrücklich nur den nachweislich veralteten Eintrag. Verwenden Sie keine breit angelegte Bereinigung als Ersatz dafür, den genauen Eigentümer der Sperre zu ermitteln. ## Vor Migrationen oder neuen Abhängigkeiten fragen und nie Geheimnisse committen Verwenden Sie drei Steuerungsebenen: - arbeiten Sie immer vom Stammverzeichnis aus, laden Sie alle anwendbaren verschachtelten Regeln, merken Sie Dateien ausdrücklich zur Übernahme vor, erzeugen Sie abgeleitete Clients aus der Quelle neu, ergänzen Sie Tests für geändertes Verhalten und weisen Sie in der Begutachtungsbeschreibung auf KI-unterstütztes Material hin; - holen Sie vor Änderungen an öffentlichen APIs, dem Hinzufügen von Erstellungs- oder Paketabhängigkeiten, dem Schreiben von Datenbankmigrationen, Änderungen an Sicherheitskonfigurationen oder Abläufen der kontinuierlichen Integration sowie vor dem destruktiven Ersetzen erzeugter Ausgaben eine Bestätigung ein; - übertragen Sie niemals Geheimnisse in die Versionsverwaltung, schreiben Sie keine maßgeblichen Versionen fest in den Code, fügen Sie reaktiven Pfaden keine blockierenden Vorgänge hinzu, bearbeiten Sie erzeugte Clients nicht direkt und eröffnen Sie keine Begutachtung, ohne das richtige Ursprungs-Repository bestätigt zu haben. Diese Grenzen gelten auch dann, wenn die Umsetzung selbst unkompliziert ist. Eine einfache Umsetzung verringert weder Kompatibilitäts-, Sicherheits-, Daten- noch Freigaberisiken. ## Bekannte Build-Fallstricke wie relative Datenbankpfade vermeiden Bewahren Sie bekannte werkzeugspezifische Invarianten: 1. Speicherorte dateibasierter eingebetteter Datenbanken müssen in absolute Dateisystempfade aufgelöst werden; relative Pfadangaben können unerwünschte Modulverzeichnisse erzeugen und dazu führen, dass die Anwendung die falsche Datenbank öffnet. 2. Eine Aktualisierung des Erstellungs-Wrappers erfordert sowohl den Wrapperbefehl mit Versionsangabe als auch einen zweiten Befehl zur Wrappererzeugung; wird nur der erste ausgeführt, bleiben die erzeugten Wrapperdateien inkonsistent. 3. Belassen Sie repositoryweite sonstige Formatierungseinstellungen im Stammverzeichnis. Eine Verschiebung in ein Anwendungsteilmodul würde inkompatible Formatierungsaufgaben zusammenführen und in der Version `9.x` des Erstellungswerkzeugs Validierungsfehler für implizite Abhängigkeiten auslösen. Dokumentieren Sie diese Fallstricke in der Nähe der maßgeblichen Erstellungsanleitung und prüfen Sie sie bei jeder Änderung der betroffenen Konfiguration.