Kleine, getestete Änderungen in einem großen TypeScript-Monorepo vornehmen

## Vor dem Bearbeiten Aufbau und Werkzeuge des Repositorys erfassen Behandle den maßgeblichen Agentenleitfaden des Repositorys als einzige Anweisungsquelle. Halte alternative Einstiegspunkte für Agenten als knappe Verweise und aktualisiere den maßgeblichen Leitfaden, wenn sich Architektur, Werkzeuge, Versionen, Arbeitsabläufe oder Regeln für Mitwirkende ändern. Ermittle: - das tatsächliche Stammverzeichnis des Repositorys, den Hauptquellbereich, den Bereich für Erstellungsskripte, die Dokumentation, Testanwendungen und erzeugte Arbeitsbereiche; - den erforderlichen Ausgangszweig, die Laufzeitversion, die Paketverwaltung, die Aufgabensteuerung, die Werkzeuge für statische Prüfung und Formatierung sowie die in der kontinuierlichen Integration verwendeten Betriebssysteme; - öffentlich vorgesehene gegenüber ausdrücklich internen Exporten; - paketspezifische Typprüfungen und eine mögliche Aufteilung der Compilerversionen zwischen Repository-Prüfungen, Editorwerkzeugen und nachgelagerten API-Nutzern. Halte gemeinsam genutzte Konfigurationen für jeden unterstützten Compilerpfad gültig. Übernimm eine Option oder Syntax nicht allein deshalb, weil die neueste Typprüfung sie akzeptiert. Unterscheide bei modularen Oberflächenwerkzeugen zwischen Laufzeitdarstellung, Bündelungswerkzeugen und Framework-Integrationen, die beides mit der Framework-Konfiguration verbinden. Bewahre eine auf schnellen Start ausgelegte Architektur, etwa durch statische Indizierung vor dem Laden zur Laufzeit; ein einziges ungültiges Benutzermodul darf nicht die gesamte Navigations- oder Verwaltungsoberfläche zum Ausfall bringen. ## Nur die Builds und Prüfungen ausführen, die die Änderung braucht Führe Befehle im dokumentierten Arbeitsverzeichnis aus und verwende beim Ansprechen des Aufgabengraphen die Projektnamen des Arbeitsbereichs statt der veröffentlichten Paketnamen. Beginne mit zwischenspeicherfähigen, abhängigkeitsbewussten Aufgaben außerhalb der Produktionskonfiguration: 1. Kompiliere das betroffene Projekt oder die betroffene Paketmenge; 2. führe gezielte Typprüfungen aus; 3. formatiere und prüfe geänderte Dateien statisch; 4. führe die nächstliegenden einschlägigen Tests aus; 5. überprüfe das Verhalten in der internen Entwicklungsoberfläche. Weite die Prüfung nur dann auf Produktionskonfigurationen, erzeugte Prüfumgebungen oder Abläufe mit CI-Gleichstand aus, wenn die Änderung von Vorlagenintegration, Produktionsverdrahtung des Aufgabengraphen oder paketübergreifendem Verhalten abhängt. Beachte Aufgabenabhängigkeiten, sofern du nicht bewusst ab einer späteren, bereits überprüften Phase fortsetzt. Starte lang laufende Entwicklungsserver nicht standardmäßig. Befehle, die eine Vorlage, ein Ziel oder eine Umgebung benötigen, müssen diese ausdrücklich erhalten. Wenn eine erzeugte Prüfumgebung fehlschlägt, verwende die dokumentierte interne Oberfläche zur Fehlerdiagnose, bevor du die Erstellungsarchitektur änderst. ## Die Testart nach dem Code wählen und verhindern, dass sich Tests gegenseitig beeinflussen Stimme die Testform auf das Verhalten ab: - Prüfe dargestellte Komponenten über direkt zugeordnete Stories und Interaktionsfunktionen, einschließlich Barrierefreiheit und Nutzerverhalten; - verwende Modultests für reine Hilfsfunktionen, Hooks und Module ohne Darstellung; - verwende visuelle Werkzeuge für das Erscheinungsbild; - verwende Ende-zu-Ende-, Kurz- oder Ausführungstests für Integrationsverträge. Prüfe exportiertes Verhalten und beobachtbare Nebenwirkungen, nicht private Umsetzungsdetails. Prüfe Zusicherungen nicht doppelt, wenn sie bereits durch Typen, statische Prüfregeln, Story-Interaktionen oder übergeordnete Browsertests durchgesetzt werden. Bevorzuge bei Dateisystemcode ein Dateisystem im Arbeitsspeicher gegenüber echten temporären Verzeichnissen oder dem vollständigen Ersetzen von Modulen. Setze den virtuellen Zustand vor jedem Test zurück, leite nur die erforderlichen Dateisystemmethoden um und prüfe bei Bedarf den Zustand des virtuellen Datenträgers. Weise globale Werte in Tests niemals direkt zu. Verwende die nachverfolgten Platzhalter des Testsystems für globale Werte und stelle sie nach jedem Test wieder her, auch bei Schlüsseln, die zuvor nicht vorhanden waren. Direkte Zuweisungen verursachen dateiübergreifende Lecks, deren Wirkung von der Ausführungsreihenfolge abhängt. Normalisiere erwartete Pfade mit den Pfadwerkzeugen der Laufzeit, damit Dateisystemprüfungen sowohl unter Unix als auch unter Windows bestehen. ## Annahmen zuerst prüfen und keine unnötigen Abstraktionen einbauen Überprüfe Umgebungsannahmen mit einer kleinen, vorübergehenden Probe, bevor du die Architektur darauf stützt. Verwandle eine ungeprüfte Vermutung über Bündelungswerkzeuge, Metadaten, Ladevorgänge oder erzeugte Ausgaben nicht in einen dauerhaften Kommentar oder eine dauerhafte Abstraktion. Drücke beständige Annahmen zuerst durch Typen und vorhandene statische Prüfregeln aus. Falls eine statische Durchsetzung unpraktisch ist, füge an der Grenze eine kostengünstige Laufzeitprüfung hinzu, damit Verstöße nahe ihrer Ursache fehlschlagen. Bevorzuge Entfernen und Direktheit gegenüber spekulativer Flexibilität. Füge keine Abstraktionen, Ausweichlösungen oder Erweiterungspunkte für Nutzer hinzu, die es nicht gibt. Kommentare sind Wartungsdokumentation, keine Untersuchungsprotokolle. Erkläre den dauerhaften Grund in ein oder zwei Sätzen; lasse Vorgangscodes, den Verlauf von Proben, Erzählungen über Bytevergleiche und empfindliche Zeilennummernverweise weg. Decke Randfälle bei sicherheitskritischen Pfaden und Altdatenmigrationen umfassend ab. Begrenze Kompatibilitätscode auf ein ausdrücklich festgelegtes Versionsfenster, damit er nach dem Ende der Unterstützung entfernt werden kann. ## Erzeugte Dateien nicht ohne Grund ändern und die vorgegebene Formatierung und Protokollierung nutzen Führe nach der Bearbeitung die Repository-Formatierung aus, prüfe anschließend die geänderten Dateien statisch und führe die einschlägigen Tests aus. Verwende die eingerichteten Werkzeuge; ersetze keine stillgelegten Prüfwerkzeuge und formatiere keinen Code von Hand, dessen Formatierung das vorgesehene Werkzeug übernimmt. Führe neue TypeScript-Skripte über den aktuellen nativen Ausführungspfad des Repositorys aus und verwende ausdrücklich angegebene TypeScript-Dateiendungen in Importen, sofern dies eingerichtet ist. Stelle ältere Ladeverfahren nur innerhalb des bearbeiteten Bereichs um. Verwende im normalen Server- und Clientcode die Protokollierungsabstraktion des Projekts. Nutze unmittelbare Konsolenaufrufe nur in eigenständigen Skripten, bei denen das Einbinden der Protokollierung unverhältnismäßig wäre. Übertrage niemals versehentliche Änderungen an erzeugten Dateien. Ein erzeugtes Artefakt darf sich nur ändern, wenn dies eine deterministische Folge einer beabsichtigten Quelländerung in derselben Arbeit ist. Andernfalls lasse es unberührt und melde wiederkehrende Abweichungen des Erzeugungswerkzeugs. Berücksichtige Unix und Windows bei Pfaden, Unterprozessen und Tests. Behandle die Betriebssystemabdeckung der kontinuierlichen Integration als Kompatibilitätsanforderung, nicht als freiwillige Aufräumarbeit. ## Eine Änderung nicht nach dem Kompilieren abhaken, sondern ihr Verhalten prüfen Für eine gewöhnliche Änderung: 1. installiere Abhängigkeiten nur bei Bedarf; 2. kompiliere den einschlägigen Abhängigkeitsgraphen; 3. nimm die kleinste zusammenhängende Änderung vor; 4. kompiliere die betroffenen Pakete erneut; 5. führe gezielte Typprüfungen, Formatierung, statische Prüfung und vertraglich passende Tests aus; 6. überprüfe die Änderung in der internen Oberfläche; 7. ergänze Prüfungen in einer erzeugten Umgebung oder mit Produktionsgleichstand nur, wenn sie unmittelbar relevant sind. Bearbeite bei der Integration eines Darstellungsmoduls, Frameworks, Erstellungswerkzeugs oder einer Erweiterung das zuständige Paket, kompiliere es zunächst ohne Produktionsmodus und prüfe es anschließend mit einer passenden erzeugten Anwendung sowie dem einschlägigen Ausführungs- oder Ende-zu-Ende-Ablauf. Wenn eine Erstellung fehlschlägt, aktualisiere die Abhängigkeiten und wiederhole die gezielte Kompilierung, bevor du den verfügbaren Arbeitsspeicher erhöhst oder die Architektur änderst. Untersuche erzeugte Ausgaben und Zwischenspeicher, wenn sich das Verhalten in der erzeugten Prüfumgebung von der internen Oberfläche unterscheidet. Leite Einsatzbereitschaft nicht allein aus erfolgreicher Kompilierung ab. Als Nachweis ist die kleinste Prüfmenge erforderlich, die die geänderte Paketgrenze, unterstützte Compilerpfade, beobachtbares Verhalten, plattformübergreifende Annahmen und den unmittelbar betroffenen Integrationsablauf abdeckt.