auditoría-de-producción

Auditoría de Producción

Usa esta habilidad cuando el usuario pregunte si una aplicación está lista para enviar, qué podría fallar en producción, o qué debe arreglarse antes de un lanzamiento. Esta es una reescritura segura para el mantenedor de la idea obsoleta de auditoría de producción de la comunidad: mantiene el lente útil de preparación para producción y elimina la ejecución remota no fijada y el intercambio de datos con terceros.

Cuándo Usar

• El usuario pregunta "¿está esto listo para producción?", "¿qué fallaría en prod?", "¿qué nos perdimos?", "audita este repositorio" o "¿listo para enviar?"
• Se fusionó una característica y necesita una revisión de riesgos previa al despliegue o posterior a la fusión.
• Se acerca un lanzamiento público, demo, implementación para un cliente, o recorrido para inversores.
• CI está verde pero el usuario quiere riesgos de producción, no solo estado de pruebas.
• Una URL desplegada, rama de lanzamiento, PR o checkout actual está disponible para recopilar evidencia.

Cuándo No Usar

• Durante la implementación activa cuando el lente correcto es codificación segura a nivel de línea; usa security-review primero.
• Para bibliotecas puras, plantillas, repositorios solo de documentación, o scaffolds a menos que el usuario quiera preparación para empaquetado/lanzamiento en lugar de preparación de aplicación.
• Cuando el usuario solicita una auditoría de cumplimiento formal. Esta habilidad es triage de ingeniería, no certificación legal, financiera, médica o regulatoria.
• Cuando la única evidencia disponible es una idea de producto sin repositorio, despliegue, CI o superficie de ejecución.

Cómo Funciona

Construye la auditoría a partir de evidencia local y autorizada por el usuario. No ejecutes código remoto no fijado, subas contenidos del repositorio a servicios de terceros, ni llames a escáneres externos a menos que el usuario apruebe explícitamente esa herramienta y flujo de datos específicos.

Usa este orden:

1. Establece la superficie de lanzamiento.
2. Lee cambios recientes y el estado actual de la rama.
3. Inspecciona los límites de ejecución, autenticación, datos, pagos, trabajos en segundo plano, IA y despliegue que realmente existen en el repositorio.
4. Verifica CI, pruebas, migraciones, documentación del entorno y ruta de reversión.
5. Produce una recomendación corta de envío/bloqueo con correcciones específicas.

Lista de Verificación de Evidencia

Comienza con señales locales y económicas:

git status --short --branch
git log --oneline --decorate -20
git diff --stat origin/main...HEAD

Luego inspecciona la superficie específica del proyecto:

• Scripts de paquete, flujos de trabajo de CI, scripts de lanzamiento, archivos Docker y manifiestos de despliegue.
• Rutas de API, webhooks, middleware de autenticación, trabajadores en segundo plano, trabajos cron y migraciones de base de datos.
• Documentación de variables de entorno y comprobaciones de inicio.
• Ganchos de observabilidad, informes de errores, registros, comprobaciones de salud y paneles.
• Instrucciones de reversión, siembra, migración y relleno.
• Cobertura E2E para las rutas de usuario que más importan.

Si una URL desplegada está en alcance, usa solo comprobaciones de navegador o HTTP contra esa URL y evita acciones con credenciales a menos que el usuario proporcione una cuenta de prueba segura.

Lentes de Riesgo

Seguridad y Autenticación

• ¿Están claramente separadas las rutas públicas, rutas de API y rutas de administración?
• ¿Se aplican la autenticación y autorización del lado del servidor?
• ¿Se mantienen los secretos fuera de los paquetes de cliente, registros, salida de ejemplo y archivos verificados?
• ¿Están presentes límites de tasa, protecciones CSRF, política CORS y validación de carga donde la aplicación los necesita?
• ¿La superficie de IA o agente se defiende contra inyección de prompts, abuso de herramientas y contenido no confiable que cruza hacia acciones privilegiadas?

Integridad de Datos

• ¿Las migraciones se ejecutan limpiamente hacia adelante y tienen un plan de reversión o recuperación?
• ¿Las migraciones destructivas, rellenos e importaciones de datos se realizan de manera segura?
• ¿Las políticas de base de datos, concesiones y límites de roles de servicio coinciden con el modelo de tenencia de la aplicación?
• ¿Son idempotentes los reintentos para escrituras, trabajos y manejadores de webhook?

Pagos y Webhooks

