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 mantenedores de la obsoleta idea comunitaria de auditoría de producción: mantiene el útil enfoque de preparación para producción y elimina la ejecución externa no anclada y el intercambio de datos con terceros.

Cuándo Usar

• El usuario pregunta "¿esto está listo para producción?", "¿qué fallaría en prod?", "¿qué nos perdimos?", "audita este repositorio" o "¿listo para enviar?"
• Se fusionó una funcionalidad y necesita un pase de riesgos previo 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 enfoque adecuado es la codificación segura a nivel de línea; usa primero security-review.
• Para bibliotecas puras, plantillas, repositorios solo de documentación o andamios, a menos que el usuario quiera preparación para empaquetado/lanzamiento en lugar de preparación de la aplicación.
• Cuando el usuario solicita una auditoría de cumplimiento formal. Esta habilidad es triaje 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 anclado, 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 enviar/bloquear 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 verificaciones de inicio.
• Ganchos de observabilidad, informes de errores, registros, verificaciones de estado y paneles.
• Instrucciones de reversión, siembra, migración y relleno.
• Cobertura E2E para las rutas de usuario más importantes.

Si una URL desplegada está dentro del alcance, usa solo verificaciones HTTP o de navegador contra esa URL y evita acciones autenticadas a menos que el usuario proporcione una cuenta de prueba segura.

Enfoques de Riesgo

Seguridad y Autenticación

• ¿Están claramente separadas las rutas públicas, las rutas de API y las rutas de administración?
• ¿Se aplican la autenticación y autorización del lado del servidor?
• ¿Se mantienen los secretos fuera de los paquetes del cliente, registros, resultados de ejemplo y archivos verificados?
• ¿Están presentes los límites de tasa, protecciones CSRF, política CORS y validación de subida 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 forma segura por etapas?
• ¿Las políticas de base de datos, concesiones y límites de rol 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 carga útil confiables?
• ¿Es idempotente cada webhook de pago, suscripción o cumplimiento?
• ¿Se manejan la reproducción, entrega duplicada y entrega fuera de orden?
• ¿Están separadas las credenciales de modo de prueba y modo real?

Operaciones

• ¿Puede la aplicación iniciarse desde un checkout limpio usando comandos documentados?
• ¿Están nombradas, validadas y con fallo rápido las variables de entorno requeridas?
• ¿Hay una verificación de estado que demuestre que las dependencias son alcanzables?
• ¿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 lo que sucedió?
• ¿Hay una ruta de soporte o recuperación cuando falla una operación crítica?

Puntuación

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

Banda	Puntuación	Significado
Bloqueado	0-49	No enviar hasta que se corrijan los riesgos principales
Riesgoso	50-69	Enviar solo detrás de un lanzamiento pequeño o beta interna
Lanzable con Advertencias	70-84	Enviar si los propietarios aceptan los riesgos listados
Fuerte	85-100	Sin bloqueadores obvios de lanzamiento 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 se pueden ejecutar de forma segura.
• Los secretos están expuestos en paquetes del 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 documentación 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 verificada: archivos, comandos, CI, URL desplegada o PR inspeccionados.
• Evidencia faltante: qué cambiaría la confianza si se proporcionara.
• Siguiente acción: una corrección concreta o paso de verificación.

Mantén las fortalezas breves. El usuario preguntó por preparación, por lo que la respuesta útil es el riesgo restante y la siguiente acción.

Ejemplo

Usuario:

¿Esto está 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 verificación de estado que verifique la alcanzabilidad de la base de datos y del proveedor de pagos.
- Agregar una ruta E2E para actualización, cumplimiento de webhook y actualización de la página de facturación.

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

Siguiente acción: ¿Quieres que parche primero la idempotencia del webhook?

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 verificada.
• Tratar 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