ZepiGit/league-api-engineering

League API Engineering

Wähle genau einen primären Modus aus. Bei einer gemischten Anforderung gib den dominanten Modus und das sekundäre Ergebnis vor der Bearbeitung an.

Modus	Verwendung	Erforderliches Ergebnis
implement	Hinzufügen oder Ändern einer Datenintegration	Quellentscheidung → Adaptervertrag → bereinigte Fixtures/Tests → Implementierungsplan oder Code → Gates
audit	Bewertung einer bestehenden Integration	Inventar → Evidenzbelege → Risikomatrix → priorisierte, quellspezifische Korrekturen
debug	Eine fehlerhafte oder irreführende Integration	Reproduktion → Fehlerklasse → Transport-/Schema-/Cache-/Fallback-Prüfung → Fix-Nachweis
research	Auswahl einer Quelle oder Überprüfung aktueller Fakten	Datierte Evidenzkarte → Quellbewertung → Entscheidung
policy	Prüfung, ob Datennutzung oder Produktverhalten zulässig ist	Produkt-/Datenprüfung → Richtlinien-Gate → Entscheidung: erlaubt, eingeschränkt oder blockiert

Unverhandelbare Gates

Lehne ein Design ab, anstatt ein gescheitertes Gate zu umgehen:

• Geheimnisse und Privatsphäre: Riot-Keys, LCU-Zugangsdaten, Bearer-Tokens, Cookies, PII oder echte Spielerverläufe niemals einbetten, speichern oder protokollieren.
• Lokaler Client-Sicherheit: Kein Injection, Hooks, Prozessspeicherzugriff, Speicher-Scanning, Anti-Cheat-Umgehung, Extraktion versteckter Zustände oder Behauptungen über exklusiven Vollbildmodus. Loopback-Zertifikatslockerung ist auf einen Client beschränkt, der explizit an 127.0.0.1 oder localhost gebunden ist; sie ist niemals für entferntes HTTPS wiederverwendbar.
• Autorität und Bedingungen: Stelle einen undocumented Endpunkt oder Anbieter nicht als offiziell unterstützt dar. Überprüfe vor der Nutzung die geltenden Bedingungen, Zuschreibungen, Weiterverteilung, Authentifizierung und Ratelimit-Bedingungen.
• Fallback-Wahrhaftigkeit: Ein Fallback muss die Semantik von Population, Umfang, Aktualität, Patch, Gebietsschema, Warteschlange und Herkunft bewahren. Materiell unterschiedliche Daten sind ein separates Ergebnis, kein stiller Ersatz.
• Nicht unterstützte Anfragen: Erfinde keine MMR/ELO-Schätzungen, leite keinen versteckten Zustand ab und lege keine nicht verfügbaren Spielerinformationen offen. Gib policy_blocked oder unsupported_context mit der Einschränkung zurück.

Quellentscheidungs-Workflow

1. Klassifiziere die angeforderten Daten: lokale Session, aktives Match, statische/versionierte Daten, entfernte Konto-/Match-/Ranglistendaten, aggregierte Trenddaten oder nicht unterstützte/versteckte Zustände.
2. Beginne mit source-decision-tree.md; wähle Kandidaten nach Autorität, Zugriff, Routing, Aktualität, Stabilität, Patch-Abdeckung, Latenz, Bedingungen, Datenschutz, Zuschreibung, Ratelimits und Fehlerverhalten aus.
3. Wende harte Gates vor der Bewertung an. Eine Quelle, die einen eingebetteten Produktionsschlüssel, unsicheren lokalen Zugriff, verbotene Daten, nicht geprüfte Weiterverteilung oder einen inkompatiblen Fallback erfordert, wird abgelehnt.
4. Erfasse eine Evidenzklasse für jede wesentliche Behauptung:
   • verified-current: direkt belegt durch eine datierte autoritative Quelle oder aktuelle reproduzierbare Beobachtung;
   • observed-undocumented: reproduziertes Verhalten, das nicht durch eine Autorität garantiert wird;
   • historical: ehemals dokumentiert oder beobachtet, nicht als aktuell sicher anzunehmen;
   • inference: eine begründete Schlussfolgerung, die vor der Produktion validiert werden muss.
5. Schreibe oder aktualisiere einen Adaptervertrag unter Verwendung von adapter-contract.md und übernehme dann Cache-/Fallback-, Test- und Canary-Kontrollen.

Fehlervokabular

Verwende eine primäre Fehlerklasse und behalte rohe bereinigte Diagnosedaten getrennt: offline, unauthorized, rate_limited, not_found, no_data, unsupported_context, transport, http_status, parse, schema_drift oder policy_blocked.

Wiederhole niemals blind unauthorized, policy_blocked, parse oder schema_drift. Siehe caching-and-fallbacks.md.

Audit-Output-Vertrag

Ein Audit erzeugt ein datiertes Artefakt mit:

1. Umfang, Datenklassen und Adapterinventar;
2. Quellen-/Endpunktkarte mit Autorität, Stabilität, Evidenzklasse und Datum der Bedingungsprüfung;
3. Befunde zu Anmeldeinformationen, Privatsphäre, lokalem Zugriff, Routing, Versionierung und Zuschreibung;
4. Befunde zu Cache, No-Data, Wiederholung, Abweichung und Fallback-Kompatibilität;
5. eine Risikomatrix: Schweregrad, Wahrscheinlichkeit, betroffenes Verhalten, Belege und konkrete Abhilfe;
6. priorisierte Korrekturen, blockierte Elemente und Überprüfungskriterien.

Bezeichne eine Annahme nicht als verifiziert. Bezeichne eine Quelle nicht nur deshalb als sicher, weil sie einmal funktioniert.

Progressive Offenlegung

• Offizielle und lokale Quellenauswahlen: riot-web-apis.md, lcu.md, live-client-data.md, data-dragon.md, communitydragon.md.
• Externe Quellen und Produktrichtlinien: third-party-providers.md, policy-and-product-gates.md.
• Engineering-Kontrollen: adapter-contract.md, caching-and-fallbacks.md, testing-and-canaries.md.
• Optionales begrenztes Beispiel: case-study-lolcompanion.md.

Führe python scripts/validate.py . aus dem Paketstammverzeichnis aus, bevor du veröffentlichst, wenn der Validator vorhanden ist.