Setiap dimensi menjawab satu pertanyaan yang sama: apakah ada transaksi yang bisa kena kedua rule ini sekaligus?
Clash = Ya kalau SEMUA dimensi Beririsan. Satu dimensi Terpisah saja sudah cukup membuat aman.
Tidak ada lagi istilah sama / beda / bersilangan / tidak bersilangan.
Cek Dua Rule
Untuk tiap dimensi, pilih hubungan antara Rule 1 dan Rule 2. Kolom kanan menunjukkan kontribusinya ke verdict.
Tiga Bentuk Irisan
Ketiganya sama-sama Beririsan. Bentuk hanya menentukan cara mengeceknya di kode, bukan verdict-nya.
Identik
Dua lingkaran menumpuk sempurna.
Produk X vs Produk X
Tumpang tindih
Masing-masing rule masih punya wilayah sendiri yang tidak disentuh rule lain.
Yang bentrok cuma 15–31 Jan
Menelan
Rule yang kecil tidak punya wilayah sendiri sama sekali.
Setiap transaksi Rule 2 pasti kena Rule 1
Menelan paling sering lolos dari perhatian. Dari sisi admin rasanya tidak sedang
membuat aturan bentrok — dia cuma mengosongkan satu field. Padahal di sistem, field kosong bukan
berarti "tidak ada aturan", tapi "semua". Mengosongkan field membuat scope melebar, bukan menyempit.
Kasus Dasar
Contoh konkret, lalu ditambahi kondisi satu per satu supaya kelihatan kapan verdict berubah.
Rule 1
Produk 123 · Pembayaran Penuh · periode kosong · email kosong
diskon 10%
Rule 2
Produk 123 · Pembayaran Penuh · periode kosong · email kosong
diskon Rp10.000
block
Clash
Kelima dimensi beririsan, jadi setiap transaksi Produk 123 cocok ke kedua rule
dan sistem tidak punya dasar memilih salah satunya.
Jebakan di kasus ini. Harga Produk 123 = Rp100.000, jadi 10% × Rp100.000 = Rp10.000 —
kedua rule kebetulan menghasilkan potongan yang sama persis. Terlihat seperti "ya sudah, pakai
yang mana saja". Itu keliru: ekuivalensinya cuma kebetulan dan langsung pecah begitu harga berubah.
Kalau harga naik jadi Rp200.000, Rule 1 memberi Rp20.000 sementara Rule 2 tetap Rp10.000.
Inilah alasan clash harus ditolak saat konfigurasi, bukan diselesaikan saat redeem —
sistem tidak boleh mengambil keputusan yang benar hari ini tapi salah bulan depan.
Asumsi. Di PRD, Skema Pembayaran tercatat wajib diisi, jadi "tanpa kondisi lainnya"
tidak bisa berarti skema dikosongkan. Di sini dibaca sebagai kedua rule memakai skema yang sama.
Kalau ternyata skema boleh dikosongkan, dia ikut punya bentuk Menelan seperti Periode dan Email.
Kalau Dikombinasikan dengan Kondisi Lain
Cukup satu
Tidak perlu memutus semua dimensi. Satu dimensi Terpisah sudah cukup — W13 memutus dua sekaligus, aman tapi berlebihan.
Bukan soal jumlah
Menambah kondisi tidak otomatis menyelamatkan. W15 mengisi semua kondisi tapi isinya sama, jadi tetap clash.
Payload tidak menolong
W16–W19: kuota, kuota per pengguna, besar nilai, dan tipe diskon tidak pernah mengubah verdict.
Glosarium
Istilah yang perlu satu arti yang sama di tim PM, Tech, dan QA.
Klasifikasi 8 Kondisi PRD
Kedelapan kondisi bukan jenis yang sama. Hanya 5 yang menentukan clash.
Intinya. Kuota Diskon Umum, Kuota per Pengguna, Budget, dan tipe diskon adalah payload —
tidak pernah menyelamatkan rule dari clash, tapi punya aturan sendiri saat redeem. Periode Diskon adalah
pembatas, bukan pembanding antar-rule.
Kamus Irisan per Dimensi
Tiga jenis pengecekan yang berbeda di kode. Produk butuh containment check,
Periode butuh date range overlap, Email butuh set intersection — dan yang terakhir ini paling baru,
karena dua daftar email bisa tumpang tindih sebagian.
M1 · Deteksi Irisan per Dimensi
Membuktikan tiap dimensi mengenali irisan dengan benar, satu per satu.
M2 · Kombinasi AND
Truth table lengkap 5 dimensi. Hanya satu kombinasi yang clash.
Untuk QA cukup 6 baris. Satu baris semua-beririsan, plus lima baris
yang masing-masing memutus tepat satu dimensi. Sisanya redundan secara logika.
M3 · Tipe Diskon Tidak Mengubah Verdict
Verdict harus identik di ketiga varian tipe pada skenario yang sama.
Bug yang paling mungkin di sini. Engineer memasukkan
tipe_diskon ke dalam unique constraint database. Kalau itu terjadi, TD1-C lolos padahal
seharusnya ditolak, dan baru ketahuan saat user komplain dapat potongan yang salah.
M4 · Limit Konsumsi & Budget
Kuota dan budget tidak pernah memengaruhi clash. Mereka punya aturannya sendiri.
L10 adalah gap yang belum ada di PRD manapun. Kalau user melanggar
tiga limit sekaligus, pesan error mana yang muncul? Tanpa urutan yang ditetapkan, tiap engineer akan
menebak sendiri dan pesan errornya jadi tidak konsisten antar-endpoint.
M5 · Periode Diskon sebagai Kontainer
Periode Diskon tidak pernah dibandingkan antar-rule. Ia membatasi Periode Aturan Diskon.
Peta Test Case QA Existing
Model baru tidak mengubah satu pun verdict — cuma menamai ulang state-nya.
Dua duplikat langsung kelihatan. Baris 6 duplikat baris 5.
Baris 12 duplikat baris 2, karena "tidak bersilangan" dan "beda" ternyata state yang sama.
Artinya 13 baris test case existing sebenarnya hanya menguji 11 kasus unik.
Open Decision
Sembilan hal yang belum bisa disimpulkan dari PRD dan 1-Pager yang ada.
Diturunkan dari PRD - Diskon [Admin], 1-Pager Rules Diskon, dan test case clash QA.