Ein Full-Stack-Repository mit seinen eigenen Befehlen und Tests ändern

## Zuerst die Dokumentation lesen und auf einem Branch mit Pull-Request arbeiten Lesen Sie die repositoryweiten Vorgaben, die Dokumentation der Teilsysteme, die Paketmanifeste und nahe gelegene Implementierungen, bevor Sie eine Änderung planen. Ermitteln Sie jeden betroffenen Bereich, darunter Benutzeroberfläche, API, SDK, CLI, Datenbank, Container und Dokumentation. Behandeln Sie den geschützten Standardzweig bei der direkten Entwicklung als schreibgeschützt. Erstellen Sie einen aussagekräftig benannten Zweig, nehmen Sie sinnvolle Commits vor und eröffnen Sie einen Änderungsantrag zur Prüfung. Schreiben Sie die gemeinsame Historie nicht durch die nachträgliche Änderung eines Commits um, und führen Sie Ihren eigenen Änderungsantrag nicht zusammen, wenn der Arbeitsablauf diese Entscheidung einer prüfenden Person zuweist. Beschränken Sie den Zweig auf das angeforderte Verhalten. Trennen Sie nicht damit zusammenhängende Bereinigungen ab und bewahren Sie etablierte Muster, sofern die Aufgabe keine bewusste Änderung erfordert. ## Die eigenen Befehle und festen Laufzeitversionen des Repositorys verwenden Ermitteln Sie die dokumentierten Befehle für Entwicklung, Formatierung, statische Prüfung, Tests, Migrationen und Start, bevor Sie sie ausführen. Verwenden Sie den Befehl des betroffenen Pakets, statt ihn durch ein Werkzeug für das gesamte Repository zu ersetzen. Halten Sie festgeschriebene Versionen der Laufzeitumgebung und vorhandene Umgebungen ein; eine neuere Hauptversion der Laufzeitumgebung wird nicht automatisch unterstützt. Installieren Sie Abhängigkeiten nur, wenn sie fehlen. Starten Sie weder den vollständigen Anwendungsverbund noch Container oder lang laufende Server, sofern die Aufgabe oder die erforderliche Prüfung dies nicht verlangt. Führen Sie Formatierer und statische Prüfwerkzeuge mit den jeweils dokumentierten Modi für die geänderten Dateien aus. Beginnen Sie mit der unterstützten Auswahl eines einzelnen Tests und erweitern Sie die Prüfung anschließend nur auf die unmittelbar betroffene Testreihe. Wenn ein Teilsystem ein installiertes SDK-Paket statt dessen Quellbaums importiert, installieren Sie das SDK nach einer Änderung erneut und starten Sie den nutzenden Prozess neu. Prüfen Sie erforderliche Ports und Voraussetzungen, bevor Sie kombinierte Entwicklungsprozesse starten. ## Die Aufgaben von Oberfläche, API, Diensten und Migrationen getrennt halten Ordnen Sie die Zuständigkeiten vor der Bearbeitung zu: - Die Benutzeroberfläche ist für Darstellung und clientseitigen Zustand zuständig; - die API ist für Anfragevalidierung und Transportbelange zuständig; - Dienstmodule sind für die Geschäftslogik zuständig; - SDK- und CLI-Pakete sind für ihre öffentlichen Schnittstellenverträge zuständig; - Migrationen sind für die Weiterentwicklung der Datenbank zuständig. Lesen Sie die Dokumentation des zu ändernden Teilsystems und prüfen Sie ähnliche vorhandene Dateien, bevor Sie ein neues Muster einführen. Wenn eine Änderung mehrere Schichten berührt, gehen Sie in kleinen Schritten vor: Definieren Sie Typen oder Schemata, implementieren Sie die Dienstlogik, stellen Sie den API-Vertrag bereit, aktualisieren Sie den Client und erstellen Sie anschließend die Benutzeroberfläche. Installieren Sie eine Abhängigkeit in dem Paket, das sie verwendet. Wenn Sie ein Arbeitsbereichspaket hinzufügen, aktualisieren Sie jedes Manifest für die Containererstellung in Produktion und lokaler Entwicklung, das Paketmetadaten vor der Installation von Abhängigkeiten kopiert. ## Die Regeln für TypeScript, Python und die Datenbank einhalten Verwenden Sie strenge TypeScript-Typen, vermeiden Sie zu weit gefasste Typen, definieren Sie Komponenten- und API-Verträge eindeutig und folgen Sie den etablierten Mustern des Repositorys für Komponenten und Zustandsverwaltung. Bevorzugen Sie funktionale Komponenten und ausdrückliche Zustandsaktionen gegenüber dem Weiterreichen von Eigenschaften durch viele Ebenen. Versehen Sie bei Python-Code jede Funktionsgrenze mit Typangaben, verwenden Sie Validierungsmodelle für die Serialisierung und belassen Sie die Geschäftslogik in Diensten statt in Transportroutern. Router sollen Anfragen validieren, Dienste aufrufen und Antworten formen. Befolgen Sie die vorhandenen Regeln für Tabellen und Migrationen, einschließlich eines etwaigen Verbots von Fremdschlüsseln. Halten Sie Datenbankoperationen über alle unterstützten Datenbank-Engines hinweg portabel. Verwenden Sie für Zeitstempelfelder die UTC-Hilfsfunktion des Repositorys statt Ortszeit, veralteter APIs oder selbst erstellter Umrechnungen. Respektieren Sie die Entscheidung des Repositorys für die Speicherung im Dateisystem oder in der Datenbank. Verschieben Sie synchronisierte Clusterdaten nicht nur der Bequemlichkeit halber in eine Datenbank. ## Jede Änderung in ihrer Schicht und ihrer Testsammlung testen Verwenden Sie das Testsystem, das für das jeweilige Teilsystem tatsächlich eingerichtet ist. Wenn für die Benutzeroberfläche kein System für Komponententests vorhanden ist, decken Sie ihr Verhalten mit der vorgesehenen Ende-zu-Ende-Testreihe ab, statt einen nicht unterstützten Testausführer einzuführen. Legen Sie serverseitige Komponenten- und Diensttests im dafür etablierten Verzeichnisbaum ab und führen Sie nach Änderungen am CLI-Quellcode die CLI-Testreihe aus. Simulieren Sie externe Speicher, Rechenanbieter und Dateisysteminteraktionen, damit die Tests schnell und deterministisch bleiben. Bevorzugen Sie direkte Diensttests für Geschäftsregeln, die nicht den vollständigen API-Verbund erfordern. Führen Sie zuerst einen gezielten Test und anschließend die relevante Testreihe des Teilsystems aus. Sorgen Sie dafür, dass wiederholte Durchläufe mit vorhandenen Daten sicher sind, verwenden Sie stabile Selektoren und erlauben Sie realistische Zeitüberschreitungen für Arbeiten in Warteschlangen oder Zustandsübergänge. Leiten Sie einen Erfolg nicht allein aus dem Namen eines Befehls ab. Bestätigen Sie, dass die vorgesehenen Testdateien erkannt wurden und das Ergebnis das geänderte Verhalten tatsächlich ausübt. ## Geänderte Seiten im Browser prüfen und API-Aufrufe mit Anmeldung testen Verwenden Sie das vom Repository zugelassene interaktive Browserwerkzeug für die Sichtprüfung. Nutzen Sie automatisierte Ende-zu-Ende-Skripte nur innerhalb der gepflegten Testreihe oder auf ausdrückliche Anforderung. Starten Sie ausschließlich die erforderliche Testanwendung, rufen Sie die geänderten und unmittelbar zugehörigen Seiten auf, erfassen Sie Nachweise und beheben Sie sichtbare Regressionen. Bevorzugen Sie Selektoren nach Rolle, exaktem Text und Platzhalter. Berücksichtigen Sie wiederholt vorhandene Testdaten, ohne eine leere Datenbank vorauszusetzen. Von einem Terminalemulator dargestellte Inhalte sind möglicherweise nicht im DOM vorhanden; prüfen Sie sie bei Bedarf über die zugrunde liegende API. Verwenden Sie für authentifizierte API-Prüfungen die dokumentierte Testidentität und den dokumentierten Authentifizierungsablauf. Übermitteln Sie erforderliche Header für den Konto- oder Mandantenbereich, unterscheiden Sie geschützte von ungeschützten Endpunkten und hinterlegen Sie wiederverwendbare Zugangsdaten niemals im Quellcode, in Protokollen oder in der daraus entstehenden Dokumentation. ## Abhängigkeiten vorsichtig hinzufügen und keine Passwörter in Logs lassen Prüfen Sie Paketmanifeste, bevor Sie Abhängigkeiten hinzufügen, und verwenden Sie den Installationsablauf des Repositorys. Lassen Sie automatische Formatierungs- und statische Prüfungen vor Commits aktiv, wenn das Projekt darauf angewiesen ist. Behandeln Sie Überschreibungen von Abhängigkeiten als vorübergehende Sicherheitsmaßnahmen, nicht als dauerhafte Zierde. Prüfen Sie beim Aktualisieren eines übergeordneten Pakets, ob die Überschreibung entfernt werden kann, führen Sie die relevante Schwachstellenprüfung aus und behalten Sie die Überschreibung bei, wenn die aufgelöste Abhängigkeit weiterhin unsicher ist. Erweitern Sie bei Integrationstests nicht die Offenlegung von Zugangsdaten. Simulieren Sie externe Anbieter, wenn deren reales Verhalten nicht Gegenstand des Tests ist, und halten Sie Protokolle frei von Zugriffstoken, Passwörtern und personenbezogenen Kennungen. ## Vor dem Abschluss die Änderungen prüfen und die Nachweise berichten Lesen Sie vor der Planung, setzen Sie die kleinste in sich geschlossene Änderung um und prüfen Sie jede betroffene Grenze, bevor Sie den Umfang erweitern. Halten Sie bei größeren Änderungen die Abfolge ausdrücklich und prüfbar, statt serverseitige, API-, Client- und Oberflächenarbeiten in einem undurchsichtigen Schritt zu vermischen. Prüfen Sie vor der Fertigmeldung die Änderungsübersicht und führen Sie die relevanten Formatierungs-, statischen und Typprüfungen, Tests, Migrationsprüfungen sowie die für die geänderten Bereiche erforderliche Sichtprüfung durch. Fügen Sie nicht nur des Anscheins wegen einen vollständigen Erstellungsprozess oder eine nicht zugehörige Testreihe hinzu. Berichten Sie, was geändert wurde, welche Prüfungen liefen, welche umfassenderen Prüfungen außerhalb des Umfangs blieben und welches Restrisiko besteht. Für den Abschluss sind Nachweise aus dem geänderten Verhalten erforderlich, nicht nur eine erfolgreiche Bearbeitung.