ZepiGit/league-api-engineering

Ingénierie des API League of Legends

Sélectionnez exactement un mode principal. Pour une requête mixte, énoncez le mode dominant et le livrable secondaire avant de procéder.

Mode	Utilisation	Résultat requis
implement	Ajout ou modification d'une intégration de données	Décision de la source → contrat d'adaptateur → fixtures/tests nettoyés → plan d'implémentation ou code → vérifications
audit	Évaluation d'une intégration existante	Inventaire → étiquettes de preuves → matrice de risques → corrections priorisées et spécifiques à la source
debug	Intégration défaillante ou trompeuse	Reproduction → classe d'échec → inspection du transport/schéma/cache/fallback → preuve de correction
research	Choix d'une source ou vérification de faits actuels	Carte des preuves datée → évaluation de la source → décision
policy	Autorisation d'une utilisation de données ou d'un comportement de produit	Examen du produit/données → vérification politique → décision : permis, contraint ou bloqué

Vérifications non-négociables

Rejetez une conception plutôt que de contourner une vérification échouée :

• Secrets et vie privée : n'intégrez, ne persistez et ne journalisez jamais les clés Riot, les identifiants LCU, les jetons d'accès, les cookies, les données personnelles ou les historiques de joueurs réels.
• Sécurité du client local : pas d'injection, de hooks, d'accès à la mémoire du processus, d'analyse de mémoire, de contournement anti-triche, d'extraction d'état caché ou de revendications de contrôle exclusif en plein écran. L'assouplissement du certificat de boucle locale est limité à un client explicitement lié à 127.0.0.1 ou localhost ; il n'est jamais réutilisable pour un HTTPS distant.
• Autorité et conditions : ne présentez pas un point de terminaison ou un fournisseur non documenté comme officiellement pris en charge. Vérifiez les conditions applicables, l'attribution, la redistribution, l'authentification et les limites de débit avant utilisation.
• Véracité du repli : un repli doit préserver la sémantique de la population, de la portée, de la fraîcheur, du patch, des paramètres régionaux, de la file d'attente et de la provenance. Des données matériellement différentes constituent un résultat distinct, pas un substitut silencieux.
• Demandes non prises en charge : n'inventez pas d'estimations MMR/ELO, n'inférez pas d'état caché et n'exposez pas d'informations de joueur indisponibles. Renvoyez policy_blocked ou unsupported_context avec la contrainte.

Processus de décision de source

1. Classez les données demandées : session locale, partie active, données statiques/versionnées, données de compte/partie/classement distantes, données de tendance agrégées, ou état caché/non pris en charge.
2. Commencez par source-decision-tree.md ; choisissez les candidats en fonction de l'autorité, de l'accès, du routage, de la fraîcheur, de la stabilité, de la couverture des patchs, de la latence, des conditions, de la vie privée, de l'attribution, des limites de débit et du comportement en cas d'échec.
3. Appliquez les vérifications strictes avant la notation. Une source nécessitant une clé de production intégrée, un accès local dangereux, des données interdites, une redistribution non examinée ou un repli incompatible est rejetée.
4. Enregistrez une classe de preuve pour chaque affirmation matérielle :
   • verified-current : directement pris en charge par une source faisant autorité et datée ou une observation reproductible actuelle ;
   • observed-undocumented : comportement reproduit non garanti par une autorité ;
   • historical : autrefois documenté ou observé, sans garantie de validité actuelle ;
   • inference : conclusion raisonnée nécessitant une validation avant la production.
5. Rédigez ou mettez à jour un contrat d'adaptateur en utilisant adapter-contract.md, puis adoptez les contrôles de cache/fallback, de test et de canary.

Vocabulaire des échecs

Utilisez une classe d'erreur principale et conservez les diagnostics bruts nettoyés séparément : offline, unauthorized, rate_limited, not_found, no_data, unsupported_context, transport, http_status, parse, schema_drift, ou policy_blocked.

Ne réessayez jamais aveuglément unauthorized, policy_blocked, parse, ou schema_drift. Voir caching-and-fallbacks.md.

Contrat de sortie d'audit

Un audit émet un artefact daté avec :

1. le périmètre, les classes de données et l'inventaire des adaptateurs ;
2. une carte des sources/points de terminaison avec autorité, stabilité, classe de preuve et date de révision des conditions ;
3. les constats sur les identifiants, la vie privée, l'accès local, le routage, le versionnage et l'attribution ;
4. les constats sur le cache, l'absence de données, les tentatives, la dérive et la compatibilité des replis ;
5. une matrice de risques : gravité, probabilité, comportement affecté, preuve et correction concrète ;
6. les corrections priorisées, les éléments bloqués et les critères de vérification.

Ne qualifiez pas une hypothèse de vérifiée. N'appelez pas une source sûre simplement parce qu'elle fonctionne une fois.

Divulgation progressive

• Choix de sources officielles et locales : riot-web-apis.md, lcu.md, live-client-data.md, data-dragon.md, communitydragon.md.
• Sources externes et politique produit : third-party-providers.md, policy-and-product-gates.md.
• Contrôles d'ingénierie : adapter-contract.md, caching-and-fallbacks.md, testing-and-canaries.md.
• Exemple facultatif limité : case-study-lolcompanion.md.

Exécutez python scripts/validate.py . depuis la racine du package avant de publier lorsque le validateur est présent.