Ein großes Plattform-Monorepo ändern und alle betroffenen Clients synchron halten

## Erst die Regeln im Root, dann die Anweisungen jedes Ordners lesen Nutze das Wurzelverzeichnis des Quelltextbestands als Koordinationspunkt und die nächstgelegene lokale Anweisungsdatei als aufgabenspezifische Instanz. Wende zuerst die Regeln des Wurzelverzeichnisses an und ergänze danach die Regeln, die jedes betroffene Verzeichnis verwaltet, statt anzunehmen, die Konventionen eines einzelnen Moduls bestimmten die gesamte Änderung. Für Bereiche ohne lokale Anweisungsdatei dienen der nächstgelegene gepflegte Entwicklungsleitfaden, die `README` des Moduls und der Ablauf für kontinuierliche Integration als nächste maßgebliche Quellen. Lies jeden zutreffenden Leitfaden, bevor du eine bereichsübergreifende Änderung bearbeitest. ## Vor dem Bearbeiten klären, welches Modul für welchen Teil zuständig ist Ermittle, welche Module für die Steuerungsebene, Laufzeitbestandteile, öffentlichen Spezifikationen, Zugriffsbibliotheken, Bereitstellungsressourcen, Befehlszeilenschnittstelle, durchgängigen Tests, Dokumentation, Beispiele und Architekturvorschläge zuständig sind. Ordne das Verhalten von Lebenszyklus und Konfiguration dem Eigentümer der Steuerungsebene zu, das Verhalten von Laufzeitprozessen dem nächstgelegenen Komponentenleitfaden, Änderungen öffentlicher Schemata dem Eigentümer der Spezifikation und die Erzeugung von Zugriffsbibliotheken deren Eigentümer. Ordne das Bereitstellungsverhalten dem zuständigen Betreiber oder dem Eigentümer der Paketierung und das Befehlsverhalten dem Eigentümer der `CLI` zu. Beginne bei einer Änderung, die Vertrag, Umsetzung und angebundene Anwendungen umfasst, mit der öffentlichen Spezifikation und lade danach die Leitfäden aller betroffenen Abnehmer. Richte die `API` der Komponenten, Prüfannahmen und Bereitstellungsanbindung am selben Vertrag aus. ## Ziel bestätigen und nur die nötigen Zeilen ändern Benenne Annahmen, lege Mehrdeutigkeiten offen und frage nach der Richtung, wenn die Anfrage widersprüchliche Auslegungen zulässt. Überführe nichttriviale Arbeiten vor der Umsetzung in beobachtbare Erfolgskriterien und halte an, wenn eine Entscheidung erforderlich ist. Wähle die kleinste Lösung, die die Anfrage erfüllt. Vermeide spekulative Funktionen, einmalige Abstraktionen, unnötige Konfigurierbarkeit, sachfremde Umstrukturierungen und das Entfernen bereits vorhandener Arbeit. Ändere nur die für die Aufgabe erforderlichen Dateien und Zeilen, halte dich an den lokalen Stil, füge bei Verhaltensänderungen zielgerichtete Prüfungen hinzu oder aktualisiere sie und arbeite weiter, bis die Prüfungen erfolgreich sind oder das verbleibende Hindernis ausdrücklich benannt ist. ## Clients und Doku anpassen, wenn sich die öffentliche Spezifikation ändert Behandle öffentliche Spezifikationen als maßgebliche Vertragsquellen. Wenn sich für Benutzer sichtbares Verhalten ändert, halte Spezifikation, Umsetzung, Zugriffsbibliotheken, Dokumentation, Beispiele, Konfiguration, Befehlsverhalten und Veröffentlichungsergebnisse miteinander synchron. Wenn sich Bereitstellungs-`API` oder Orchestrierungsressourcen ändern, aktualisiere oder prüfe außerdem erzeugte Manifeste, Bereitstellungspakete, das Verhalten der Steuerungskomponente, die Anbindung der Dienstsysteme und die Betriebsdokumentation. Lass einen Vertrag ohne ausdrückliche Freigabe nicht absichtlich von der Umsetzung abweichen. Aktualisiere die Dokumentation für Benutzer und Betrieb vor oder zusammen mit der Umsetzung, damit das dokumentierte Verhalten weiterhin das maßgebliche öffentliche Versprechen bleibt. ## Die Quelle korrigieren und generierte Dateien neu erzeugen Bearbeite niemals nur das erzeugte Ergebnis, um eine Korrektur vorzunehmen. Ermittle und ändere das maßgebliche Schema, die Vorlage, die Konfiguration oder die Eingabe des Erzeugungswerkzeugs und erzeuge anschließend über den unterstützten Ablauf alle betroffenen Zugriffsbibliotheken, Manifeste, Verweise, Beispiele und Paketbestandteile neu. Prüfe die erzeugten Änderungen auf unerwartete Abweichungen und überprüfe nachgelagerte Abnehmer anhand des neu erzeugten Vertrags. Halte von Hand geschriebene Anpassungsschichten von erzeugtem Quelltext getrennt und bewahre die Zuständigkeitsgrenze des Quelltextbestands zwischen beiden. Wenn die Neuerzeugung blockiert ist, melde das fehlende Werkzeug oder die fehlende Umgebung und belasse Quelle und abgeleitete Ergebnisse in einem klar gekennzeichneten unvollständigen Zustand, statt sie als synchron darzustellen. ## Vor inkompatiblen öffentlichen Änderungen nachfragen Bevorzuge für öffentliche `API`, Schnittstellen angebundener Anwendungen, Konfiguration, Protokolle, Befehlsverhalten, Bereitstellungsressourcen, Anmerkungen, Kennzeichnungen und Paketwerte ergänzende, rückwärtskompatible Änderungen. Frage nach, bevor du eine inkompatible öffentliche Änderung vornimmst, eine absichtliche Vertragsabweichung einführst oder sichtbares Verhalten ohne klaren Umstellungsweg änderst. Beschreibe betroffene Abnehmer, Kompatibilitätsauswirkungen, Umstellungsanforderungen und Folgen für die Veröffentlichung, bevor du um Freigabe bittest. Verbirg niemals eine inkompatible Änderung in erzeugten Änderungen und vermische keine sachfremde Komponentenarbeit mit derselben Änderung. Halte die genehmigte Kompatibilitätsentscheidung in Umsetzung, Dokumentation, Prüfungen und Veröffentlichungshinweisen ausdrücklich fest. ## Zuerst im kleinsten Umfang prüfen, dann ausweiten Führe vor einer umfangreicheren Prüfung Formatierungswerkzeuge, statische Prüfwerkzeuge, Modultests, Vertragsprüfungen und Zusicherungen für Befehlsausgaben auf Datei- oder Paketebene aus. Erweitere die Prüfung auf Integration, sprachübergreifende Abläufe, Bereitstellung oder Dokumentationserstellung, wenn die Änderung diese Grenzen überschreitet. Prüfe Befehlshilfe und -ausgabe zusammen mit `CLI`-Prüfungen, Vertragsbeispiele zusammen mit Schemaprüfungen, das Verhalten angebundener Anwendungen in allen unterstützten Sprachen und das Bereitstellungsergebnis auf der betroffenen Plattform. Aktualisiere zielgerichtete Prüfungen, wenn sich Verhalten ändert oder ein Fehler behoben wird. Nenne in der abschließenden Übergabe jede nicht ausgeführte oder blockierte Prüfung. Behaupte keinen Abschluss, solange eine erforderliche Prüfung fehlschlägt oder ein betroffener Abnehmer ohne ausdrücklich benannte Einschränkung ungeprüft bleibt. ## Jede Doku an einem Ort halten und verlinken statt kopieren Pflege ausführliche Anleitungen für Benutzer und Betrieb im dafür vorgesehenen Dokumentationsbaum. Verwende die `README` im Wurzelverzeichnis nur als Einstieg in den Quelltextbestand und die `README` veröffentlichbarer Pakete für Installation, Schnelleinstiege und Paketeinstiege. Halte die `README` interner Bestandteile knapp, wenn eine gepflegte Dokumentationsseite vorhanden ist. Lege ausführbare Beispiele im Beispielbaum und die zugehörigen Erläuterungsseiten im Dokumentationsbaum ab. Nutze Vorschlagsdokumente als maßgebliche Quelle und Gemeinschaftsseiten nur als Verzeichnisse, wenn dies der Konvention des Quelltextbestands entspricht. Verweise auf Gemeinschafts- und Entwicklungsrichtlinien, statt sie zu vervielfältigen. Bevorzuge aus Dateien des Quelltextbestands versionsbezogene Verweise, damit die Dokumentation dem aktuell gewählten Entwicklungszweig oder der Versionsmarke folgt, und verwende einen öffentlichen Netzauftritt nicht als einzige Quelle aus versionsverwaltetem Quelltext. ## Seitenregeln der Doku-Website einhalten und fehlerfrei bauen Nutze das eingerichtete Dokumentationswerkzeug und die Konfiguration des statischen Netzauftritts, ohne eine nicht dokumentierte Erzeugung während des Erstellungsvorgangs einzuführen. Lege Bilder im vorgesehenen öffentlichen Ressourcenverzeichnis ab und verweise nach der zugelassenen Pfadkonvention des Netzauftritts auf sie. Gib jeder veröffentlichten Seite die erforderlichen Metadaten, verwende die eingerichtete Form interner Verweise und vollständige Quellenverweise für Ziele außerhalb des Dokumentationsbaums. Wende zugelassene Hinweisblöcke, Quelltextgruppen und Navigationskonventionen einheitlich an. Schließe ausschließlich für Mitwirkende bestimmte Anweisungen vom veröffentlichten Netzauftritt aus. Füge übersetzte Fassungen nur dort hinzu, wo die Lokalisierungsrichtlinie dies erlaubt, und führe die Dokumentationserstellung fehlerfrei aus, bevor du veröffentlichungsreife Änderungen als abgeschlossen betrachtest. ## Inkompatible Änderungen prüfen und offene Risiken melden Prüfe vorrangig inkompatible Änderungen an öffentlichen Spezifikationen, Schnittstellen angebundener Anwendungen, Konfiguration, Befehlsverhalten, Bereitstellungsressourcen und Protokollen. Kennzeichne Änderungen, die unnötig, in sich widersprüchlich, für Abnehmer schwer umzusetzen oder ohne glaubwürdigen Umstellungsweg sind. Prüfe auf durchbrochene Grenzen maßgeblicher Quellen, Verletzungen der Schichtenarchitektur, veraltete erzeugte Ergebnisse, fehlende Prüfungen, nicht dokumentiertes Verhalten und Kompatibilitätsrückschritte. Trenne bestätigte Fehler von ungeprüften Risiken und benenne den betroffenen Vertrag oder Abnehmer. Schließe mit einem nachweisgestützten Bericht über geänderte Bereiche, synchronisierte Abnehmer, ausgeführte Prüfungen, blockierte Überprüfungen, Kompatibilitätsentscheidungen und verbleibende Risiken.