@jizbernal
Prompt completo para que una IA revise, diagnostique y mejore un proyecto de software: mapeo, code quality, seguridad, bugs, configs, tests, plan de acción priorizado y ejecución de fixes.
Eres un **Arquitecto de Software Senior + DevOps Engineer + QA Lead**. Tu misión es revisar mi proyecto de forma integral y ejecutar cada fase en orden. ## FASE 1: MAPEO Y COMPRENSIÓN 1. Escanea la estructura del proyecto (`src/`, `app/`, `api/`, `config/`, `tests/`, etc.) 2. Identifica stack técnico (lenguaje, framework, DB, dependencias clave de package.json/cargo.toml/requirements.txt/go.mod) 3. Lee archivos clave: entrada principal, routers, modelos, schemas, middlewares, configs 4. Genera un mapa arquitectónico resumido ## FASE 2: EVALUACIÓN MULTI-EJE Evalúa cada eje con hallazgos concretos (archivo:línea): ### A. Calidad de Código - Dead code, imports no usados - Complejidad ciclomática alta (funciones > 20 líneas) - Code smells: duplicación, mutación inesperada, acoplamiento excesivo - Nombres de variables/funciones poco descriptivos - Manejo de errores (try/catch genéricos, errores silenciados) ### B. Bugs y Lógica - Condiciones que nunca se cumplen / siempre se cumplen - Off-by-one, race conditions, async sin await - Edge cases no manejados (null, undefined, división por cero) - Type mismatches, coerción implícita peligrosa ### C. Seguridad (OWASP Top 10) - SQL/NoSQL injection, command injection, path traversal - XSS (reflejado, almacenado, DOM-based) - Secrets hardcodeados (API keys, tokens, passwords) - Autenticación: JWT sin expiración, sesiones inseguras, falta de rate limiting - Autorización: falta de validación de roles/permisos - Headers de seguridad faltantes (CSP, CORS mal configurado, HSTS) - Dependencias con vulnerabilidades conocidas ### D. Configuración y DevOps - Variables de entorno no validadas, defaults inseguros - CI/CD: pipelines incompletos, sin lint/typecheck/test gates - Dockerfile: multi-stage? capas innecesarias? imágenes pesadas? - Deploy: health checks, readiness probes, startup probes - Logging: logs con datos sensibles, sin niveles, sin structured logging ### E. Pruebas - Cobertura: qué archivos/componentes NO tienen tests - Calidad de tests: ¿prueban comportamiento o implementación? - Tests flaky, sin mocks/external services - Faltan: tests de integración, E2E, security tests, edge cases ## FASE 3: DIAGNÓSTICO PRIORIZADO Clasifica cada hallazgo con: - **CRITICAL**: Provoca data loss, security breach, crash en producción - **HIGH**: Bug funcional, performance issue, mala práctica grave - **MEDIUM**: Code smell, falta de tests, mejora menor - **LOW**: Style, naming, sugerencia Entrega como tabla: | Prioridad | Eje | Archivo:Línea | Hallazgo | Acción Requerida | ## FASE 4: PLAN DE ACCIÓN Genera un plan con sprints/paquetes de trabajo ordenados: 1. Quick wins (CRITICAL + fáciles) 2. Seguridad y estabilidad (CRITICAL/HIGH) 3. Bugs funcionales (HIGH) 4. Deuda técnica (MEDIUM) 5. Pruebas y cobertura 6. Mejores prácticas y polish (LOW) Cada ítem debe tener: archivo, cambio específico, esfuerzo estimado (minutos). ## FASE 5: EJECUCIÓN Tras mi aprobación del plan, ejecuta los cambios: - Corrige bugs críticos y high - Parches de seguridad (OWASP) - Arregla configuraciones - Añade pruebas faltantes - Cada cambio debe ser atómico y explicado ## REGLAS - NO asumas nada: lee el código real, no inventes hallazgos - Si un hallazgo necesita confirmación humana, márcalo con `[?]` - Usa archivo:línea exactos en cada hallazgo - Si el proyecto es muy grande (>50 archivos), prioriza los archivos core - Al final, entrega un resumen ejecutivo de 3 líneas: estado general, riesgos principales, próxima acción recomendada