• ¿Se verifican las firmas de webhook antes de analizar campos de payload confiables?
• ¿Es idempotente cada webhook de pago, suscripción o cumplimiento?
• ¿Se manejan reproducciones, entregas duplicadas y entregas fuera de orden?
• ¿Están separadas las credenciales de modo de prueba y modo en vivo?

Operaciones

• ¿Puede la aplicación iniciarse desde un checkout limpio usando comandos documentados?
• ¿Están nombradas, validadas y fallan rápidamente las variables de entorno requeridas?
• ¿Existe una comprobación de salud que demuestre que las dependencias son accesibles?
• ¿Están documentadas las rutas de despliegue, reversión y propietario de incidentes?
• ¿Son útiles los registros sin filtrar secretos ni datos personales?

Experiencia de Usuario

• ¿Están cubiertas las rutas críticas de lanzamiento en escritorio y móvil?
• ¿Son utilizables los formularios en móvil sin zoom de entrada, superposición de diseño o estados de envío bloqueados?
• ¿Los estados de carga, vacío, error y permiso denegado informan al usuario qué sucedió?
• ¿Existe una ruta de soporte o recuperación cuando falla una operación crítica?

Puntuación

Usa puntuaciones para forzar priorización, no para implicar certeza matemática.

Banda	Puntuación	Significado
Bloqueado	0-49	No enviar hasta que se solucionen los riesgos principales
Riesgoso	50-69	Enviar solo detrás de un despliegue pequeño o beta interna
Lanzable con Advertencias	70-84	Enviar si los propietarios aceptan los riesgos listados
Sólido	85-100	Sin bloqueadores de lanzamiento obvios según la evidencia disponible

Limita la puntuación a 69 si alguna de estas es cierta:

• Falta autenticación o autorización en datos sensibles.
• Los webhooks de pago o cumplimiento no son idempotentes.
• Las migraciones requeridas no pueden ejecutarse de manera segura.
• Los secretos están expuestos en paquetes de cliente, registros o archivos confirmados.
• No hay ruta de reversión para un lanzamiento de alto impacto.

Limita la puntuación a 84 si CI no está verde o la ruta crítica de lanzamiento no fue probada de extremo a extremo.

Formato de Salida

Comienza con una oración:

Auditoría de producción: 76/100, lanzable con advertencias, con idempotencia de webhook y documentos de reversión como los dos riesgos a corregir antes del lanzamiento público.

Luego lista:

• Bloqueadores: elementos que deben corregirse antes del despliegue.
• Correcciones de alto valor: siguientes correcciones si el usuario quiere mejorar la puntuación.
• Evidencia comprobada: archivos, comandos, CI, URL desplegada o PRs inspeccionados.
• Evidencia faltante: qué cambiaría la confianza si se proporcionara.
• Próximo paso: una corrección concreta o paso de verificación.

Mantén las fortalezas cortas. El usuario pidió preparación, por lo que la respuesta útil es el riesgo restante y el próximo paso.

Ejemplo

Usuario:

¿Está esto listo para enviar?

Respuesta:

Auditoría de producción: 68/100, riesgoso, porque los webhooks de Stripe están verificados pero no son idempotentes y no hay nota de reversión para la migración pendiente.

Bloqueadores:
- Agregar idempotencia para `checkout.session.completed` antes de cumplir pedidos.
- Escribir y probar la ruta de reversión para `20260511_add_billing_state.sql`.

Correcciones de alto valor:
- Agregar una comprobación de salud que verifique la accesibilidad de la base de datos y el proveedor de pagos.
- Agregar una ruta E2E para actualización, cumplimiento de webhook y actualización de página de facturación.

Evidencia comprobada:
- `api/stripe/webhook.ts`
- `db/migrations/20260511_add_billing_state.sql`
- Ejecución de GitHub Actions para la rama de lanzamiento

Próximo paso: ¿Quieres que parche la idempotencia del webhook primero?

Anti-Patrones

• Ejecutar npx <paquete>@latest o un escáner remoto como ruta de auditoría predeterminada.
• Subir fuente, secretos, datos de clientes o topología privada a un servicio de auditoría externo sin aprobación explícita.
• Producir una puntuación sin nombrar la evidencia comprobada.
• Tratar un CI verde como preparación para producción.
• Terminar con un genérico "dime qué quieres hacer".

Ver También

• Habilidad: security-review
• Habilidad: deployment-patterns
• Habilidad: e2e-testing
• Habilidad: tdd-workflow
• Habilidad: verification-loop