Communitygithub.com

1184898069/revisión-de-seguridad-de-datos-a-gran-escala

Habilidad de Codex respaldada por evidencia para encontrar riesgos de producción en funciones con grandes volúmenes de datos antes de que se conviertan en incidentes.

¿Qué es revisión-de-seguridad-de-datos-a-gran-escala?

Esta habilidad de Codex, respaldada por evidencia, realiza una revisión sistemática de la ruta completa de datos de una función, desde la fuente hasta la interfaz de usuario, para identificar riesgos de producción como agotamiento de recursos, tiempos de espera o corrupción de datos. Está diseñada para desarrolladores que trabajan con grandes volúmenes de datos y buscan prevenir incidentes en producción. La habilidad sigue un flujo de trabajo de siete pasos: establece el alcance, construye un perfil de escala (utilizando valores de diagnóstico cuando faltan datos reales), traza la ruta de datos, revisa cada capa con listas de verificación específicas (por ejemplo, para Vue, axios, vxe-table o .NET WebAPI, EF Core), valida hallazgos candidatos, clasifica la evidencia y la severidad (P0-P3), y escribe un informe detallado. Es de solo lectura, no modifica código ni sistemas, y exige evidencia concreta (SQL, pruebas, planes de ejecución) antes de declarar un camino seguro. La habilidad es útil para revisiones de diseño, análisis de rendimiento y auditorías de seguridad de datos en plataformas como Claude Code, Cursor y Codex.

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

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Revisión de Seguridad de Datos a Gran Escala

Revise la ruta completa de datos para garantizar un comportamiento de producción acotado. Reporte hallazgos respaldados por evidencia, caminos seguros confirmados, evidencia faltante y límites probados o no probados.

Reglas Operativas

  • Solo lectura por defecto. No modifique código, dependencias, bases de datos, configuraciones de producción ni sistemas externos.
  • No instale dependencias.
  • Nunca trate la evidencia faltante como prueba de seguridad. Marque la capa afectada como No Verificada.
  • No reclame una escala compatible sin evidencia de tiempo de ejecución, pruebas de carga, plan de consulta o equivalente.
  • Trate las coincidencias de patrones como candidatos, no como hallazgos. Lea el flujo de datos circundante antes de informar.
  • Prefiera el alcance del usuario o el diff actual. Mantenga acotados el descubrimiento, la lectura, los comandos y la salida.

Flujo de Trabajo

1. Establecer el alcance

Lea la solicitud, las instrucciones del repositorio, los archivos nombrados, el diff actual y los productores y consumidores directos. Indique las capas revisadas, excluidas y faltantes.

2. Construir el perfil de escala

Registre el volumen actual, el límite de diseño, la frecuencia de solicitudes, la concurrencia, el crecimiento, el tamaño de los elementos, los objetivos de interacción y los límites de recursos. Si los valores están ausentes, etiquete las suposiciones de diagnóstico por separado de los valores confirmados.

Utilice estas sondas de diagnóstico solo cuando falte evidencia del usuario:

  • 10,000,000 filas almacenadas.
  • 100,000 filas coincidentes.
  • 100 solicitudes interactivas concurrentes.
  • Tamaño de página 100, máximo estricto 200.
  • 100,000 filas lógicas de tabla con filas DOM acotadas.
  • 1,000,000 filas de exportación o lote.
  • Crecimiento de 10x.

3. Trazar la ruta de datos

Trazar:

Fuente de datos -> consulta/acceso a datos -> servicio/trabajo -> API/serialización -> gestión de estado -> página/tabla/exportación

Indique qué capas están respaldadas por evidencia.

4. Revisar cada capa

Utilice references/review-checklist.md para la revisión entre pilas.

Cargue references/vue2-axios-vxe-table.md solo cuando la ruta contenga Vue, axios, vxe-table, estado del navegador o renderizado de tablas con muchos datos.

Cargue references/dotnet-webapi-efcore.md solo cuando la ruta contenga ASP.NET WebAPI, EF Core, LINQ, controladores, servicios, repositorios, exportaciones o trabajos en segundo plano.

