Eine Go-API und eine React-SPA ändern, indem zuerst die OpenAPI-Spezifikation angepasst wird

## Die OpenAPI-Spezifikation als maßgebliche Quelle nehmen und jeder Schicht ihre Aufgabe geben - Behandle die OpenAPI-Spezifikation als maßgebliche Quelle für Routen, Anfrage- und Antwortschemata sowie gemeinsame Modelle. - Halte Go-Backend und React-SPA in der Entwicklung unabhängig voneinander erstellbar. - Bette die erstellte SPA in der Produktion vorzugsweise in die Backend-Binärdatei ein und liefere API und UI vom selben Ursprung aus. - Nutze den Entwicklungsserver nur als bequemen Proxy; lasse ausschließlich für die Entwicklung bestimmte Ports oder Hosts nicht in Produktionscode einfließen. - Bewahre klare Zuständigkeiten: Die API-Schicht verantwortet den Transport, Dienste das Domänenverhalten, Speicher die Persistenz und das Frontend die Darstellung. - Erweitere vorhandene Verträge, bevor du parallele Routen, Konfigurationsspeicher, Ereigniskanäle oder Zustandsmodelle erfindest. - Füge ausdrücklich zurückgestellte Teilsysteme nicht ohne abgegrenzte Anforderung und Architekturentscheidung hinzu. - Halte die betroffene Änderung bei Widersprüchen zwischen Dokumentation und Implementierung an und kläre zuerst den Konflikt der maßgeblichen Quellen. ## Die Spezifikation ändern und Code neu erzeugen, statt generierte Dateien von Hand zu ändern 1. Untersuche Spezifikation, generierte Schnittstellen, Implementierung, Tests und einschlägige Betriebsdokumentation. 2. Bearbeite die maßgebliche Quelle: OpenAPI-Dateien für die API-Form, Konfigurationsstrukturen für Einstellungen und Nachrichtenkataloge für UI-Texte. 3. Erzeuge Backend- und Frontend-Artefakte mit den Repository-Befehlen neu. 4. Implementiere die generierte Schnittstelle und aktualisiere nur unmittelbar betroffene Dienste und UI-Vermittlungsschichten. 5. Führe Formatierung, statische Analyse, zielgerichtete Tests und die kleinste einschlägige Laufzeitprüfung aus. 6. Prüfe generierte Unterschiede, um zu bestätigen, dass die Spezifikation den beabsichtigten Vertrag erzeugt hat. - Bearbeite generierte Dateien niemals von Hand; korrigiere stattdessen Spezifikation oder Generatorkonfiguration. - Registriere niemals eine improvisierte Route, welche die generierte Serverschnittstelle umgeht. - Halte Vorgangskennungen eindeutig und stabil, da daraus generierte Methodennamen entstehen. ## Gemeinsame Schemas an einer Stelle halten und generierte Typen an die API anpassen - Teile Pfaddefinitionen nach Domänen auf und bewahre gemeinsame Schemata, Parameter und Antworten in einem einzigen maßgeblichen Komponentenabschnitt. - Verwende gemeinsame Referenzen wieder, statt nahezu identische Schemata in mehreren Pfaddateien zu vervielfältigen. - Bewahre generatorspezifische Importzuordnungen und Bereinigungskontrollen, die dateiübergreifende Referenzen benötigen. - Halte maschinelle Zuordnung und JSON-Eigenschaften synchron, wenn ein Schema einen Typ einer vorgelagerten Bibliothek abbildet. - Deklariere jedes serialisierte Feld und kennzeichne jedes immer vorhandene Feld für Nicht-Go-Nutzer als erforderlich. - Stelle nullable Referenzen in der von OpenAPI-Version und Generator verlangten Form dar und teste das erzeugte Ergebnis. - Erzeuge Frontend-Typen aus dem tatsächlich vom Backend ausgelieferten API-Dokument, wenn Laufzeittreue wichtig ist. - Committe generierte API-Typen, wenn die Repository-Regeln ihre Unterschiede als Nachweis der Vertragsprüfung verwenden. - Halte API-Clients hinter Domänen-Vermittlungsschichten, damit Komponenten nicht von Transportdetails abhängen. ## Strukturierte Fehler zurückgeben, ohne interne Fehlertexte preiszugeben - Implementiere Endpunkte über die generierte Serverschnittstelle und gruppiere Handler-Methoden nach Domäne. - Verwende genau eine gemeinsame Hilfe für JSON-Antworten und einen zentralen Fehlerklassifizierer. - Gib strukturierte Fehler mit stabilen Maschinencodes, Darstellungsart, sicheren optionalen Feldern und einer Anfragekennung zurück. - Kopiere niemals rohe interne oder vorgelagerte Fehlertexte in eine Client-Antwort. - Lege Einzelheiten der Feldvalidierung in einer eigenen Zuordnung ab und reserviere einen allgemeinen Schlüssel für nicht feldbezogene Fehler. - Wandle vorgelagerte Fehler in stabile Grundkennungen um; bewahre Rohinhalte ausschließlich in geschützten Protokollen. - Verwende typisierte, benutzersichtbare Fehler nur, wenn dynamischer Text bewusst als sicher zur Anzeige gilt. - Erzeuge Übertragungsfehlerumschläge nicht außerhalb des Klassifizierers. - Gib Statuscodes und JSON-Fehler zurück, statt Panics zur Ablaufsteuerung einzusetzen. - Behandle Panic-Wiederherstellung als strukturierte und protokollierte Sicherheitsreserve, nicht als Normalverhalten. ## Jede Einstellung nur einmal festlegen und markieren, welche einen Neustart braucht - Definiere Einstellungen einmalig in typisierten Konfigurationsstrukturen und leite Vorgaben, Validierung, Schemametadaten und Umgebungsschlüssel daraus ab. - Wende stets dieselbe Rangfolge an: Vorgaben, Einstellungsdatei und anschließend Umgebungsüberschreibungen. - Speichere nur Werte dauerhaft, die von eingebauten Vorgaben abweichen. - Definiere für jede neue Einstellung Vorgabe, Validierung, UI-Kategorie, Vertraulichkeit, Sichtbarkeit und Neustartverhalten. - Eine zur Laufzeit neu ladbare Einstellung benötigt einen aktiven Verbraucher oder eine Neuladefunktion; andernfalls kennzeichne sie als neustartpflichtig. - Neustartpflichtige Werte dürfen sofort gespeichert werden, müssen aber bis zum Neustart in der wirksamen Laufzeitsicht unverändert bleiben. - Schwärze vertrauliche Werte in API-Antworten und behandle geschwärzte Platzhalter bei Aktualisierungen als wirkungslos. - Halte programmexklusive Einstellungen über die Laufzeit-API schreibgeschützt und verborgene Einstellungen aus dem abgeleiteten UI-Schema heraus. - Führe beim Start und vor dem Speichern dieselben Prüfer aus, damit eine gespeicherte Konfiguration den nächsten Start nicht beschädigt. - Schreibe Einstellungen atomar und verankere verwaltete relative Pfade an einem stabilen Datenstamm statt am Startverzeichnis. ## Ein einheitliches Logformat nutzen und den Server herunterfahren, ohne Arbeit zurückzulassen - Verwende strukturierte Protokollierung mit einem Schema für HTTP-Anfragen, Lebenszyklusereignisse und Hintergrundprozesse. - Hänge Handler-Felder und Fehler an das Protokoll der aktuellen Anfrage an, statt doppelte Ereignisse je Anfrage auszugeben. - Halte Backend-Protokolle in einer Betriebssprache; die Lokalisierung der UI gehört ins Frontend. - Bewahre die Middleware-Reihenfolge, wenn Anfragekennungen, tatsächliche Client-Adressen, Anfrageprotokollierung und Panic-Wiederherstellung davon abhängen. - Platziere neue Middleware innerhalb der Wiederherstellungsgrenze, sofern sie nicht vor Beginn der Anfrageprotokollierung Felder ändern muss. - Schließe beim Herunterfahren zuerst langlebige Ereignisabonnenten und entleere danach den HTTP-Server. - Setze für laufende Anfragen eine begrenzte Entleerungsfrist und definiere das Verhalten bei Fristablauf ausdrücklich. - Schließe bei einem Neustart die Dienstbereinigung ab, bevor du den Prozess ersetzt oder neu erzeugst. - Lasse Streaming-Handler zurückkehren, wenn der Verteiler geschlossen oder die Anfrage abgebrochen wird. - Registriere jeden Hintergrundprozess in derselben Herunterfahrsequenz, damit keine Arbeit verwaist. ## Stabile Abfrageschlüssel nutzen und den Zwischenspeicher leeren, wenn der Benutzer wechselt - Lege die Reihenfolge der Kontextanbieter fest, wenn spätere Anbieter von Abfrage-, Gebietsschema-, Authentifizierungs- oder Ereigniskontexten abhängen. - Stelle Fabriken für Abfrageoptionen aus Funktionsmodulen bereit und halte rohe API-Aufrufe in Domänen-Vermittlungsschichten. - Verwende stabile Abfrageschlüssel, die jeden identitätsändernden Parameter enthalten. - Bewahre vorherige Listendaten nur bei echten Seitenwechseln; verwirf sie bei Änderungen an Filter, Benutzer, Register oder Suchidentität. - Leere kontobezogene Zwischenspeicher, wenn sich die authentifizierte Sitzung ändert. - Zentralisiere optimistische Aktualisierungen, Rücksetz-Schnappschüsse und Ungültigsetzungen, damit jede zwischengespeicherte Kopie eines Objekts übereinstimmt. - Behandle Serverereignisse als Aktualisierungshinweise; der maßgebliche Zustand stammt weiterhin aus Abfragen oder Zustandsendpunkten. - Lies lokalisierte Nachrichtenfunktionen innerhalb von Darstellungswegen über einen reaktiven Kontext. - Ordne dynamische Übersetzungsschlüssel über ausdrückliche statische Auflöser zu und halte Platzhalterformen in allen Gebietsschemata gleich. - Lege menschenlesbare Konfigurationsbezeichnungen in Frontend-Katalogen statt in Backend-Schemata ab. ## Sitzungen getrennt speichern und Benutzer bei kurzzeitigen Fehlern nicht abmelden - Speichere Sitzungszugangsdaten in einer eigenen Zustandsdatei mit eingeschränkten Berechtigungen; mische sie niemals in allgemeine Einstellungen. - Behandle die Erneuerungszugangsdaten als Sitzungsautorität und kurzlebige Zugriffszugangsdaten als austauschbar. - Erneuere vorausschauend kurz vor Ablauf und nach einem Authentifizierungsfehler einmal reaktiv mit koordinierter Einzelausführung. - Bewahre die Sitzung bei vorübergehenden Fehlern und lösche sie erst nach bestätigter dauerhafter Ablehnung. - Halte Autorisierungsprüfer kurzlebig, kapazitätsbegrenzt und nur einmal verwendbar. - Prüfe eingefügte Rückrufwerte vor der Weitergabe an vorgelagerte Systeme und gib lokalisierte, handlungsfähige Fehler zurück. - Entferne Zugangsdaten aus Ergebnissen der Proxy-Erkennung und halte die Erkennung schreibgeschützt. - Sichere nicht authentifizierte Einführungs-Schreibvorgänge, damit sie Einstellungen nach der Anmeldung nicht verändern können. - Schütze vertrauliche Änderungsendpunkte durch Authentifizierung und einen anwendungsspezifischen CSRF-Header. - Lege vorgelagerte Authentifizierungsinhalte, Zugangsdaten oder interne Paketfehler niemals gegenüber Clients offen. ## Downloads über temporäre Dateien speichern und keine Dateien löschen, die die App nicht erstellt hat - Mache den `job` zur Transaktionsgrenze und speichere jeden bedeutsamen Zustandswechsel atomar. - Sende häufige Fortschrittsdaten über Ereignisse, statt den dauerhaften Zustand bei jedem Tick neu zu schreiben. - Schreibe Nutzdaten in eindeutig benannte temporäre Dateien und benenne sie erst nach Erfolg um; entferne Teildateien bei Abbruch oder Fehler. - Wiederhole nur wiederholbare Fehler mit begrenzter exponentieller Wartezeit. - Erfasse vor der Bereinigung, ob die Anwendung jede endgültige Datei erzeugt hat; entferne einen Pfad niemals allein aufgrund seines erwarteten Namens. - Löse Namenskollisionen anhand vorhandener Datenträgerinhalte und laufender Reservierungen mit einer begrenzten Ausweichstrategie. - Löse Pfade bei der Neustartwiederherstellung erneut, sofern fertige Nutzdaten ihr Ziel nicht bereits besitzen. - Verarbeite Pfadvorlagen beim Start und prüfe sie erneut, bevor du Konfigurationsänderungen annimmst. - Bereinige jedes Pfadsegment, bewahre ausdrückliche Wurzeln, begrenze Dateinamen nach Bytes und zähle sichtbare Kürzung nach Zeichen. - Fixiere Konvertierungs- und Benennungsentscheidungen je `job`, damit neu geladene Einstellungen laufende Arbeit nicht verändern. ## Verpasste Ereignisse beim Wiederverbinden nachliefern und sonst neu synchronisieren - Halte dauerhaften Zustand maßgeblich und behandle Ereignisse als Optimierung. - Gib Ereignissen stabile Kennungen, Zeitstempel, Themen, Typen und rekonstruierbare Nutzdaten. - Spiele bei Wiederverbindung Ereignisse nach der letzten bekannten Client-Kennung ab, wenn der Puffer sie noch enthält. - Sende bei unmöglicher Wiedergabe genau ein Resynchronisationsereignis und verlange das erneute Abrufen des maßgeblichen Zustands. - Verhindere durch Lebenszeichen, dass Zwischenstellen inaktive Datenströme unbemerkt schließen. - Nur Ereignisse auf `job`-Ebene dürfen den Gesamtstatus setzen; `task`-Ereignisse aktualisieren Aufgaben, ohne servereigene Regeln neu zu berechnen. - Aktualisiere betroffene Ansichten nach Wiederverbindung und einem Resynchronisationssignal. - Begrenze die Häufigkeit von Fortschrittsmeldungen, umgehe die Begrenzung jedoch bei Endzuständen und der letzten Fortschrittsaktualisierung. - Halte Ereignistransport durch eine kleine Veröffentlicherschnittstelle von Domänenverwaltern unabhängig. ## Proxy-Ziele begrenzen und Signaturen prüfen, bevor die App aktualisiert wird - Erlaube Proxy-Ziele anhand genauer Hostregeln und prüfe jede Weiterleitung erneut, um serverseitige Anforderungsfälschung zu verhindern. - Teile gleichzeitige Fehltreffer für dieselbe Ressource und lehne übergroße Inhalte vor dem Zwischenspeichern ab. - Behandle das Dateisystem als Wahrheit des Zwischenspeichers; gleiche die Größe regelmäßig und nach Schreibvorgängen durch Verdrängung der ältesten Zugriffe ab. - Halte Zwischenspeicher verschiebbar und von dauerhaftem Benutzerzustand getrennt. - Füge Speicherorte des Aktualisierungsfeeds und vertrauenswürdige Signaturschlüssel beim Veröffentlichungs-Build ein; verweigere ohne Vertrauensmaterial jede Aktualisierung. - Prüfe ein signiertes Manifest, bevor du Version, URL, Prüfsumme oder Feld der Veröffentlichungshinweise vertraust. - Prüfe das heruntergeladene Archiv anhand des signierten Manifests, bevor du eine Binärdatei ersetzt. - Führe Aktualisierungen einzeln koordiniert aus, lehne sie in Entwicklungs-Builds ab und verlange Authentifizierung samt CSRF-Schutz. - Bestimme die Ersatzprogrammdatei eindeutig und verweigere mehrdeutige Archive. - Entleere Dienste und starte erst neu, nachdem der geprüfte Ersatz bereitsteht. ## In der laufenden App prüfen und vor Veröffentlichungen oder Produktionsänderungen anhalten - Durchlaufe Erzeugung, Implementierung, zielgerichtete Tests und direkte Laufzeitprüfung, ohne einen fehlgeschlagenen Schritt zu überspringen. - Prüfe den Health-Endpunkt, ausgeliefertes OpenAPI-Dokument, betroffenes API-Verhalten und unmittelbar betroffenen UI-Pfad. - Führe bei betroffenen Änderungen Formatierung, statische Analyse, rennbedingungssensitive Backend-Tests, Frontend-Prüfungen und Produktions-Builds aus. - Bestätige atomare Persistenz, Neustartsemantik, Geheimnismaskierung und Nichtoffenlegung von Fehlern mit zielgerichteten Tests. - Prüfe bei Veröffentlichungen strikte semantische Versionierung, Kontinuität des signierten Feeds, Prüfsummen und plattformspezifische Archivauflösung. - Belasse zurückgestellte Funktionen zurückgestellt, sofern die aktuelle Anforderung sie nicht ausdrücklich einbezieht. - Vermeide sachfremde Umstrukturierungen, parallele Zustandsspeicher, doppelte Fehlersysteme und spekulative Infrastruktur. - Halte vor externer Veröffentlichung, zerstörerischer Migration, Änderung von Zugangsdaten oder Produktionsänderung an, sofern keine ausdrückliche Genehmigung vorliegt. - Berichte, was geändert und geprüft wurde, was außerhalb des Umfangs bleibt und welche Vertragskonflikte ungelöst sind.