Einen graphbasierten Autorisierungsdienst ändern und dabei zuerst Tests schreiben

## Korrektheit an erste Stelle setzen und die Build-Targets des Repositorys nutzen Wende die Projektprioritäten in dieser Reihenfolge an: 1. Korrektheit: Jede Autorisierungsentscheidung muss richtig sein. 2. Zuverlässigkeit: Der Dienst muss verfügbar bleiben und sich vorhersehbar erholen. 3. Leistung: Verringere Latenz und Speicherzuweisungen erst, nachdem Korrektheit und Zuverlässigkeit geschützt sind. Behandle die vom Repository verwalteten Build-Ziele als maßgebliche Quelle. Ziehe sie spontanen Einzelbefehlen vor, da sie erforderliche Erzeugungsschritte, Schalter, Erkennung von Nebenläufigkeitsfehlern, Abdeckung, Lint-Prüfungen und Umgebungseinrichtung enthalten. Typische Zielgruppen sollen Folgendes abdecken: - Produktiv-Builds; - die vollständige Testsammlung; - gefilterte Tests für einen benannten Fall; - Leistungstests mit Speicherkennzahlen; - Integrationstests, die Container benötigen; - Lint-Prüfungen mit der im Repository festgelegten Werkzeugversion; - erzeugte Testersatzobjekte; - lokale Entwicklung mit einem Datenspeicher im Arbeitsspeicher oder in einem Container. Lies vor der Ausführung eines Ziels dessen Definition und erforderliche Umgebungsvariablen. Wenn das maßgebliche Ziel nicht verfügbar oder unklar ist, behebe diese Lücke, statt es stillschweigend durch einen schwächeren Befehl zu ersetzen. ## Vor einer Änderung den Weg einer Anfrage durch die Resolver-Kette verfolgen Ordne eine Anfrage vor einer Verhaltensänderung dem vollständigen Laufzeitpfad zu. Halte diese Reihenfolge ein: 1. HTTP- oder RPC-Anfrage empfangen; 2. Middleware anwenden; 3. in die Transportverarbeitung eintreten; 4. Befehl oder Anwendungsdienst aufrufen; 5. Autorisierungsgraph auflösen; 6. auf den Speicher zugreifen; 7. Antwort zurückgeben. Ermittle die Module für Start und Beendigung, Verarbeitung, Geschäftsbefehle, Graphauswertung, Planung, Speicherschnittstellen und -implementierungen, Modellparsing, Tupelprüfung, Authentifizierung und API-Autorisierung. Prüfe bei graphbasierten Abfragen den Resolver-Erzeuger und die Resolver-Schnittstelle gemeinsam. Eine Resolver-Pipeline darf Zwischenspeicherung, Drosselung der Verteilung oder Schattenvergleiche nur hinzufügen, wenn die Konfiguration sie aktiviert. Gehe nicht davon aus, dass die Kette linear ist. Manche Resolver-Systeme bilden eine kreisförmige Delegationskette, in der der letzte Resolver zum ersten zurückkehrt. Prüfe vor einer Änderung des Verteilungsverhaltens die Konstruktionsreihenfolge, Abbruchbedingungen und den Unterschied zwischen optionalen Kapseln und der zentralen lokalen Prüfung. Behandle die Laufzeitverschaltung als stärkeren Beleg als Verzeichnisnamen oder Entwurfsannahmen. ## Lint-Namensregeln einhalten und umhüllte Fehler erkennbar halten Lies die aktive Lint-Konfiguration, bevor du Importe oder Namen änderst. Bewahre: - erforderliche Aliasse für erzeugte APIs und Parser; - die festgelegten Importgruppen und ihre Reihenfolge; - Schnittstellennamen ohne überflüssige Präfixe; - Konstruktoren nach dem Namensmuster `NewTypeName`; - funktionale Optionen nach dem Namensmuster `WithPropertyName`; - Optionstypen in der Form `TypeNameOption func(*TypeName)`; - exportierte Konstanten im Exportbenennungsstil des Projekts; - nicht exportierte Konstanten und Kontextschlüssel im lokalen Benennungsstil des Projekts. Definiere stabile Domänenfehler als Wächterwerte. Füge Kontext hinzu, ohne die Fehleridentität zu zerstören: - einen Wächter wie `var ErrNotFound = errors.New("not found")` deklarieren; - ihn mit Kontext wie `fmt.Errorf("load relationship: %w", ErrNotFound)` umschließen. Verwende `errors.Is` oder `errors.As` zum Abgleichen. Vergleiche umschlossene Fehler nicht direkt und formatiere sie nicht mit einem Formatierungsverb, das die Fehlerkette verliert. Halte die Umwandlung von der Domäne zur Transportschicht an einer ausdrücklichen Grenze. Die Befehlslogik soll Domänenfehler zurückgeben; ein eigener Konverter ordnet sie HTTP- oder RPC-Antworten zu. ## Zuerst einen fehlschlagenden Test schreiben und die Matrixtests für Autorisierung pflegen Nutze testgetriebene Entwicklung für Verhaltensänderungen: 1. Einen gezielten Test hinzufügen, der das fehlende oder falsche Verhalten ausdrückt. 2. Ihn ausführen und bestätigen, dass er aus dem beabsichtigten Grund fehlschlägt. 3. Die kleinste Änderung implementieren, die den Test bestehen lässt. 4. Den gezielten Test und danach die unmittelbar betroffene Testsammlung ausführen. 5. Erst umstrukturieren, nachdem die Tests bestanden wurden. Pflege für Autorisierungsalgorithmen Matrixtests, die Modelle, Beziehungstupel und erwartete Ergebnisse für Prüf-, Objektlisten- und Benutzerlisten-APIs definieren. In jeder Matrixstufe sollen Modell und Zusicherungen zusammen lesbar sein. Ein minimaler Matrixfall soll diese Reihenfolge und Bedeutung bewahren: 1. dem Test einen Namen wie `viewer_can_read_document` geben; 2. im Stufenmodell die Typen `user` und `document` definieren; 3. eine Beziehung `viewer` definieren, die einen Benutzer akzeptiert; 4. das Tupel `document:1`, `viewer`, `user:alice` hinzufügen; 5. zusichern, dass die Prüfung desselben Objekts, derselben Beziehung und desselben Benutzers `true` zurückgibt. Halte eingebettete Testressourcen bei den zugehörigen Testausführungen registriert. Wenn eine API mehrere Listen- oder Prüfoberflächen besitzt, prüfe jede betroffene Ausführung, statt anzunehmen, dass eine Oberfläche die anderen abdeckt. Nutze Leistungstests bei Änderungen an häufig durchlaufenen Graphpfaden, Resolver-Auswahl, Speicherzugriff oder zuweisungsabhängigem Code. Nutze containerbasierte Tests für datenspeicherspezifisches Verhalten. ## Erzeugte Dateien und Schemas anderer Repositorys nicht von Hand ändern Bearbeite erzeugte Testattrappen, erzeugte Protokollanbindungen oder andere erzeugte Artefakte nicht direkt. Ändere die Quelle oder den Erzeuger und erzeuge anschließend über das maßgebliche Ziel neu. Ändere extern verwaltete Schemadefinitionen nicht im Repository eines nachgelagerten Dienstes. Nimm die Schemaänderung im zuständigen Repository vor, prüfe sie dort und aktualisiere danach die nachgelagerte Abhängigkeit. Berücksichtige diese betrieblichen Fallstricke: - Ein vollständiges Testziel kann Testattrappen automatisch neu erzeugen, während ein direkter Sprachtestbefehl dies möglicherweise nicht tut. - Integrationstests für SQL-Datenspeicher können eine Containerlaufzeit benötigen. - Resolver-Rekursion kann beabsichtigt sein, weil die Kette kreisförmig ist. - Die Syntax der Lint-Konfiguration ist versionsabhängig. - Eine Änderung der Speicherschnittstelle erfordert, dass alle Backends und ihre gemeinsamen Vertragstests gemeinsam angepasst werden. Wenn ein erforderlicher Erzeuger, eine Containerlaufzeit oder ein vorgelagertes Schema nicht verfügbar ist, melde die fehlende Voraussetzung. Bearbeite abgeleitete Artefakte nicht von Hand, um einen Abschluss vorzutäuschen. ## Bei neuen API-Endpunkten und Speicheränderungen alle Schritte durchgehen Für einen neuen API-Endpunkt: 1. das verwaltete API-Schema aktualisieren; 2. die Transportverarbeitung hinzufügen; 3. die Befehls- oder Anwendungsdienstlogik hinzufügen; 4. Domänenfehler an der Transportgrenze zuordnen; 5. gezielte Tests und Matrixtests hinzufügen. Für eine Änderung der Speicherschnittstelle: 1. die Schnittstelle aktualisieren; 2. gemeinsame Speichervertragstests aktualisieren; 3. die Änderung für jedes unterstützte Backend implementieren; 4. die betroffenen arbeitsspeicherbasierten und containerbasierten Testsammlungen ausführen. Für eine Änderung am Graph-Resolver: 1. die Resolver-Schnittstelle implementieren; 2. Erzeugeroptionen hinzufügen oder aktualisieren; 3. bedingte Zusammensetzung und kreisförmige Delegation prüfen; 4. Korrektheit, Wechselwirkungen mit Drosselung oder Zwischenspeicherung sowie Abbruch testen; 5. einen Leistungstest ausführen, wenn sich der häufig durchlaufene Pfad ändern könnte. Aktualisiere bei einer Änderung des Typsystems Parsing, Validierung, gewichtete oder optimierte Graphlogik und die zugehörigen Validierungstests als eine zusammenhängende Änderung. Prüfe vor der Abschlussmeldung den Änderungssatz auf unbeabsichtigte Bearbeitungen erzeugter Dateien, bestätige, dass der gezielte Test vom Fehlschlag zum Erfolg gewechselt ist, führe die unmittelbar betroffenen maßgeblichen Ziele aus und notiere jede nicht ausführbare Testklasse mit ihrer genauen Voraussetzung.