Actualización de producto KENSAI: la evidencia de las pruebas nocturnas reemplaza las métricas de consuelo

El 26 de abril empezó con el tipo de fallo que un sistema útil debería conservar en vez de suavizar: la suite freemium nocturna no pasó. La buena noticia es que ahora el fallo es lo bastante preciso como para corregirlo.

Lo que demostró la ejecución nocturna

El recibo cron del 26 de abril registró la suite freemium completa de KENSAI desde el repositorio de plataforma. El resultado no fue un build rojo vago. Fue un mapa de fallo concreto: pnpm test terminó con código 1 tras 636 pruebas, con 310 fallidas, 243 aprobadas y 83 omitidas.

La clase de fallo dominante fueron pruebas apoyadas en la API que esperaban un servicio en 127.0.0.1:4000 mientras la API no estaba disponible, generando rechazos de conexión y aserciones de estado cero. Eso no es un misterio del producto. Es un defecto de preflight y de orquestación de servicios.

Qué faltaba

Se registraron dos huecos más en lugar de esconderlos. El paquete raíz no definía pnpm test:e2e, así que el runner no tenía una entrada e2e estable. El comando de cobertura falló de inmediato porque faltaba @vitest/coverage-v8. Un fallback directo con Playwright sí arrancó, pero el ruido de errores de auth/admin y timeouts de un minuto lo hacía más honesto de matar que venderlo como señal útil.

Por qué esto es una actualización de producto

Una ejecución de pruebas fallida no es progreso automáticamente. Una ejecución fallida con conteos, clases de error dominantes, herramientas ausentes y una ruta clara de reparación sí lo es. El sistema de calidad ahora distingue entre comportamiento de aplicación roto e infraestructura que nunca arrancó.

Eso importa para KENSAI porque las afirmaciones de seguridad de cara al cliente dependen de una verdad operativa aburrida. Si el flujo freemium necesita la API, el runner debe arrancarla o verificarla antes de empezar. Si la cobertura es un gate obligatorio, el provider debe estar instalado. Si e2e forma parte de la historia de release, necesita un script real en lugar de una convención implícita.

Siguiente ruta de reparación

La secuencia de reparación ya está clara: añadir o restaurar un script raíz test:e2e, instalar el provider de cobertura y hacer que el runner freemium arranque y compruebe la salud de la API en el puerto 4000 antes de ejecutar pruebas dependientes de la API. Todo lo demás sería teatro.

Ese es el estándar que KENSAI debería mantener: conservar la medición incómoda, nombrar las precondiciones rotas y convertir una ejecución roja en una lista corta de arreglos.

Conclusión

El estándar útil es simple: una afirmación se vuelve real cuando el prerrequisito, el artefacto y la ruta se alinean. El trabajo de hoy mantiene visible ese estándar.