Code in einem Full-Stack-Monorepo ändern, ohne gemeinsame Pakete zu beschädigen

## Jede Änderung in das zuständige Modul legen Verschaffe dir vor der Bearbeitung einen Überblick über den Arbeitsbereich. Unterscheide Produktanwendungen, wiederverwendbare UI-Pakete, gemeinsam genutzte Geschäftslogik, Datenschemata und Migrationen, Typpakete, Konfigurationsvorgaben, Dokumentation, Bereitstellungsressourcen und Testgerüste. Lege funktionsspezifisches Verhalten in der zuständigen Anwendung oder im zuständigen Funktionsmodul ab. Lege wiederverwendbare Domänenlogik und gemeinsame Typen in Paketen mit eindeutig benannten Verbrauchern ab. Halte Infrastruktur und Begleitmaterial für die Bereitstellung vom Laufzeitquellcode getrennt. Ordne Unit-Tests der stabilen Logik zu, die sie prüfen; Spezifikationen für Browserabläufe gehören dagegen in den End-to-End-Bereich der Anwendung. Du darfst gemeinsame Logik nicht allein deshalb innerhalb einer Anwendung duplizieren, um die Änderung eines Pakets zu vermeiden. Halte die Abhängigkeitsrichtung ein und überprüfe bei Änderungen an einem gemeinsamen Paket jeden nachgelagerten Verbraucher. ## Vorkompilierte Pakete neu bauen und veraltete Caches umgehen Ermittle Pakete, die vorkompiliert und in die öffentlichen Ressourcen einer Anwendung kopiert werden. Eine laufende Anwendung kann statt des Quellcodes die Distributionsausgabe des Pakets importieren. Eine reine Quellcodeänderung ist daher möglicherweise nicht sichtbar. Nach der Änderung eines vorkompilierten Pakets oder einer Abhängigkeit, die dessen Bundle beeinflusst: 1. entferne ausschließlich die bekannten Distributionsausgaben des Pakets und die kopierten Artefakte; 2. umgehe den Zwischenspeicher des Buildsystems für den betroffenen Abhängigkeitsgraphen; 3. erstelle das Paket über seine offizielle Arbeitsbereichsaufgabe neu; 4. aktualisiere oder deaktiviere den Browser-Zwischenspeicher; 5. starte den Entwicklungsserver nur dann neu, wenn die neu erstellte Ressource weiterhin nicht geladen wird. Bearbeite kopierte Bundles oder erzeugte Artefakte niemals von Hand. Behandle die Ungültigmachung des Zwischenspeichers als Teil des Prüfverfahrens und nicht als Beleg dafür, dass die Quellcodeänderung fehlgeschlagen ist. ## Gemeinsame Lint- und Typregeln einhalten Verwende die gemeinsamen Lint-, Formatierungs- und Compiler-Vorgaben des Repositorys anstelle lokaler Überschreibungen. Halte die festgelegten Regeln für Einrückung, Zeilenbreite, Anführungszeichen, Semikolons und Importgruppen ein. Benenne Komponenten und Komponentenordner einheitlich, verwende Lower Camel Case für Funktionen und Variablen und reserviere Upper Snake Case für echte Konstanten. Lege Mocks am dafür vorgesehenen Ort ab, damit Auflösung und Importreihenfolge stabil bleiben. Bevorzuge abgeleitete Typen, solange sie eindeutig bleiben, verwende gemeinsame Domänentypen und vermeide untypisierte Auswege. Behandle Komponenteneigenschaften als unveränderlich. Halte Komponenten fokussiert und Effekte eng begrenzt, pflege korrekte Hook-Abhängigkeiten und begründe Memoisierung mit einem gemessenen Bedarf statt mit Gewohnheit. ## Serverlogik trennen und Cache-Schlüssel über eine Fabrik erzeugen Halte Routenzusammenstellung, Dienstlogik und Funktionsmodule getrennt. Serveraktionen müssen Dienste aufrufen und ein einheitliches Erfolgs- oder Fehlerformat zurückgeben. Kontextanbieter müssen bei einer Verwendung außerhalb ihres Providers eindeutig fehlschlagen und Effekte anhand stabiler Momentaufnahmen statt veränderlicher Referenzen bereinigen. Verwende anfragegebundene Memoisierung für doppelte Arbeit innerhalb einer Anfrage. Nutze für aufwendige, anfrageübergreifende Arbeit die genehmigte gemeinsame Cache-Abstraktion oder einen ausdrücklich festgelegten verteilten Cache. Führe keine instabile Cache-API eines Frameworks ein, wenn das Repository sie abgelehnt hat. Erzeuge jeden Cache-Schlüssel über die maßgebliche Schlüsselfabrik. Der Schlüssel muss alle Dimensionen enthalten, die das Ergebnis verändern können, damit Benutzer, Mandanten, Umgebungen, Locales oder Funktionsmodi keine inkompatiblen Einträge gemeinsam nutzen. ## Texte über Übersetzungen führen und Zeitzone von Sprache trennen Führe alle benutzerseitig sichtbaren Texte durch die Übersetzungsfunktion und halte die festgelegte Konvention für kleingeschriebene, durch Punkte getrennte Schlüssel ein. Pflege genau eine Datei des Quell-Locales als einzige von Hand verfasste Übersetzungsquelle. Bearbeite erzeugte Locale-Dateien niemals manuell; führe nach einer Änderung am Quelltext den Lokalisierungsgenerator und die Schlüsselprüfung aus. Stelle benutzerseitig sichtbare Datums- und Zeitangaben über gemeinsame Hilfsfunktionen dar. Beziehe das Anzeige-Locale aus der maßgeblichen Sprachquelle der Anwendung und niemals aus einem impliziten Browserstandard. Behandle Locale und Zeitzone als voneinander unabhängig: Das Locale steuert die Formatierung, die Zeitzone hingegen den dargestellten Zeitpunkt. Leite die Zeitzone niemals aus dem Locale ab. Bewahre die bestehende Bedeutung gespeicherter Werte, sofern das Produkt keine maßgebliche Zeitzonenquelle festlegt. Verwende für Speicherung, APIs, Exporte, Integrationen und Protokolle stabile, nicht lokalisierte Formate wie eine ausdrückliche UTC- oder ISO-Darstellung. ## Daten jeder Organisation trennen und Abfragen schnell halten Begrenze jede Datenoperation durch die Mandantengrenze des Repositorys, etwa Organisation und Umgebung. Wende Filter für logisches Löschen konsequent an, damit inaktive oder gelöschte Datensätze nicht über andere Abfragewege erneut erscheinen. Verwende für Anzahlen eine gefilterte Zählabfrage statt Argumenten für Offset-Paginierung. Führe voneinander unabhängige Zähl- und Datenabfragen gleichzeitig aus. Bevorzuge bei großen Datenmengen Cursor-Paginierung und beziehe bei zeitbasierten Filtern indizierte Eigentumsfelder ein. Überprüfe Schema- und Migrationsänderungen gemeinsam mit jedem betroffenen Abfrageweg. Datentrennung ist eine querschnittliche Invariante: Ein fehlendes Mandantenprädikat ist kein geringfügiges Leistungsproblem, sondern ein möglicher Bruch der Datengrenze. ## Tests nach Risiko für Nutzer wählen, nicht nach Abdeckungszahlen Optimiere auf Vertrauen statt auf einen Abdeckungsprozentsatz: - Verwende Browser-End-to-End-Tests für kritische Benutzerabläufe, UI-Regressionen und Komponentenverhalten. - Verwende Unit-Tests für stabile reine Logik wie Prüfer, Umformer, Auswerter, Berechnungen und Grenzfälle. - Nutze manuelle Prüfungen in der Staging-Umgebung für die Freigabebereitschaft und durchlaufe bei kritischen Befunden eine Schleife aus Fehlerbehebung, Rückportierung und erneutem Test. Halte Browsertests fokussiert, benenne sie eindeutig und kennzeichne langsame Testsammlungen ausdrücklich. Simuliere Netzwerk- und Speichergrenzen über gemeinsame Hilfsfunktionen. Füge keine fragilen Komponenten-Momentaufnahmen, Markup-Prüfungen, Tests von Implementierungsdetails, Zeitsteuerungstricks, übergroßen Abläufe oder aussagearmen Tests hinzu, die ausschließlich die Abdeckung erhöhen sollen. Führe vor der Überprüfung die standardmäßige Unit-Testsammlung aus, ermittle bei Änderungen kritischer Abläufe die Abdeckung und führe für Risiken eines Benutzerablaufs die direkt betroffene End-to-End-Testsammlung aus. ## Dokumentation und Komponentenbeispiele aktuell halten Halte den Dateivertrag, die Metadatenfelder, die Überschriftenregeln und die genehmigten Schritt- oder Hinweiskomponenten des Dokumentationssystems ein. Kennzeichne Inhalte eingeschränkter Editionen mit dem Standardhinweis, statt ein neues Abzeichen oder eine neue Formulierung zu erfinden. Bewahre Komponentenbeispiele neben der Komponente auf und importiere sie über deren öffentlichen Einstiegspunkt. Ordne Bedienelemente in die Standardgruppen des Repositorys ein. Decke den Standardzustand, sofern unterstützt den deaktivierten Zustand und den Symbolzustand, sämtliche Varianten sowie aussagekräftige Grenzfälle ab. Lade vor der Erstellung oder Überprüfung einer UI den Gestaltungskontext für den betroffenen Bereich. Die gemeinsamen Gestaltungsrichtlinien ergänzen die Codekonventionen und bleiben die maßgebliche Quelle für Design-Tokens, Komponenten, Bewegung und visuelle Qualität. ## CI-Workflows nur die nötigen Berechtigungen geben Gewähre Automatisierungstokens ausschließlich die Berechtigungen, die der jeweilige Arbeitsablauf benötigt. Beginne gehostete Linux-Aufträge mit dem genehmigten Schritt zur Runner-Härtung, damit Netzwerk- und Prozessverhalten eingeschränkt sind, bevor Projektcode ausgeführt wird. Behandle Abhängigkeitssperrdateien als maßgeblich und führe Arbeitsbereichsbefehle mit dem vom Repository ausgewählten Paketmanager aus. Vermeide einmalige Installations- oder Buildbefehle, die den Aufgabengraphen, die gemeinsame Umgebung oder Cache-Metadaten umgehen. Überprüfe bei einer Änderung des Arbeitsablaufs Ereignisauslöser, Berechtigungen, die Offenlegung geheimer Werte, Cache-Schlüssel, Artefakte und die Weitergabe von Fehlern. Ein erfolgreicher nachgelagerter Schritt darf keine fehlgeschlagene Voraussetzung verdecken. ## Pull Request mit Testergebnissen und Screenshots übergeben Entferne vor dem Abschluss ungenutzten Code und ungenutzte Imports, führe den maßgeblichen Lint-Befehl aus und absolviere die kleinste Testmenge, die die Änderung belegt, sowie jeden direkt betroffenen umfassenderen Ablauf. Halte Commits fokussiert und mit der Commit-Konvention des Repositorys vereinbar. Ein Pull Request muss das Problem benennen, die Lösung zusammenfassen, auf das maßgebliche Issue oder die Spezifikation verweisen und Migrationen oder Umgebungsänderungen ausweisen. Füge bei UI-Arbeiten visuelle Belege bei und dokumentiere die Ergebnisse der relevanten Lint-, Test-, Build- und Migrationsbefehle. Prüfende müssen erkennen können, was geändert wurde, warum es in dieses Modul gehört, wie erzeugte Ausgaben aktualisiert wurden und welche Risiken geprüft wurden, ohne die Arbeit allein aus dem Diff rekonstruieren zu müssen.