Ändere ein mehrsprachiges Automatisierungs-Monorepo, ohne die Kompatibilität zu brechen

## Lies zuerst die Regeln des Repositorys, dann die Anweisungen nahe den geänderten Dateien Beginne mit den Regeln auf Repository-Ebene und lies anschließend die Anweisungen, die den zu ändernden Dateien am nächsten liegen. Sprachanbindungen, gemeinsam genutzte Infrastruktur, native Komponenten und Veröffentlichungswerkzeuge können jeweils engere Vorgaben festlegen. Wenn das Repository einen von der Versionsverwaltung ignorierten lokalen Bereich für persönliche Einstellungen der Mitwirkenden, erzeugte Artefakte, vorläufige Arbeiten oder isolierte Erstellungsausgaben bereitstellt, prüfe vor Beginn die dafür dokumentierten ergänzenden Anweisungen. Behandle benutzerdefinierte lokale Anweisungen als zusätzlichen Kontext innerhalb der aktuellen Aufgabe und der übergeordneten Sicherheitsregeln. Ordne das Repository nach Verantwortungsbereichen: - Sprachanbindungen sind für sprachspezifische APIs, Tests und Stilregeln verantwortlich; - gemeinsam genutzte Bereiche für Protokolle, Übertragung, Erstellung, Testdaten und Skripte wirken sich auf mehrere Verbraucher aus; - native Verwaltungskomponenten, Verteil- oder Weiterleitungsdienste und Abhängigkeitsdefinitionen haben einen besonders großen Wirkungsbereich; - Quellen von Drittanbietern sind schreibgeschützt, sofern die Aufgabe nicht ausdrücklich deren Pflege verlangt; - erzeugte Ausgaben dürfen niemals von Hand bearbeitet werden. Gehe nicht davon aus, dass Endbenutzerdokumentation, Hinweise für Mitwirkende und erzeugte API-Referenzen am selben Ort liegen. ## Halte öffentliche APIs kompatibel und Änderungen klein genug zum Rückgängigmachen Wahre die Kompatibilität der öffentlichen API sowie die Binärkompatibilität, sofern die Aufgabe keinen Bruch ausdrücklich erlaubt. Benutzer sollten normalerweise allein durch Ändern der Version aktualisieren können. Vermeide Umstrukturierungen im gesamten Repository, flächendeckende Formatierungen und nicht damit zusammenhängende Bereinigungen. Bevorzuge eine kleine, umkehrbare Änderung, die genau ein Problem löst. Bevor du öffentliches Verhalten entfernst, kennzeichne es als veraltet und biete eine eindeutige Alternative für die Umstellung an. Verstehe das Fehlen semantischer Versionierung nicht als Erlaubnis, Funktionen ohne Übergang zu entfernen. Verschiebe oder kopiere nachverfolgte Dateien vorzugsweise, statt sie zu löschen und neu anzulegen, wenn dadurch ihr Verlauf erhalten bleibt. Fordere vor Änderungen an besonders riskanten Bereichen eine Prüfung an, sofern der Benutzer die Änderung nicht bereits angewiesen hat. Dazu zählen die Semantik gemeinsam genutzter Protokolle, Übertragungsserialisierung, Auswertung von Funktionsmerkmalen, Neufestlegung von Abhängigkeitsversionen, gemeinsam genutzte Testdaten, Einbindung ins Erstellungssystem, Weiterleitung, Verteilungswarteschlangen und Code, den mehrere Sprachanbindungen verwenden. ## Baue mit dem festgelegten Build-Werkzeug nur das kleinste betroffene Ziel Verwende den vom Repository festgelegten hermetischen Einstiegspunkt des Erstellungssystems, statt eine eingerichtete lokale Umgebung für eine bestimmte Sprache vorauszusetzen. Erkunde den Erstellungsgraphen, bevor du große Teile des Verzeichnisbaums liest. Frage Zielbezeichnungen und Abhängigkeiten ab und erstelle oder teste anschließend das kleinste Ziel, das die Änderung abdeckt. Versuche, den maßgeblichen Erstellungsbefehl direkt auszuführen. Wenn Einschränkungen der isolierten Umgebung, des Netzwerks oder der Werkzeugkette die Ausführung verhindern, melde die Blockade und nenne den genauen Befehl, den der Benutzer separat ausführen kann. Wenn das voreingestellte Ausgabeverzeichnis eingeschränkt ist oder ein zweiter Arbeitsbaum verwendet wird, isoliere die Erstellungsausgabe: - stelle die Startoption `output-base` vor den Befehl `build`, `test` oder `query`; - verankere den Pfad im Stammverzeichnis des Repositorys, damit er aus jedem Verzeichnis gleich aufgelöst wird; - bewahre die isolierte Ausgabe im von der Versionsverwaltung ignorierten lokalen Bereich auf. Führe zerstörerische Cache-Bereinigungen nicht als routinemäßigen Schritt zur Fehlerbehebung aus. Bevorzuge gezielte Neuerstellungen und erläutere jede tatsächlich notwendige Ungültigmachung zwischengespeicherter Daten. ## Prüfe, ob sich die Anbindungen anderer Sprachen gleich verhalten Wenn sich für Benutzer sichtbares Verhalten ändert, vergleiche die Umsetzung mit mindestens einer weiteren Sprachanbindung. Prüfe die Gleichheit insbesondere bei: - Namen öffentlicher Methoden, Argumenten, Vorgabewerten und Rückgabeverhalten; - Protokollbefehlen und Serialisierung; - Fernübertragung und Fehlerzuordnung; - Auswertung von Funktionsmerkmalen und Optionen; - als veraltet gekennzeichneten Elementen und Umstellungswegen; - Dokumentationsbeispielen und Protokollmeldungen für Benutzer. Ermittle bei gemeinsam genutztem grundlegendem Verhalten jede Sprachanbindung und jeden Dienst, die beziehungsweise der die Änderung verwenden könnte. Wenn die aktuelle Aufgabe nicht alle sicher aktualisieren kann, berichte über die anschließend nötige Angleichung oder empfehle eine nachverfolgte Aufgabe. Erzwinge nicht in allen Sprachen dieselbe interne Struktur. Erhalte das gemeinsame Verhalten und beachte zugleich die eingeführten Ausdrucksweisen und Testkonventionen jeder Sprachanbindung. ## Beginne mit einem kleinen fehlschlagenden Test mit echten Teilen statt Mocks Schreibe vorzugsweise einen zunächst fehlschlagenden Test, bevor du geändertes Verhalten umsetzt. Beginne mit einem kleinen Einheiten- oder Vertragstest; verwende Browser- oder Ende-zu-Ende-Tests nur, wenn sich das Verhalten auf einer niedrigeren Ebene nicht zuverlässig prüfen lässt. Vermeide Testattrappen, wenn sie ein öffentliches Protokoll oder den Vertrag einer Sprachanbindung falsch darstellen könnten. Bevorzuge echte Parser und Serialisierer, lokale Testdaten, leichtgewichtige Server oder vorhandene Integrations-Testumgebungen. Wähle anhand des Erstellungsgraphen das engste passende Testziel aus. Hilfreiche Steuerungsmöglichkeiten sind: - auf kleine Tests zu filtern; - bei der Fehlersuche die vollständige Testausgabe anzuzeigen; - zwischengespeicherte Testergebnisse auszuschalten, wenn eine echte erneute Ausführung erforderlich ist; - die sprachspezifischen Anweisungen zum richtigen Ziel und zu den richtigen Optionen heranzuziehen. Prüfe, ob die erwarteten Tests tatsächlich ausgeführt wurden. Ein erfolgreicher Abschluss des Erstellungswerkzeugs ohne passende Tests belegt keine Korrektheit. Erweitere die Prüfung nach dem erfolgreichen gezielten Test nur auf die unmittelbar betroffene Sprachanbindung, das gemeinsam genutzte Ziel oder die betroffene Integrationsschnittstelle. ## Schreibe hilfreiche Logs und Kommentare und formatiere nur, was sich geändert hat Füge Protokollmeldungen dort hinzu, wo Benutzer oder Betreiber Einblick in wichtige Zustände, Wiederholungsversuche, Weiterleitungen oder Fehlerursachen benötigen. Befolge die sprachspezifischen Konventionen zur Protokollierung und vermeide störende Meldungen, die tiefer liegende Diagnosen wiederholen. Erläutere in Kommentaren, warum eine Einschränkung oder Umgehungslösung besteht, nicht das, was gut benannter Code bereits ausdrückt. Verwende das maßgebliche Formatierungswerkzeug des Repositorys. Wenn ein `pre-commit`- oder `pre-push`-Hook den betreffenden Bereich bereits formatiert, überlasse ihm diese Aufgabe, statt die Formatierung doppelt auszuführen. Wenn kein Hook die Änderung abdeckt, führe den engsten Modus des Formatierungswerkzeugs aus, der zur vorgesehenen Übergabe passt. Formatiere nicht wegen einer einzigen geänderten Datei das ganze Repository. Richte jede vorgeschlagene Änderung auf einen einzigen Zweck aus, damit Prüfung, Rücknahme und Auswirkungen auf andere Sprachanbindungen nachvollziehbar bleiben. ## Prüfe, ob Build und Tests wirklich liefen, und melde, was nicht laufen konnte Vor dem Abschluss: 1. bestätige, dass sich das geänderte Ziel mit der hermetischen Werkzeugkette erstellen lässt; 2. führe die gezielten Tests aus und prüfe, ob sie das beabsichtigte Verhalten tatsächlich ausgeübt haben; 3. führe die maßgebliche Prüfung der Formatierung oder statischen Analyse aus; 4. untersuche den Änderungsvergleich auf nicht zugehörige Änderungen und erzeugte Ausgaben; 5. beurteile die Folgen für Kompatibilität und Kennzeichnung als veraltet; 6. vergleiche bei für Benutzer sichtbaren Änderungen mindestens eine weitere Sprachanbindung; 7. ermittle jeden berührten gemeinsam genutzten Bereich mit besonders hohem Risiko. Berichte, was geändert wurde, welche Ziele und Tests tatsächlich ausgeführt wurden, was nicht ausgeführt werden konnte und warum. Weise auf besonders riskante Dateien, gemeinsam genutztes Verhalten, Auswirkungen auf andere Sprachanbindungen und noch ausstehende Arbeiten hin. Behaupte keine umfassende Kompatibilität aufgrund des Tests einer einzigen Sprachanbindung. Melde den Abschluss bei nicht verfügbarer hermetischer Werkzeugkette nicht, ohne die unvollständige Prüfung deutlich zu kennzeichnen.