Eine mandantenfähige Automatisierungsplattform bauen, ohne Mandanten oder Editionen zu vermischen

## Mandantendaten trennen und Premiumcode aus der Gemeinschaftsedition heraushalten Behandle Mandantenbereiche, Produkteditionen, Funktionszugriff und Markenauftritt als Verträge für Sicherheit und Verhalten. ### Trennung durchsetzen - Bilde Eigentumsverhältnisse auf Plattform-, Projekt- und Benutzerebene ausdrücklich ab. - Begrenze jede Datenbankabfrage mit der richtigen Projekt- oder Plattformkennung; verlasse dich niemals darauf, dass die aufrufende Stelle die Ergebnisse später filtert. - Verlange für jeden Endpunkt eine Erklärung zur Zugriffskontrolle. - Wende die Autorisierung im Backend und die Funktionsvermittlung vor geschütztem Verhalten an, gib für nicht verfügbare Bezahlfunktionen die standardmäßige Antwort `402` zurück und spiegle dieselbe Sperre in der Schutzprüfung des Frontends und bei der Aktivierung von Abfragen. ### Abhängigkeiten zwischen Editionen gerichtet halten - Premium- oder gehostete Editionen dürfen den Gemeinschaftskern über registrierte Erweiterungspunkte oder Schnittstellen erweitern. - Importiere niemals Anwendungscode, der ausschließlich für die Premiumedition bestimmt ist, in den Gemeinschaftscode. - Halte die Voreinstellungen der Gemeinschaftsedition markenfrei, wende in gehosteten Umgebungen den konfigurierten Markenauftritt an und beschränke den Markenauftritt der selbst gehosteten Unternehmensedition anhand der passenden Tarifberechtigung. - Prüfe das kundenwirksame Verhalten über 5 Pfade: selbst gehostete Gemeinschaftsedition, selbst gehostete Unternehmensedition, kostenlos gehostete Edition, kostenpflichtig gehostete Edition und gehostete Unternehmensedition. - Sorge dafür, dass alle kundenwirksamen Namen, Farben, Logos, Anmeldebildschirme und Nachrichten von der konfigurierten Darstellung bestimmt werden, statt eine Produktmarke fest einzuprogrammieren. ## Abhängigkeiten pro Arbeitsbereich deklarieren und serverübergreifende Daten mit Sperren schützen Lege die Zuständigkeit für Abhängigkeiten und das Verhalten gleichzeitiger Datenvorgänge offen, damit lokale Erfolge der Bereitstellung in der Produktionsumgebung entsprechen. ### Paketgrenzen wahren - Ordne gemeinsame Bibliotheken von schlanken, vom Anwendungsrahmen unabhängigen Grundlagen bis zu umfangreichen Paketen auf Anwendungsebene. - Wiederverwendbare Integrationen und Ausführungsmaschinen dürfen nur von schlanken Paketen abhängen; stelle benötigtes Anwendungsverhalten über eine schmale Rahmenschicht bereit. - Deklariere jede Laufzeitabhängigkeit in dem Arbeitsbereich, der sie importiert, und jede Test- oder Werkzeugabhängigkeit in den Entwicklungsabhängigkeiten dieses Arbeitsbereichs. - Reserviere das Stammmanifest für werkzeugbezogene Anforderungen des gesamten Repositories oder echte Startanforderungen. - Fixiere Versionen einheitlich und aktualisiere nach Änderungen an Abhängigkeiten die Sperrdatei mit dem vorgeschriebenen Installationswerkzeug. ### Persistenz und Nebenläufigkeit schützen - Registriere neue Entitäten ausdrücklich, wenn der Objektmapper sie nicht automatisch erkennt. - Trenne Nebenwirkungen in eigene Module und rufe sie nach erfolgreichen Änderungen ausdrücklich auf. - Verwende bei Arbeiten über mehrere Server eine verteilte Sperre, Warteschlangenentdoppelung oder Zeilensperren mit `skip-locked`-Semantik. - Vermeide Datenbankerweiterungen, die in verwalteten Diensten nicht verfügbar sind. - Bereinige von außen bereitgestellte Objekte, bevor du sie in der Datenbank speicherst. ## Auf any und erzwungene Typumwandlungen verzichten und die gemeinsamen Hilfsfunktionen nutzen Verwende vorhersehbare Schnittstellen, Datenflüsse, Dateiorganisation und gemeinsame Hilfsfunktionen. ### Typintegrität bewahren - Verwende nicht `any`, sondern genaue Typen oder `unknown` zusammen mit Typwächtern. - Erzwinge Werte nicht durch Typumwandlungen. Korrigiere den Ursprungstyp, ergänze eine Prüfung oder grenze den Typ des Werts ein. - Prüfe vor der Nutzung einer API die Bibliotheksdokumentation und ersetze alles, was als veraltet gekennzeichnet ist. - Verwende für jede Funktion mit mehr als 1 Parameter einen einzelnen destrukturierten Objektparameter. - Bevorzuge unveränderliche Datenflüsse über Funktionsgrenzen hinweg; erstelle und liefere neue Sammlungen zurück, statt Objekte der aufrufenden Stelle zu verändern. ### Konventionen ausdrücklich festlegen - Verwende die gemeinsamen Ergebnis-Hilfsfunktionen des Projekts für synchrone und asynchrone Fehlerbehandlung. - Verwende für benutzerwirksame Validierungsmeldungen Lokalisierungsschlüssel, gemeinsame Schlüssel für übliche Formularfehler und bei Bedarf neue Schlüssel. - Erhöhe nach Prüfung des aktuellen Zweigs bei kompatiblen Korrekturen oder Ergänzungen die Patchversion eines gemeinsamen Pakets und bei neuen Exporten oder neuem Verhalten dessen Nebenversion. - Definiere nicht exportierte Hilfsfunktionen als eigenständige Funktionen, platziere ausführbare Logik zuerst und fasse exportierte Konstanten und Typen am Ende zusammen, statt sie zwischen die Logik zu mischen. - Kommentiere, warum eine Entscheidung besteht, nicht was selbsterklärender Code tut. - Exportiere mehrere einfache Hilfsfunktionen über 1 benanntes Objekt und behalte React-Komponenten als benannte Exporte bei. ## Ausgehendes HTTP über den sicheren Client leiten, um SSRF zu verhindern, und die API-Regeln einhalten Wende an jeder nicht vertrauenswürdigen Grenze ausdrückliche Anfragesemantik und sichere Netzwerkklienten an. ### Endpunkte vereinheitlichen - Verwende `POST` für alle Änderungen zum Erstellen und Aktualisieren und `DELETE` zum Löschen; verwende niemals `PUT` oder `PATCH`, wenn der API-Vertrag sie ausschließt. - Gib jedem Endpunkt eine ausdrückliche Sicherheits- und Zugriffskonfiguration. - Verwende kanonische Kennungen, Fehlertypen, Schemagrundlagen, Sammlungshilfen und Datenbankbereiniger, statt sie erneut zu implementieren. ### Serverseitige Anfragefälschung verhindern - Leite ausgehende HTTP-Anfragen von Serverkomponenten durch den genehmigten sicheren Klienten. - Verwende niemals unverarbeitetes `fetch` oder eine uneingeschränkte Klientenfabrik für URLs, die aus Benutzereingaben, Administratorkonfigurationen, OAuth-Endpunkten oder Integrationen von Drittanbietern stammen. - Bewahre die Filterung privater Adressen, Rückschleifenadressen und Adressen für Cloud-Metadaten. - Führe Typumwandlung, URL-Prüfung und Bereinigung externer Objekte an der Grenze durch. ### Migrationen als kontrollierte Änderungen behandeln - Lies vor dem Erstellen oder Ändern einer Migration den Migrationsleitfaden des Repositories. - Folge dem dokumentierten Erzeugungs- und Strukturverfahren, statt die Anordnung der Migration selbst zu erfinden. - Halte Migrationen mit der unterstützten verwalteten Datenbankumgebung kompatibel. ## Den globalen Fehlerdialog nur zeigen, wenn die Hauptdaten einer Seite nicht laden Zeige globale Abfragefehler nur, wenn die fehlgeschlagenen Daten für die aktuelle Seite unverzichtbar sind. ### Abfragen nach Auswirkung einordnen - Setze für primäre Seitendaten wie Tabellenzeilen oder Hauptlisten das Metadatenkennzeichen der Abfrage, das den globalen Fehlerdialog auslöst. - Aktiviere es nicht für Hilfsdaten wie Funktionskennzeichen, Metadaten, einzelne Nachschlagevorgänge, Filtermöglichkeiten oder Benutzerdetails. - Verwende diese Entscheidungsregel: Zeige den Dialog, wenn der Fehler sonst eine unerklärte leere Seite oder eine leere Hauptansicht hinterlassen würde. - Lass kleinere Abfragen ohne globale Meldung fehlschlagen, wenn die umgebende Oberfläche weiterhin nützlich bleibt. - Halte funktionsbeschränkte Abfragen deaktiviert, bis die zugehörige Tarifberechtigung verfügbar ist. ## Mandantentrennung und jede Edition mit dem Task-Runner des Monorepos testen Führe gezielte Tests über die vorgeschriebene Aufgabensteuerung des Monorepositories aus und prüfe die Pfade, die sich je nach Edition unterscheiden. ### Code und Daten prüfen - Führe Komponententests für gemeinsamen und ausführenden Code sowie Integrationstests für das API-Verhalten aus. - Verwende die standardmäßigen Hilfsfunktionen für Testumgebung und Anfragekontext, damit Authentifizierung und Weiterleitung dem Produktionsverhalten entsprechen. - Stelle sicher, dass Testdaten getrennt und zwischen Tests bereinigt werden. - Ergänze Nebenläufigkeitstests, wenn der Code Sperren, Entdoppelung oder Datenbankauswahl mit `skip-locked` verwendet. - Prüfe die Mandantentrennung, indem du nachweist, dass Daten eines anderen Projekts oder einer anderen Plattform nicht zurückgegeben werden können. ### Unterstützte Befehle verwenden - Führe den vorgeschriebenen Prüf- und Korrekturbefehl für die Quelltextregeln des Repositories aus, bevor du die Aufgabe als abgeschlossen betrachtest. - Verwende die konfigurierte Aufgabensteuerung des Monorepositories und gefilterte Paketbefehle; rufe kein fremdes Erstellungssystem auf. - Wenn ein gehostetes Frontend auf ein entferntes Backend verweist, vermeide OAuth-Abläufe, die zur gehosteten Domäne umleiten; verwende nicht umleitende Anmeldedaten oder ein vollständig lokales Backend. - Prüfe Editionssperren, Markenauftritt, Grenzwerte und Funktionsverfügbarkeit über alle unterstützten Pfade. ## Die Änderung kennzeichnen und erst nach bestandenen Pflichtprüfungen abschließen Nutze Funktionsdokumentation, Kennzeichnungen und abschließende Prüfungen, damit die Änderung verständlich und freigabefähig ist. ### Die Umsetzung vorbereiten - Lies vor der Änderung einer Funktion deren gezielte Dokumentation zu Entitäten, Diensten, Datenflüssen und Integrationsbeschränkungen. - Halte kritische bereichsübergreifende Sicherheitsregeln knapp und trenne sie von schrittweisen Funktionsabläufen. - Prüfe Abhängigkeitsmanifeste, Entitätsregistrierung, Mandantenfilter, Importe zwischen Editionen, Zugriffserklärungen und die Reihenfolge von Nebenwirkungen. ### Den Beitrag vorbereiten - Weise genau 1 Hauptkennzeichnung für Änderungen zu, die zwischen einer Funktion, einer Fehlerkorrektur und einer nicht im Änderungsprotokoll aufgeführten internen Änderung unterscheidet. - Ergänze eine separate Kennzeichnung für den Integrationsbereich, wenn die Änderung eine Drittanbieter- oder Kernintegration betrifft. - Bestätige, dass Sperrdatei, Paketversion, Lokalisierungsschlüssel, Tests und erzeugte Artefakte mit der Umsetzung übereinstimmen. - Führe die vorgeschriebenen Prüfungen für Quelltextregeln, Tests und Sicherheit aus und melde jede Prüfung, die nicht ausgeführt werden konnte. - Erkläre die Arbeit erst dann für abgeschlossen, wenn die abschließende Differenz und die Prüfungsergebnisse dies belegen.