Rà soát dự án: kiểm toán và kế hoạch cải thiện (tiếng Tây Ban Nha) — Revisor-Diagnóstico-Proyecto: Auditoría + Plan de Mejora

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