165 lines
4.6 KiB
Markdown
165 lines
4.6 KiB
Markdown
# Rebuild Decisions
|
|
**Project:** myLesen Rebuild
|
|
**Last updated:** 2026-05-08
|
|
**Owner:** [Saufi / Inhouse]
|
|
**Reference:** `rebuild-architecture.md`
|
|
|
|
> Dokumen ini menyimpan keputusan yang telah dimuktamadkan.
|
|
> Jangan letak task harian di sini.
|
|
> Jangan letak brainstorming panjang di sini.
|
|
> Hanya keputusan yang sudah dipersetujui.
|
|
|
|
---
|
|
|
|
## 1. Cara Guna Dokumen Ini
|
|
|
|
Setiap keputusan mesti ada:
|
|
- status: `confirmed` / `pending` / `rejected`
|
|
- tarikh
|
|
- pemilik keputusan
|
|
- rasional ringkas
|
|
- impak kepada codebase
|
|
|
|
Format:
|
|
|
|
```md
|
|
### [DECISION-ID] Tajuk keputusan
|
|
- Status:
|
|
- Tarikh:
|
|
- Owner:
|
|
- Rujuk bahagian architecture:
|
|
- Keputusan:
|
|
- Rasional:
|
|
- Impak:
|
|
- Tindakan susulan:
|
|
|
|
[DEC-001] Single Admin Theme
|
|
Status: pending
|
|
Tarikh: -
|
|
Owner: -
|
|
Rujuk bahagian architecture: 5.2, 8.3
|
|
Keputusan:
|
|
Belum dipilih theme utama yang akan dikekalkan.
|
|
Rasional:
|
|
Architecture mencadangkan satu theme sahaja untuk memudahkan maintenance.
|
|
Impak:
|
|
Akan menentukan folder theme dalam public/ yang dikekalkan atau dibuang.
|
|
Tindakan susulan:
|
|
Audit semua theme aktif dalam layout, blade include, dan asset reference.
|
|
Pilih 1 theme aktif sebenar sebelum cleanup theme dijalankan.
|
|
[DEC-002] PBTPay Scope
|
|
Status: pending
|
|
Tarikh: -
|
|
Owner: -
|
|
Rujuk bahagian architecture: 6.5, 10
|
|
Keputusan:
|
|
Belum dimuktamadkan sama ada PBTPay akan diimplement atau dibuang dahulu.
|
|
Rasional:
|
|
Blueprint mencadangkan pilihan B dahulu: keluarkan PBTPay stubs untuk kurangkan beban codebase.
|
|
Impak:
|
|
Akan menentukan sama ada controller/model/view/route PBTPay dibuang atau diteruskan.
|
|
Tindakan susulan:
|
|
Sahkan keperluan bisnes sebenar dengan stakeholder.
|
|
Jika out of scope, label semua artifact PBTPay sebagai calon removal.
|
|
[DEC-003] EPBT Billing Mode
|
|
Status: pending
|
|
Tarikh: -
|
|
Owner: -
|
|
Rujuk bahagian architecture: 6.1, 10
|
|
Keputusan:
|
|
Mod semasa belum dimuktamadkan:
|
|
manual EPBT dahulu
|
|
atau aktifkan auto-generate bil selepas UAT
|
|
Rasional:
|
|
Blueprint mencadangkan aktifkan auto-generate secara berperingkat, bukan terus production.
|
|
Impak:
|
|
Menentukan sama ada janaBil() dihidupkan, dan bila.
|
|
Tindakan susulan:
|
|
Confirm akses endpoint EPBT.
|
|
Confirm client_key, host, dan konfigurasi network.
|
|
[DEC-004] Terminal Status Permohonan
|
|
Status: pending
|
|
Tarikh: -
|
|
Owner: -
|
|
Rujuk bahagian architecture: 3.1, 10
|
|
Keputusan:
|
|
Belum dimuktamadkan sama ada status terminal rasmi ialah:
|
|
lesen dikeluarkan
|
|
atau kekal keputusan diperolehi + flag tambahan
|
|
Rasional:
|
|
Blueprint mencadangkan lesen dikeluarkan sebagai status terminal yang lebih jelas.
|
|
Impak:
|
|
Menentukan enum, badge UI, query dashboard, dan audit trail.
|
|
Tindakan susulan:
|
|
Sahkan flow semasa dengan pengguna PT/admin.
|
|
[DEC-005] Clarify no_fail_lesen vs no_akaun_lesen
|
|
Status: pending
|
|
Tarikh: -
|
|
Owner: -
|
|
Rujuk bahagian architecture: 6.3, 10
|
|
Keputusan:
|
|
Belum ada definisi rasmi yang dipersetujui.
|
|
Rasional:
|
|
Nama field hampir sama tetapi peranan mungkin berbeza.
|
|
Impak:
|
|
Risiko bug pada simpanan no. fail/no. akaun, mesej UI, laporan, dan API export.
|
|
Tindakan susulan:
|
|
Dapatkan definisi operasi sebenar daripada PT / pentadbiran.
|
|
[DEC-006] Role pp tadbir vs pegawai tadbir
|
|
Status: pending
|
|
Tarikh: -
|
|
Owner: -
|
|
Rujuk bahagian architecture: 4.1, 10
|
|
Keputusan:
|
|
Belum dimuktamadkan sama ada dua role ini sama atau berbeza.
|
|
Rasional:
|
|
Blueprint mencadangkan digabungkan jika fungsi operasi sama.
|
|
Impak:
|
|
Menentukan enum role, policy, middleware, dashboard, dan permission matrix.
|
|
Tindakan susulan:
|
|
Audit penggunaan sebenar dalam middleware, controller, dan data user semasa.
|
|
[DEC-007] Email Notification Scope
|
|
Status: pending
|
|
Tarikh: -
|
|
Owner: -
|
|
Rujuk bahagian architecture: 10
|
|
Keputusan:
|
|
Belum dimuktamadkan sama ada email notification dimasukkan dalam Fasa 1 atau ditangguh.
|
|
Rasional:
|
|
Blueprint cadangkan tangguh dahulu.
|
|
Impak:
|
|
Menentukan sama ada perlu siapkan mail config, notification classes, dan queue mail.
|
|
Tindakan susulan:
|
|
Confirm expectation pemohon dan stakeholder.
|
|
[DEC-008] Fasa 0 Cleanup Rule
|
|
Status: confirmed
|
|
Tarikh: 2026-05-08
|
|
Owner: team rebuild
|
|
Rujuk bahagian architecture: 9.1
|
|
Keputusan:
|
|
Fasa 0 hanya untuk cleanup.
|
|
Tiada perubahan business logic.
|
|
Tiada perubahan schema database.
|
|
Tiada refactor controller aktif.
|
|
Rasional:
|
|
Elak cleanup bercampur dengan refactor dan susahkan debugging.
|
|
Impak:
|
|
Semua task Fasa 0 mesti reversible dan kecil.
|
|
Tindakan susulan:
|
|
Audit dulu, execute cleanup secara bertahap, test route aktif selepas setiap perubahan.
|
|
[DEC-009] Fasa 1 Scope Rule
|
|
Status: confirmed
|
|
Tarikh: 2026-05-08
|
|
Owner: team rebuild
|
|
Rujuk bahagian architecture: 9.2
|
|
Keputusan:
|
|
Fasa 1 dipecahkan kepada 3 blok:
|
|
Enum + Config
|
|
Services + FormRequest
|
|
Policy + Audit Trail
|
|
Rasional:
|
|
Bagi AI dan developer fokus pada unit kerja kecil.
|
|
Impak:
|
|
Prompt execution mesti ikut blok ini, bukan campur semua sekali.
|
|
Tindakan susulan:
|
|
Update rebuild-execution.md mengikut blok. |