Communitygithub.com

1184898069/large-data-safety-review

Compétence Codex basée sur des preuves pour identifier les risques de production dans les fonctionnalités gourmandes en données avant qu'ils ne deviennent des incidents.

Qu'est-ce que large-data-safety-review ?

Cette compétence pour Codex (ou d'autres agents IA similaires) permet d'effectuer une revue systématique et rigoureuse de la chaîne de traitement des données d'une fonctionnalité, afin de détecter les risques de passage à l'échelle avant qu'ils ne provoquent des incidents en production. Elle est conçue pour les développeurs et les équipes techniques qui travaillent sur des fonctionnalités manipulant de grands volumes de données. La compétence fonctionne en mode lecture seule et trace l'ensemble du chemin des données, de la source à l'affichage, en inspectant chaque couche (base de données, API, services, frontend) avec des listes de contrôle spécialisées. Elle classe ensuite les problèmes par sévérité et état de la preuve, et produit un rapport structuré avec des recommandations de correction et de vérification. Les preuves (code, logs, plans de requêtes) sont primordiales : l'absence de preuve n'est jamais considérée comme une preuve de sécurité.

Compatible avec~Claude Code✓Codex CLI~Cursor
npx skills add 1184898069/large-data-safety-review

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Revue de Sécurité des Grands Volumes de Données

Examinez l'ensemble du chemin de données pour un comportement de production borné. Signalez les conclusions étayées par des preuves, les chemins sûrs confirmés, les preuves manquantes et les limites testées ou non testées.

Règles de Fonctionnement

  • Lecture seule par défaut. Ne modifiez pas le code, les dépendances, les bases de données, les paramètres de production ou les systèmes externes.
  • N'installez pas de dépendances.
  • Ne considérez jamais l'absence de preuve comme une preuve de sécurité. Marquez la couche concernée comme Non Vérifiée.
  • Ne revendiquez pas une échelle supportée sans preuve d'exécution, de test de charge, de plan de requête ou équivalente.
  • Traitez les correspondances de motifs comme des candidats, pas comme des conclusions. Lisez le flux de données environnant avant de signaler.
  • Préférez le périmètre de l'utilisateur ou le diff actuel. Limitez la découverte, la lecture, les commandes et les sorties.

Flux de Travail

1. Établir le périmètre

Lisez la demande, les instructions du dépôt, les fichiers nommés, le diff actuel, ainsi que les producteurs et consommateurs directs. Indiquez les couches examinées, exclues et manquantes.

2. Construire le profil d'échelle

Enregistrez le volume actuel, la limite de conception, la fréquence des requêtes, la concurrence, la croissance, la taille des éléments, les cibles d'interaction et les limites de ressources. Si les valeurs sont absentes, étiquetez les hypothèses de diagnostic séparément des valeurs confirmées.

Utilisez ces sondes de diagnostic uniquement lorsque les preuves de l'utilisateur sont manquantes :

  • 10 000 000 lignes stockées.
  • 100 000 lignes correspondantes.
  • 100 requêtes interactives simultanées.
  • Taille de page 100, maximum absolu 200.
  • 100 000 lignes de table logique avec des lignes DOM bornées.
  • 1 000 000 lignes d'exportation ou de traitement par lots.
  • Croissance multipliée par 10.

3. Tracer le chemin des données

Tracez :

Source de données -> requête/accès aux données -> service/tâche -> API/sérialisation -> gestion d'état -> page/tableau/exportation

Indiquez quelles couches sont étayées par des preuves.

4. Examiner chaque couche

Utilisez references/review-checklist.md pour l'examen multi-couche.

Chargez references/vue2-axios-vxe-table.md uniquement lorsque le chemin contient Vue, axios, vxe-table, l'état du navigateur ou le rendu de tableaux de données volumineux.

Chargez references/dotnet-webapi-efcore.md uniquement lorsque le chemin contient ASP.NET WebAPI, EF Core, LINQ, contrôleurs, services, dépôts, exportations ou tâches d'arrière-plan.

Ne chargez pas chaque référence par défaut.

Vérifiez le périmètre de stockage/requête, la matérialisation, la projection, les index, la pagination stable, la taille des charges utiles, l'annulation, les délais d'attente, la concurrence bornée, la contre-pression, l'idempotence, les nouvelles tentatives, les copies d'état, le travail calculé, la taille du DOM, les états de chargement et la dégradation.

5. Valider les conclusions candidates

Pour chaque candidat :

  1. Identifiez l'entrée croissante ou la dimension de concurrence.
  2. Confirmez où le filtrage, la projection, la pagination, la mise en mémoire tampon ou le rendu se produisent.
  3. Vérifiez les limites absolues existantes et si elles sont testées.
  4. Tracez la propagation de l'annulation, du délai d'attente, des nouvelles tentatives et des erreurs.
  5. Enregistrez les preuves exactes de fichier et de ligne lorsque le code est disponible.
  6. Rejetez le candidat si le contexte prouve que le chemin est borné.

6. Classifier les preuves et la sévérité

États des preuves :

  • Confirmé : preuve directe de code, SQL, configuration, test, exécution ou conception.
  • Probable : preuve de chemin solide avec un artefact manquant en amont ou en aval.
  • Non vérifié : le matériel nécessaire n'est pas disponible.

Sévérités :

  • P0 : dommages aux données confirmés, indisponibilité de la production ou épuisement incontrôlé des ressources sur un chemin accessible.
  • P1 : délai d'attente probable, OOM, surcharge de base de données, échec d'interaction grave ou résultats incorrects à une échelle connue ou de diagnostic.
  • P2 : dégradation significative à mesure que le volume ou la concurrence augmente, avec une marge de manœuvre actuelle ou un chemin alternatif.
  • P3 : limites, observabilité, tests ou preuves de maintenabilité manquants sans défaillance grave démontrée.

N'attribuez pas P0 ou P1 uniquement à partir d'hypothèses de diagnostic. Placez les risques graves mais non étayés sous une vérification haute priorité.

7. Rédiger le rapport

Chargez references/output-contract.md et suivez-le exactement.

Chaque conclusion doit inclure :

  • Sévérité et état de la preuve.
  • Couche et code racine stable.
  • Emplacement de la preuve.
  • Échelle déclencheur.
  • Impact.
  • Correction minimale.
  • Méthode de vérification.

Listez les chemins sûrs confirmés uniquement lorsque les preuves les soutiennent.

Limites du Dépôt et de la Sortie

  • Énumérez au maximum 100 000 chemins en tant que métadonnées ; réduisez par répertoire et extension au-delà.
  • Scannez au maximum 20 000 fichiers sources ou 500 Mio de texte par passe de contenu, selon la première éventualité.
  • Conservez au maximum 500 correspondances candidates ; regroupez le reste et enregistrez le nombre tronqué.
  • Lisez en profondeur au maximum 200 fichiers candidats par passe.
  • Utilisez un délai d'attente de commande par défaut de 60 secondes ; réduisez le périmètre après un délai d'attente.
  • Développez au maximum 50 conclusions et 5 emplacements de preuve représentatifs par cause racine.
  • Ignorez les dépendances, les sorties générées, les archives, les binaires, les répertoires de build et les grands fichiers minifiés.
  • Signalez chaque exclusion et troncature avec le nombre d'origine, le nombre conservé et la raison.

Preuves Manquantes et Échecs

  • Frontend uniquement : examinez le frontend et produisez un contrat backend/API/base de données non vérifié.
  • Backend uniquement : examinez le backend et marquez le rendu consommateur et l'interaction comme non vérifiés.
  • Dépôt surdimensionné : réduisez à partir du diff, des routes, des clients, des requêtes, des exportations et des points d'entrée de rendu.
  • Délai d'attente de commande : réduisez le lot ou le périmètre du chemin au lieu d'augmenter le délai d'attente à plusieurs reprises.
  • Conflits de documentation avec le code : privilégiez le code, les tests, les plans de requête et les preuves d'exécution ; signalez les dérives de documentation.
  • Matériel sensible : ne répétez pas les secrets ou les enregistrements ; utilisez une description d'emplacement masquée.

Skills associés