No cargue todas las referencias por defecto.

Verifique el alcance de almacenamiento/consulta, materialización, proyección, índices, paginación estable, tamaño de carga útil, cancelación, tiempos de espera, concurrencia acotada, contrapresión, idempotencia, reintentos, copias de estado, trabajo computado, tamaño DOM, estados de carga y degradación.

5. Validar hallazgos candidatos

Para cada candidato:

  1. Identifique la dimensión de entrada o concurrencia creciente.
  2. Confirme dónde ocurre el filtrado, la proyección, la paginación, el almacenamiento en búfer o el renderizado.
  3. Verifique los límites estrictos existentes y si están probados.
  4. Trace la cancelación, el tiempo de espera, el reintento y la propagación de errores.
  5. Registre la evidencia exacta de archivo y línea cuando el código esté disponible.
  6. Rechace el candidato si el contexto demuestra que la ruta está acotada.

6. Clasificar evidencia y severidad

Estados de evidencia:

  • Confirmada: evidencia directa de código, SQL, configuración, prueba, tiempo de ejecución o diseño.
  • Probable: evidencia de ruta sólida con un artefacto ascendente o descendente faltante.
  • No Verificada: el material necesario no está disponible.

Severidades:

  • P0: daño de datos confirmado, indisponibilidad de producción o agotamiento de recursos incontrolado en una ruta accesible.
  • P1: probable tiempo de espera, OOM, sobrecarga de base de datos, falla de interacción severa o resultados incorrectos a escala conocida o de diagnóstico.
  • P2: degradación significativa a medida que crece el volumen o la concurrencia, con margen actual o una ruta alternativa.
  • P3: faltan límites, observabilidad, pruebas o evidencia de mantenibilidad sin una falla severa demostrada.

No asigne P0 o P1 solo con suposiciones de diagnóstico. Coloque los riesgos graves pero no respaldados bajo verificación de alta prioridad.

7. Escribir el informe

Cargue references/output-contract.md y sígalo exactamente.

Cada hallazgo debe incluir:

  • Severidad y estado de evidencia.
  • Capa y código de causa raíz estable.
  • Ubicación de la evidencia.
  • Escala de activación.
  • Impacto.
  • Mitigación mínima.
  • Método de verificación.

Enumere los caminos seguros confirmados solo cuando la evidencia los respalde.

Límites del Repositorio y la Salida

  • Enumere como máximo 100,000 rutas como metadatos; reduzca por directorio y extensión por encima de eso.
  • Escanee como máximo 20,000 archivos fuente o 500 MiB de texto por pase de contenido, lo que ocurra primero.
  • Retenga como máximo 500 coincidencias candidatas; agregue el resto y registre el recuento truncado.
  • Lea en profundidad como máximo 200 archivos candidatos por pase.
  • Utilice un tiempo de espera de comando predeterminado de 60 segundos; reduzca el alcance después de un tiempo de espera.
  • Expanda como máximo 50 hallazgos y 5 ubicaciones de evidencia representativas por causa raíz.
  • Omita dependencias, salida generada, archivos comprimidos, binarios, directorios de compilación y archivos grandes minificados.
  • Reporte cada exclusión y truncamiento con el recuento original, el recuento retenido y el motivo.

Evidencia Faltante y Fallos

  • Solo frontend: revise el frontend y genere un contrato de backend/API/base de datos No Verificado.
  • Solo backend: revise el backend y marque el renderizado y la interacción del consumidor como No Verificado.
  • Repositorio sobredimensionado: reduzca desde diff, rutas, clientes, consultas, exportaciones y puntos de entrada de renderizado.
  • Tiempo de espera de comando: reduzca el lote o el alcance de la ruta en lugar de aumentar repetidamente el tiempo de espera.
  • Conflictos de documentación con el código: prefiera código, pruebas, planes de consulta y evidencia de tiempo de ejecución; reporte la desviación de la documentación.
  • Material sensible: no repita secretos ni registros; utilice una descripción de ubicación redactada.

Skills relacionados