Nimm kleine, kompatible Änderungen in einem modularen Java-Projekt vor

## Prüfe vor dem Bearbeiten die Build-, Format- und CI-Regeln Behandle die Leitlinien des Projektarchivs, die Erstellungskonfiguration, die Formatierungsregeln und die Prüfungen der fortlaufenden Integration als ausführbare Verträge. Lies vor der Bearbeitung die geltenden Anweisungen und ermittle, welche Regeln maschinell durchgesetzt werden. - Ermittle den kanonischen Build-Wrapper, das Formatierungswerkzeug, die statischen Prüfungen, die Testbefehle und die Beitragsrichtlinie. - Verfolge vor einer Quelltextänderung das zuständige Modul und seine Abhängigkeiten. - Bevorzuge etablierte Hilfsprogramme und Muster des Projekts gegenüber nur lokal bequemen Alternativen. - Unterscheide Quelltextkompatibilität, Anforderungen der Erstellungswerkzeuge, Unterstützung der Laufzeitumgebung und Verhalten des Auslieferungspakets. - Deaktiviere keine Qualitätsprüfung nur deshalb, damit eine Änderung besteht. Verwende die kleinste maßgebliche Eingabe, die das angeforderte Verhalten steuert. ## Halte den Code mit der festgelegten Java-Version und den Abhängigkeiten lauffähig Für eine Erstellung kann eine neuere Werkzeugkette erforderlich sein, obwohl der Quelltext mit einer älteren Laufzeitumgebung kompatibel bleibt. Kompiliere und teste gemäß der festgelegten Quelltextebene; gehe nicht davon aus, dass eine neuere lokale Umgebung auch neuere Sprachmerkmale oder Bibliotheks-APIs zulässt. - Ersetze nicht unterstützte Komfort-APIs durch kompatible Entsprechungen. - Verwende bei Bedarf die verschobenen oder abgeschatteten Namensräume für Abhängigkeiten des Projektarchivs. - Bevorzuge projekteigene Hilfsprogramme für Validierung, Serialisierung, Sammlungen, Dateien, Future-Verarbeitung und Zeit. - Verzichte auf unmittelbare Importe externer Bibliotheken, wenn das Auslieferungspaket diese Bibliotheken isoliert. - Kläre vor dem Hinzufügen einer Abhängigkeit deren Kompatibilität, Lizenzierung, Paketierung und mittelbare Auswirkungen. Überprüfe die Kompatibilität mit dem dafür vorgesehenen Erstellungsziel des Projektarchivs, nicht allein durch lokale Kompilierung. ## Nutze in öffentlichen APIs Factories, Builder und unveränderliche Ergebnisse Kennzeichne APIs entsprechend ihrer vorgesehenen Stabilität: Stabile öffentliche Verträge, in Entwicklung befindliche öffentliche Verträge und interne Implementierungsbereiche müssen klar getrennt bleiben. - Lass Erzeuger Schnittstellen zurückgeben und verbirg die Konstruktion hinter privaten Konstruktoren oder statischen Erzeugungsmethoden. - Verwende für mehrstufige Konfigurationen Erstellungsobjekte mit verkettbaren Methoden und einem einzigen validierten Konstruktionspunkt. - Halte Ergebnisobjekte unveränderlich: mit als final deklariertem Zustand, ohne Settermethoden und mit vollständiger Gleichheitsprüfung, Hashwertbildung und Zeichenfolgendarstellung. - Stelle allgemeine und typisierte Schnittstellen bereit, wenn Aufrufende beide Formen ohne unsichere Typumwandlung benötigen. - Dokumentiere die Erwartungen an die Threadsicherheit öffentlicher Typen. Die Änderung eines öffentlichen Vertrags erfordert eine Kompatibilitätsanalyse und den passenden Weg der Versionsfortschreibung. ## Halte Abhängigkeiten zwischen Modulen in einer Richtung Erfasse vor der Implementierung den Modulgraphen. Grundlagenmodule sollen gemeinsame Typen und Schnittstellen enthalten; Protokoll- oder Übertragungsschichten bauen darauf auf; gleichrangige Klient- und Servermodule dürfen nicht voneinander abhängen; Integrationen gehören oberhalb stabiler unterer Schichten. - Definiere gemeinsame Schnittstellen im tiefsten geeigneten Modul und ihre Implementierungen darüber. - Verhindere, dass Anbindungen und optionale Integrationen Abhängigkeiten in den Kern eintragen. - Verhindere zyklische Abhängigkeiten und reine Komfortimporte zwischen gleichrangigen Modulen. - Bilde in Tests die Paketstruktur des Produktivcodes nach. - Lege erzeugten Quelltext, Auslieferungsbestandteile, Dokumentationserzeuger und Testhilfen in den dafür vorgesehenen Modulen ab. Wenn eine Funktion Grenzen überschreitet, ändere jede zuständige Schicht ausdrücklich, statt die Architektur zu umgehen. ## Trenne Fehlerarten und schütze gemeinsamen Zustand mit Locks Validiere Eingaben an API-Grenzen mit den projektüblichen Hilfsfunktionen zur Vorbedingungsprüfung und aussagekräftigen Meldungen. Bewahre die Ausnahmehierarchie, damit Aufrufende Bedienfehler, erneut versuchbare Fehlschläge und ungeprüfte interne Fehler unterscheiden können. - Gib asynchrone Fehlschläge über die etablierten Future-Hilfsprogramme und Fehlerbehandlungen weiter. - Verknüpfe asynchrone Arbeit, statt sie ohne dokumentierten Grund zu blockieren. - Schütze gemeinsam genutzten veränderlichen Zustand mit ausdrücklichen Sperren und dokumentiere die geschützten Felder. - Verwende Sichtbarkeitsmechanismen nur, wenn ein Zugriff außerhalb der Sperre sie erfordert. - Schließe Ressourcen durch strukturierte Ressourcenverwaltung. - Gestalte Schließvorgänge idempotent, wenn eine Bereinigung mehrfach erfolgen kann. Verbirg keine prüfungspflichtigen Fehlschläge und fasse erneut versuchbare und dauerhafte Fehler nicht in einer einzigen, undifferenzierten Ausnahme zusammen. ## Halte Konfigurationsschlüssel und Nachrichtenschemata kompatibel Definiere Konfigurationen durch typisierte Builder mit Standardwerten, Beschreibungen und optionalen Werten sowie, sofern zutreffend, einer Behandlung veralteter Schlüssel. Verwende hierarchische, einheitliche Schlüssel und greife über die Konfigurationsabstraktion des Projektarchivs auf Werte zu. Für Serialisierung und entfernte Nachrichten gilt: - Bewahre das festgelegte Schema und die Protokollversion. - Verwende nur Feldformen, die von dieser Version unterstützt werden. - Erzeuge den Quelltext nach Schemaänderungen mit dem vorgegebenen Generator neu. - Halte Übertragungsnachrichten unveränderlich und kennzeichne interne Übertragungstypen entsprechend. - Stelle optionale Felder ausdrücklich dar. - Bearbeite niemals erzeugte Dateien, wenn sie von einem Erzeugungsablauf verwaltet werden. Aktualisiere bei jeder Änderung eines Konfigurations- oder Übertragungsvertrags die Kompatibilitätstests und die erzeugte Dokumentation. ## Schreibe Unit- und Integrationstests mit den Testwerkzeugen des Projekts Verwende das vom Projektarchiv gewählte Testgerüst, die Prüfbibliothek, die Benennungskonventionen, Erweiterungen und grundlegenden Testvorrichtungen. Vermische damit keine alternativen Prüfungen oder Zeitbegrenzungsmechanismen, die dem globalen Testgerüst widersprechen. - Schreibe gezielte Einheitstests für lokales Verhalten und Integrationstests für Verträge zwischen Komponenten. - Verwende aussagekräftige Testnamen, die das geprüfte Verhalten benennen. - Prüfe sowohl erfolgreiche Ergebnisse als auch erwartete Fehlschläge. - Verwende unterstützte Testvorrichtungen für Cluster, Speicher oder Dienste wieder, statt eine parallele Infrastruktur aufzubauen. - Führe zuerst den eng eingegrenzten betroffenen Test und danach die direkt betroffene Testgruppe aus. - Bestätige, dass der Test aus dem beabsichtigten Grund fehlschlägt, bevor du dich zum Nachweis einer Korrektur auf ihn stützt. Teste über das öffentliche Verhalten, wenn ein internes Implementierungsdetail nicht Bestandteil des Vertrags ist. ## Baue und prüfe über den Build-Wrapper des Projekts Verwende den Build-Wrapper des Repositorys für Erstellung, Formatierung, statische Analyse, Lizenzprüfungen, Quelltexterzeugung und Tests. Die vorgegebenen Befehle können erzeugte Bestandteile vorbereiten oder Kompatibilitätsanforderungen durchsetzen, die beim direkten Aufruf einzelner Werkzeuge übersehen werden. - Erstelle mit der dokumentierten Werkzeugkette und bewahre dabei das festgelegte Quelltextziel. - Starte lokale Dienstabhängigkeiten und Komponenten in der dokumentierten Reihenfolge. - Bearbeite nur unterstützte Konfigurationsdateien und Werte. - Führe die Formatierung vor den statischen Prüfungen aus. - Führe die betroffenen Testgruppen vor einer umfassenderen Überprüfung aus. - Verwende das Abdeckungsprofil, wenn die Änderung geprüftes Verhalten beeinflussen kann. Verstehe die Stufen der fortlaufenden Integration und bilde die relevante Stufe lokal nach, bevor du den Abschluss meldest. ## Folge dem Formatierer und halte themenfremde Änderungen aus dem Diff Befolge die vorgeschriebene Reihenfolge von Importen und Modifikatoren, die Syntax von Datenfeldern, Klammerregeln, Leerraumrichtlinie und Benennungskonventionen. Überlasse die rein mechanische Gestaltung dem vorgegebenen Formatierungswerkzeug. - Vermeide Platzhalterimporte sowie vom Projektarchiv verbotene Kommentarmarkierungen oder Urheberkennzeichnungen. - Dokumentiere public- und protected-APIs, wenn das Projekt dies verlangt. - Halte Dateigrößenbegrenzungen ein, indem du zusammengehörige Verantwortlichkeiten auslagerst, statt die Lesbarkeit durch Verdichtung zu beeinträchtigen. - Aktualisiere die Dokumentation, wenn sich Befehle, Konfiguration, Kompatibilität oder öffentliches Verhalten ändern. - Prüfe den endgültigen Änderungsvergleich auf sachfremde Umschreibungen, versehentliche Bearbeitungen erzeugter Dateien, Geheimnisse und unvollständige Bereinigung. Verbinde eine gezielte Verhaltensänderung nicht mit einer sachfremden Umstrukturierung. ## Veröffentliche Änderungen über Review-Zweige, nie per Force-Push Arbeite in einem autorisierten Zweig und überprüfe vor dem Push jede entfernte Gegenstelle. Schütze übergeordnete oder gemeinsam genutzte Zweige; reiche Änderungen über den Prüfweg des Projekts ein, statt unmittelbar in geschützte Ziele zu schreiben. - Führe nach dem dokumentierten Ablauf ein rebase oder eine Aktualisierung vom maßgeblichen Ausgangszweig aus. - Verfasse einen knappen, auf die Komponente begrenzten Commit-Titel und erläutere bei Bedarf die Motivation im Text. - Prüfe vor dem Einreichen den vollständigen Änderungsvergleich des Zweigs. - Führe Formatierung, statische Prüfungen, Lizenzprüfungen und betroffene Tests aus. - Füge dem Änderungsantrag eine verständliche Zusammenfassung und einen Testplan bei. - Kennzeichne Änderungen, die mit Unterstützung erstellt wurden, für die menschliche Prüfung, wenn die Beitragsrichtlinie dies verlangt. Führe ohne ausdrückliche Genehmigung niemals einen force-push auf einen gemeinsam genutzten Zweig oder zerstörerische Verlaufsoperationen aus. ## Frage vor großen oder zerstörerischen Schritten wie neuen Abhängigkeiten oder Resets Führe klar begrenztes Lesen, lokale Erstellungen, Tests, Formatierung, Diagnose und Korrekturen, die den bestehenden Regeln folgen, selbstständig aus. Frage vor umfassenden oder folgenreichen Arbeiten nach, darunter modulübergreifende Umstrukturierungen, neue Abhängigkeiten, Schemamigrationen, Änderungen am Erstellungssystem, Änderungen an der fortlaufenden Integration oder zerstörerische Operationen. Ohne ausdrückliche Erlaubnis darfst du niemals: - Zugangsdaten oder vertrauliche Werte einchecken; - unmittelbar auf ein geschütztes übergeordnetes Ziel pushen; - einen force-push auf gemeinsam genutzten Verlauf ausführen oder Zweige löschen; - hard reset oder eine zerstörerische Bereinigung ausführen; - Hooks, statische Prüfungen oder Formatierungsregeln umgehen; - erzeugte Ergebnisse statt ihres Quelltexts verändern; - Qualitätsprüfungen abschwächen, um ein bestandenes Ergebnis zu erhalten. Überprüfe vor dem Abschluss Tests, Formatierung, statische Prüfungen, erforderliche Kopfzeilen und den vollständigen beabsichtigten Änderungsvergleich. Wenn Umfang oder Umkehrbarkeit unklar sind, halte an und erläutere die erforderliche Entscheidung.