00 README MULAI DI SINI

SAKILA — Baseline PRD v2.1 untuk audit dan rencana modernisasi

Tanggal: 11 Oktober 2026. Status: AUDIT-READY. Tidak sama dengan persetujuan deploy atau pengesahan otomatis seluruh keputusan bisnis.

SAKILA adalah ERP SaaS lintas organisasi. UMV adalah salah satu organisasi; wakaf Al-Qur’an Braille adalah salah satu program UMV. Program ≠ campaign ≠ modul perangkat lunak.

Mulai dari sini

1. 16_PENETAPAN_BASELINE_AUDIT.md: acuan dan cara menangani konflik.
2. 17_KEPUTUSAN_IMPLEMENTASI_DAN_ADR.md: aturan desain aman dan keputusan bisnis yang belum sah.
3. 18_GERBANG_GO_NO_GO_DEPLOY.md: secara eksplisit menentukan apa yang boleh dilakukan sekarang.
4. 19_PAKET_KERJA_AGENT_AUDIT.md: instruksi audit dan rekomendasi reuse/refactor/rewrite per komponen.
5. 01–15: seluruh cakupan Candidate 2.0 dan bukti sebelumnya, tidak dihapus.
6. MATRIKS_REQUIREMENT.csv: pekerjaan per requirement dan evidence.

Yang sudah tuntas: paket konsolidasi, kebijakan baseline audit, gerbang rilis dan kontrak penugasan Agent. Yang belum tuntas secara faktual: pemeriksaan butir demi butir terhadap seluruh PRD warisan, keputusan komersial tertentu, pengujian end-to-end, dan persetujuan deploy. Dokumen ini tidak menyembunyikan hal tersebut.

01 PRD PRODUK DAN BISNIS

01 — PRD Produk, nilai bisnis dan batas cakupan

Status: DRAF editorial; keputusan resmi pemilik yang dikutip tetap berlaku.

1.1 Masalah yang diselesaikan

Lembaga mengelola orang, uang, program, komunikasi, bantuan, bukti pelaksanaan dan pelaporan dengan banyak alat terpisah. Dampaknya: input berulang, pembagian wewenang tidak jelas, histori koreksi kabur, dan bukti dampak sukar ditelusuri. SAKILA menargetkan satu alur kerja yang terhubung dan dapat diaudit, tanpa memaksakan model operasional satu lembaga kepada lembaga lain.

1.2 Posisi produk

SAKILA = ERP SaaS lintas organisasi, dengan web backoffice, aplikasi mobile Flutter dan API backend yang menjadi sumber data bersama. Bukan aplikasi wakaf Braille generik, bukan perangkat lunak yang wajib memakai WhatsApp/AI, dan bukan sistem keuangan yang boleh memotong persentase donasi.

1.3 Segmen dan aktor

Pelanggan adalah organisasi/lembaga (yayasan, LSM, rumah ibadah, dan organisasi sosial relevan). Pengguna meliputi administrator lembaga, pengelola program, petugas keuangan, CS/CRM, pelaksana lapangan, pimpinan, auditor, dan pengguna publik sesuai modul serta izin. Role yang tepat tidak diputuskan lewat contoh ini; matriks izin detail mengacu ke PRD V5.2 §02/§04.

1.4 Janji inti

1. Data organisasi dipisahkan dengan ketat.
2. Program beragam dan tidak dikunci ke jenis wakaf tertentu.
3. Modul dapat dikombinasikan menurut kebutuhan organisasi dan ketentuan paket.
4. Peristiwa finansial dan perubahan kritis mempunyai jejak audit.
5. Semua jalur penting dapat dioperasikan secara aksesibel.
6. Modul/program khusus tetap bisa dipakai lembaga awal tanpa menjadi default universal.

1.5 Model bisnis resmi

Freemium SaaS dengan layanan premium dan white-label; tidak mengambil persentase dari donasi/wakaf. Integrasi AI dan komunikasi menggunakan prinsip BYOK per lembaga (biaya provider bukan dibebankan diam-diam kepada pemilik platform). Detail harga, kuota, SLA, fitur paket dan penagihan belum disetujui dalam paket ini.

1.6 Contoh yang dapat dipahami semua orang

• UMV: menyelenggarakan program wakaf Al-Qur'an Braille; menggunakan modul penghimpunan, keuangan, logistik, penyaluran dan laporan; dapat memakai logika Braille spesifik.
• Yayasan pendidikan: menyelenggarakan beasiswa; memakai pendaftaran, asesmen, persetujuan dana dan laporan tanpa logika Braille.
• Masjid: menyelenggarakan program pembangunan atau bantuan jamaah dengan kombinasi modul sesuai kebutuhan. Semua contoh selain UMV bersifat skenario desain, bukan klaim modul itu sudah selesai.

1.7 Di luar cakupan otomatis

Paket ini tidak menyetujui migrasi tenant, pemecahan database, perubahan akuntansi, penerbitan layanan publik, ataupun perubahan harga. Semua memerlukan desain, pengujian, dan persetujuan lanjutan.

1.8 Kriteria diterima

Pembaca dapat menjelaskan perbedaan SAKILA–organisasi–program–modul, dan tidak menyebut Braille sebagai default platform. Agent tidak menurunkan fitur V6 menjadi pekerjaan langsung tanpa change request.

02 KAMUS DAN MODEL DOMAIN

02 — Kamus domain dan relasi data

2.1 Istilah normatif

2.2 Relasi konseptual sasaran

Satu tenant mempunyai banyak unit/cabang, pengguna dan program; program dapat memiliki campaign, transaksi yang relevan dan kegiatan penyaluran; satu modul dapat dipakai banyak program dan satu program dapat memakai banyak modul. Plugin adalah perilaku khusus jenis program, bukan identitas organisasi. Relasi ini rancangan produk; kardinalitas implementasi perlu diturunkan ke desain database.

2.3 Alur informasi konseptual

Organisasi → Program → Campaign (opsional) → Transaksi → Verifikasi → Penggunaan/alokasi → Penyaluran/kegiatan → Bukti → Laporan. Seluruh tahapan tunduk pada otorisasi, audit dan retensi yang berlaku; tidak setiap program memiliki transaksi donasi atau proses penyaluran fisik.

2.4 Temuan LAB terverifikasi dari source (11 Oktober 2026)

app/Models/Program.php memiliki plugin_key, relasi transactions() dan programUpdates(); app/Models/Campaign.php memiliki relasi ke Program dan Transaction; app/Models/Distribution.php memiliki relasi ke Program; app/Models/Transaction.php memiliki relasi ke Program dan Campaign. Penelusuran migrasi belum menemukan referensi tenant_id atau organization_id. Ini bukan audit keseluruhan database runtime.

2.5 Risiko default legacy

Pada Model Program, ProgramController, DonationService, DonationController dan migrasi 2026_06_13_151500_create_program_plugins_table.php, terdapat default braille_waqf. Jangan menghapusnya secara otomatis: perlu inventaris pemanggil, analisis transaksi lama, strategi kompatibilitas, tes regresi dan persetujuan. Target desain: program baru non-UMV tidak otomatis menjadi Braille; pilihan yang aman untuk data legacy perlu diputuskan secara eksplisit.

2.6 Acceptance desain

Dokumen desain dan tes harus membuktikan pembuatan program umum tanpa konversi Braille yang tidak diminta, serta bahwa program Braille historis tetap dapat dibaca dan dilaporkan dengan benar.

03 KATALOG MODUL

03 — Katalog modul, plugin dan kepemilikan

Penting: Katalog berikut memisahkan kode ditemukan, status fitur, dan status SaaS; tidak menyebutnya semuanya siap produksi.

Perbedaan tiga pengendalian

1. Katalog modul: fitur apa tersedia secara teknis.
2. Entitlement/paket organisasi: fitur mana yang berhak dipakai tenant.
3. Permission individu: siapa boleh menjalankan aksi dalam tenant. Ketiganya harus diperiksa bersamaan di backend. Menyembunyikan menu saja bukan keamanan.

Kebijakan plugin program

Plugin harus punya kontrak perilaku (input, output, kesalahan, kompatibilitas) dan pengaturan scoped tenant pada arsitektur sasaran. Fallback global braille_waqf adalah utang transisi; perubahan tidak boleh menafsir ulang transaksi historis.

Definition of Done modul

Daftar dependency, izin, skema data, API, status aktivasi, migrasi, tes otomatis, tes aksesibilitas, rollback dan pemilik bisnis terdokumentasi; bukti tiap tenant terisolasi diperlukan sebelum modul masuk SaaS multi-tenant.

04 ARSITEKTUR SAAS DAN TENANCY

04 — Arsitektur SaaS, organisasi dan isolasi

Keputusan resmi

Database terpisah per organisasi/tenant adalah target yang telah dipilih pemilik. Cabang/unit bukan tenant tersendiri kecuali ada keputusan bisnis dan kontrak khusus. Sasaran: organisasi mendaftar, disiapkan lingkungan datanya, memilih paket, mengaktifkan modul, memakai mereknya sendiri, dan mengelola integrasi BYOK.

Batas antara saat ini dan target

LAB saat ini mempunyai model Program/Campaign/Transaction dan konfigurasi modul melalui Settings yang tidak terbukti scoped tenant. Belum ditemukan migrasi bertuliskan tenant_id atau organization_id dalam pemeriksaan source. Jangan menyimpulkan tenancy sudah siap maupun mustahil dibangun dari temuan terbatas ini.

Kebutuhan produk (harus dibuktikan sebelum rilis SaaS)

• Tenant provisioning aman, idempotent dan diaudit; kegagalan provisioning dapat dipulihkan tanpa database yatim.
• Request backend harus menyelesaikan identitas tenant secara autentik; tenant A tidak bisa membaca/mengubah tenant B.
• Database, backup, restore, jadwal job, event, queue, cache, media dan log mempertahankan batas tenant.
• Plugin/setting, API credentials dan white-label dipisah per tenant; secret disimpan terenkripsi dan tidak tercetak di log.
• Entitlement free/premium dilakukan di backend dengan izin pengguna; peningkatan/penurunan paket tidak merusak histori.
• Dukungan dan super admin tidak boleh menyamar sebagai pengguna bisnis tanpa batas, audit, dan otorisasi khusus.
• Onboarding, offboarding, ekspor dan retensi mengikuti kebijakan privasi yang disetujui.

Desain yang belum final

Pilihan database control-plane, pemetaan tenant ke koneksi, subdomain/domain, shared identity vs separate identity, billing provider, kuota, lingkungan preview dan migrasi UMV perlu Architecture Decision Record (ADR). Agent tidak boleh mengarang keputusan ini.

Tes penerimaan wajib

Dua tenant dengan nama program identik mempunyai data terisolasi; tenant A tidak dapat melihat transaction, file, cache, notifikasi, laporan atau credential B, termasuk via URL langsung/API/background job. Setiap klaim PASS membutuhkan bukti test dan tanggal.

05 KEUANGAN DAN TATA KELOLA

05 — Keuangan, pengendalian dan integritas data

Bab berisiko tinggi. Dokumen ini adalah panduan baca; detail state machine, ledger, permission dan audit tidak boleh dipersingkat menjadi implementasi baru. Referensi kontrak: PRD V5.2 §02–§06, §08, §12, §16, §19 dan SAKILA_MASTER_HANDOFF.md §6–§7.

Prinsip wajib yang harus tetap dipertahankan

1. Fakta finansial awal, nilai saat ini dan riwayat koreksi harus dibedakan. Tidak ada perubahan yang diam-diam menghapus bukti asli.
2. Verifikasi, koreksi sebelum verifikasi, adjustment setelah verifikasi dan penolakan mengikuti alur persetujuan, keadaan transaksi, kewenangan, atomicity dan audit PRD V5.2.
3. Permission dan separation of duties ditegakkan server-side; super admin bukan izin universal melakukan aksi bisnis.
4. Transaksi finansial yang punya side effect harus aman terhadap retry, concurrency dan duplikasi.
5. Rekonsiliasi, alokasi ke program/campaign, laporan dan penyaluran memakai nilai yang benar menurut definisi sumber; tidak boleh menyamakan total seluruh lembaga dengan perolehan program.
6. Data penerima manfaat dilindungi sesuai tingkat sensitifnya; jangan menampilkan detail identitas tanpa kewenangan.

Celah definisi yang wajib diselesaikan sebelum migrasi

• Apakah transaksi lama yang tidak bertaut program/campaign dianggap data historis atau perlu reclassify?
• Bagaimana mempertahankan original_amount, current_amount, state, ledger dan approval jika tenant dipisahkan?
• Bagaimana rekonsiliasi dan pelaporan campaign berbeda dengan agregat program/organisasi?
• Bagaimana refund diperlakukan tanpa mengubah histori?

Acceptance dan bukti

Minimal mencakup correction sebelum verifikasi, penolakan dengan alasan, adjustment atomik pascaverifikasi, persetujuan tidak oleh aktor sama bila dilarang, pencegahan duplikasi, concurrency, dan laporan konsisten. Skenario Gherkin yang mengikat tetap berada di PRD V5.2 §08 sampai diturunkan tanpa kehilangan satu pun kondisi.

Larangan agent

Tidak mengubah schema/migration finansial atau membuka bypass hanya untuk membuat tes hijau. Jika pernyataan di ringkasan ini bertentangan dengan kontrak detail V5.2 atau keputusan pemilik, STOP dan catat konflik.

06 API INTEGRASI DAN KEAMANAN

06 — API, integrasi, privasi dan keamanan

Kontrak API

Web dan Flutter memakai backend API yang konsisten. Standar envelope, kompatibilitas klien lama dan endpoint detail mengikuti PRD V5.2 §07 serta dokumen API_ENVELOPE_STANDARD.md. API yang hidup di kode belum otomatis terbukti sesuai kontrak: verifikasi route, middleware, test, dan konsumen klien.

Identitas dan izin

Autentikasi, otorisasi role, izin per objek, tenant context dan entitlement adalah mekanisme berbeda. Semua operasi sensitif harus diverifikasi backend, bukan hanya tombol di UI.

Integrasi

Integrasi WhatsApp, AI Safira, pembayaran, SMS/email dan VoIP bersifat dapat dikonfigurasi sesuai modul. Kebijakan produk adalah BYOK per lembaga bila relevan. Credential, webhook, retry dan batas biaya harus diisolasi serta dimonitor. WhatsApp idempotency dan guard AI mengacu ke PRD V5.2 §10–§11; detail VoIP sesuai bukti handoff bertanggal, bukan janji umum kesiapan produksi.

Privasi dan retensi

Data pribadi dan data penerima manfaat harus diminimalkan, dibatasi berdasarkan kebutuhan/role, disimpan dengan keamanan memadai, dapat diaudit, dan dihapus/diarsip mengikuti jadwal retensi yang disetujui. Detail V5.2 §05 tetap mengikat sebagai baseline sampai direvisi secara eksplisit.

Dokumentasi publik vs internal

Portal HTML publik boleh menjelaskan model produk dan kontrak tanpa host SSH, username, file key, jalur deploy, secret, detail bypass maupun temuan keamanan sensitif. Halaman internal AI Agent harus dibatasi akses; jangan sekadar menyembunyikan link.

Acceptance

Cross-tenant authorization, perlindungan credential, webhook signature, retry/idempotency, deny-by-default, masking informasi pribadi, redaksi log, dan peran agent diuji dengan bukti negatif maupun positif.

07 AKSESIBILITAS DAN PENGALAMAN

07 — Pengalaman pengguna dan aksesibilitas universal

Prinsip

Aksesibilitas adalah syarat penerimaan tiap alur penting, bukan fase tambahan setelah produk jadi. Dokumen sumber V5.2 §09 berisi kewajiban baseline; audit menyeluruh pada roadmap V6 tidak boleh ditafsirkan sebagai izin merilis alur tidak aksesibel.

Web

Struktur heading logis, label input permanen, pesan error tersambung ke field, fokus yang terlihat, navigasi keyboard, status dinamis diumumkan, tabel mempunyai header, dialog menahan serta mengembalikan fokus, dan tidak menggantungkan informasi hanya pada warna atau ikon. Kegunaan diuji di NVDA dan JAWS untuk alur prioritas.

Mobile Flutter

Semantik label, role tombol, fokus TalkBack/VoiceOver, target sentuh, pengumuman status, dialog, login, verifikasi, daftar transaksi dan panggilan harus diuji dengan perangkat nyata sesuai fitur yang dirilis.

Alur minimum yang perlu diuji

Login; memilih organisasi bila relevan; navigasi menu; membuat program; membaca laporan; memverifikasi transaksi; melakukan approval sesuai role; memperbarui data; mengonfirmasi aksi; meninjau bukti penyaluran; mengatur modul (hanya bila sudah aktif).

Bukti penerimaan

Untuk setiap alur catat perangkat/OS, screen reader, versi aplikasi, langkah yang diuji, hasil, hambatan, dan koreksi. Skor checklist dokumentasi saja tidak setara dengan lulus uji pengguna.

08 PENGUJIAN DAN RILIS

08 — Pengujian, definisi selesai dan keamanan rilis

Lima status yang tidak boleh dicampur

Direncanakan → Ada kode → Lulus tes terisolasi → Lulus integrasi/UAT LAB → Diverifikasi production. Tidak ada langkah yang otomatis melompati lainnya. Klaim PASS selalu menyebut lingkup, tanggal, lingkungan dan bukti.

Sebelum development

Tentukan scope, sumber keputusan, sistem terdampak, risiko dana/data, kebijakan aksesibilitas, dependencies, rollback plan dan tes regresi. Catat branch dan dirty worktree; jangan mengganti berkas yang sedang dikembangkan agent lain.

Saat implementation LAB

Gunakan workspace/branch terpisah untuk pekerjaan besar, tinjau skema, tulis tes, eksekusi hanya pada LAB yang memang disetujui. Jangan memasukkan data rahasia ke artefak, log, maupun repo.

Safety Gate ke production

PRD V5.2 §16 adalah protokol detail wajib; bagian ini tidak memberi izin deploy. Terapkan backup/recovery, approval manusia, perbandingan diff, compatibility check, security review, uji regresi, monitoring dan rollback, sesuai prosedur resmi.

Definisi selesai

Kode saja belum selesai. Harus ada acceptance test, pemeriksaan permission, isolation tenant bila berlaku, tidak ada kebocoran data, tes aksesibilitas, bukti hasil, dokumentasi dan persetujuan pemilik sesuai tingkat risiko. Referensi mengikat DoD V5.2 §19.

Larangan khusus

Jangan deploy diam-diam, restart service production, lakukan migrasi destructive, commit/push perubahan lain yang tidak terkait, atau menyatakan siap produksi berdasarkan satu skenario VoIP/finansial yang lolos.

09 ROADMAP DAN STATUS

09 — Roadmap, status dan keputusan berikutnya

9.1 Baseline nyata yang terbukti di penelusuran kode LAB

Model Program, Campaign, Transaction dan Distribution mempunyai relasi yang relevan; ada plugin program Braille/Zakat/Wakaf Umum/Donation serta plugin komunikasi/pembayaran dan kode modul Koperasi; ProgramPluginController memuat toggle business modules. Ini bukti keberadaan source, bukan sertifikat kerja normal, keamanan atau kesiapan SaaS.

9.2 Pekerjaan prioritas

P0 — Jangan rusak: jaga integritas transaksi lama, histori koreksi, role, data donor, dan worktree VoIP aktif; hentikan penyebaran informasi operasional sensitif di portal publik.

P1 — Konsolidasi: tetapkan PRD induk resmi setelah review, selesaikan konflik penomoran/status, audit semua fallback Braille, definisikan kontrak plugin vs modul dan tes program generik.

P2 — Fondasi SaaS: ADR control-plane, database-per-tenant, provisioning, module entitlement, scoped config/cache/jobs/storage, permission lintas tenant, BYOK.

P3 — Pilot terukur: uji UMV regression dan organisasi kedua dengan data terpisah; tes finansial dan aksesibilitas; tetapkan paket, billing serta SLA berdasarkan keputusan bisnis.

P4 — Ekspansi: white-label penuh, perluasan modul, otomatisasi onboarding dan observability sesuai bukti pilot.

9.3 Pertanyaan terbuka yang tidak boleh dijawab agent sendiri

Harga/kuota; modul core wajib; apakah setiap program perlu plugin atau plugin opsional; default yang aman bagi program baru; legacy UMV migration mapping; definisi cabang versus tenant; administrasi support lintas tenant; billing/penonaktifan paket; proses penghapusan data; nama dan versi kontrak API final.

9.4 Kriteria keberhasilan produk

Organisasi kedua bisa onboarding dan mengelola program tanpa fallback Braille, mempunyai database dan credential terpisah, memakai entitlement dan permission tepat, serta lulus alur keuangan, laporan dan aksesibilitas yang telah didefinisikan.

10 KONTRAK KERJA AGENT

10 — Kontrak kerja untuk AI Agent dan pengembang

Urutan baca wajib

1. Panduan dan PRD induk revisi ini.
2. KEPUTUSAN_ARAH_SAKILA_2026_09_16.md untuk 8 keputusan resmi pemilik.
3. Pasal detail PRD V5.2 sesuai tugas; V6 untuk arah masa depan.
4. AGENTS.md, SAKILA_MASTER_HANDOFF.md, evidence terbaru (tanggal, lingkungan, commit), dan source aktual.
5. 11_TRACEABILITY_DAN_KONFLIK.md agar tidak ada bab lama tertinggal.

Klasifikasi setiap klaim

Tuliskan DECIDED, PROPOSED, SOURCE_OBSERVED, TESTED_LAB, VERIFIED_PRODUCTION, UNKNOWN dengan bukti. SOURCE_OBSERVED bukan TESTED_LAB.

Jika spesifikasi bertentangan

Jangan memilih dokumen berdasarkan nomor versi saja. Keputusan resmi identitas produk mengarahkan interpretasi; kewajiban detail finansial/privasi tetap berlaku sampai ada revisi eksplisit. Catat kedua sumber, dampak, opsi dan alasan berhenti; minta keputusan untuk konflik bisnis/finansial/hak akses/keamanan.

Pemisahan lingkungan

LAB boleh hanya sesuai scope otorisasi. Production tidak boleh disentuh tanpa persetujuan spesifik per operasi. Jangan print .env, secret, private key, identitas pribadi, atau isi transaksi nyata ke laporan.

Hasil minimum sebuah pekerjaan

Tujuan dan batas; daftar sumber bertanggal; daftar file diperiksa/diubah; diff; risiko kompatibilitas; tes dengan evidence; rollback; konflik; approval status. Jangan mengubah status di dokumentasi menjadi PASS tanpa bukti.

Kriteria gagal otomatis

Menjadikan UMV sebagai default seluruh tenant, menganggap program = modul, melewatkan security check tenant, merusak transaksi legacy, melewati approval bisnis, atau mengklaim siap rilis berdasarkan sekadar keberadaan kode.

11 TRACEABILITY DAN KONFLIK

11 — Matriks keterlacakan semua bab lama dan konflik dokumentasi

Fungsi: memastikan konsolidasi tidak menghilangkan substansi penting. Ini peta, bukan klaim bahwa seluruh isi setiap pasal lama sudah diverifikasi ulang baris demi baris.

Pemetaan PRD V5.2

Pemetaan PRD V6

Konflik / ketidakjelasan yang telah diamati

C-01 Prioritas tinggi: V5.2 dan V6 sama-sama memakai bahasa 'canonical'; keputusan pemilik menyatakan V5.2 baseline terperinci sekarang dan V6 arah masa depan. Jangan samakan kewenangan keduanya.

C-02 Tinggi: Label bagian roadmap status memakai angka lama (misalnya DoD disebut 18 di STATUS_BAB_PRD.md, padahal V5.2 aktual §19). Perbarui rujukan ketika sinkronisasi disetujui.

C-03 Tinggi: V6 menjelaskan ERP umum tetapi contoh dan identitas lembaga UMV dominan; bedakan visi platform dan studi kasus operasional.

C-04 Tinggi: Source LAB masih fallback braille_waqf pada pembuatan program, model, notifikasi dan dokumen transaksi. Rencanakan compatibility migration, jangan replace mendadak.

C-05 Tinggi: SaaS database-per-tenant, entitlement per tenant, dan billing merupakan keputusan target; bukti implementasi belum ditemukan dalam audit source terbatas.

C-06 Sedang: Setting::isModuleEnabled menunjukkan toggle aplikasi, belum menjadi bukti entitlement per tenant.

C-07 Tinggi: AGENTS.md memiliki instruksi dan detail server production; tidak tepat disajikan sebagai prosedur LAB universal atau portal publik terbuka.

C-08 Sedang: Laporan status bab dan handoff bersifat snapshot; hasil tes harus disertai versi kode, tanggal dan scope.

C-09 Tinggi: Alur penjualan SaaS perlu definisi harga, tenant registration, billing, suspended state dan kebijakan perpanjangan yang belum diputuskan.

Kebijakan penutupan konflik

Tutup hanya dengan: keputusan pemilik/ADR, patch dokumentasi terkontrol, uji relevan, sumber bukti, tanggal, dan reviewer. Jangan menghapus temuan hanya karena kalimat PRD sudah diubah.

12 PROTOKOL ADOPSI DAN VALIDASI

12 — Cara menerapkan revisi tanpa merusak LAB

Kondisi saat penulisan: dokumen asli LAB belum ditimpa. Git LAB mempunyai perubahan aktif termasuk area VoIP; perlakukan worktree sebagai area yang dilindungi.

Urutan adopsi yang aman

1. Pemilik membaca HTML, mengoreksi identitas produk/keputusan bisnis, dan menyetujui atau menolak revisi.
2. Pengembang membandingkan seluruh subbab PRD V5.2/V6 dengan matriks keterlacakan, merekam requirement yang tidak tercakup.
3. Buat branch/worktree dokumentasi terpisah dari pengembangan aktif, simpan salinan/commit SHA file sumber.
4. Tambahkan indeks dan dokumen baru tanpa menimpa sumber lama pada tahap pertama; tautkan arsip sebagai referensi.
5. Jalankan review domain finansial, keamanan, API, mobile/VoIP, dan aksesibilitas oleh pemilik teknis.
6. Perbarui status dengan bukti tes aktual, bukan klaim generik PASS.
7. Setelah review resmi, tetapkan satu entry point agent; tandai dokumen lama historical/reference tanpa menghapusnya.
8. Deployment dokumentasi HTML mengikuti filter informasi publik vs internal.

Checklist sign-off

• Identitas dan istilah disetujui pemilik.
• Tidak ada kewajiban finansial/permission/privacy yang hilang.
• Mapping setiap bab V5.2 dan V6 telah diperiksa reviewer.
• Kondisi LAB / production dibedakan.
• Tidak ada secret atau host operasional dalam versi HTML publik.
• Dokumen dapat diakses dengan NVDA/JAWS.
• Agent entry point ditetapkan, dan keputusan di luar cakupan tidak diambil agent sendiri.

Aturan akhir: DRAF ini dapat dipakai untuk review dan perencanaan. Ia baru menjadi spesifikasi implementasi baru setelah disetujui dan diberi versi kanonis resmi.

13 TAHAP29 KONSOLIDASI TEMUAN

Tahap 29 — Konsolidasi hasil audit dan backlog keputusan

Status: selesai untuk konsolidasi bukti yang tersedia; audit terhadap setiap baris PRD warisan masih butuh sign-off review khusus. Urutan temuan berdasarkan dampak data/dana, bukan kronologi nomor audit.

A. P0 — Integritas keuangan dan pemisahan tugas

B. P0/P1 — Domain produk dan SaaS

C. Bukti sandbox yang tidak boleh dilebih-lebihkan

• Tahap 17: HTTP /up mengembalikan 200 pada Laravel terisolasi.
• Tahap 18: 3 tes model/7 assertion PASS dalam fixture minimal.
• Tahap 19: akses anonim web 302, mobile 401; bukti autentikasi, bukan matriks izin lengkap.
• Tahap 22: Gate manage_wakaf memberi akses pada employee, finance_staff, finance_manager.
• Tahap 24: tes negatif mengungkap mutasi tanpa kewenangan.
• Tahap 25: prototipe pengaman di sandbox: 5 tes/12 assertion PASS (memblokir edit transaksi final web umum).
• Tahap 27: self-approval sebelum patch sukses; sesudah patch ditolak, approver lain sukses.
• Tahap 28: 5 tes/16 assertion PASS pada controller secara langsung; middleware API dan audit trail durable belum dibuktikan.
• Semua patch hanya di salinan /tmp/sakila_phpunit_sandbox_20261011, bukan source LAB aktif/production.

D. Kebijakan prioritas engineering

P0: FIN-01/02/05/07 (otorisasi dan SoD); cegah editing data final, selaraskan workflow, audit dan rollback sebelum rilis. P1: FIN-03/04/06/08, DOM-01/05 serta kontrak data dan laporan. P2: DOM-02/03/04, mekanisme SaaS tenant/entitlement dan white-label sesuai roadmap; keamanan lintas tenant tetap release blocker jika fitur tenant akan dirilis.

Tidak ada perbaikan di atas yang dianggap terselesaikan pada source aktif. Tes sandbox yang PASS adalah bukti prototipe, bukan izin deploy.

14 TAHAP30 KONTRAK ACCEPTANCE

Tahap 30 — Kontrak PRD dan matriks acceptance

Status: rumusan kandidat PRD. Setiap kata WAJIB adalah kriteria penerimaan usulan yang harus direview pemilik domain/teknis sebelum ditetapkan kanonis. Ini memperjelas baseline V5.2, bukan mencabut aturan rincinya.

1. Organisasi, program, campaign dan modul

• SAAS-01: Organisasi diprovisioning ke database khusus tenant secara idempotent, dengan backup, restore, tenant resolution dan isolasi cache/job/media/log; tidak boleh ada query silang tenant tanpa otorisasi dukungan terpisah.
• SAAS-02: Unit/cabang berada di bawah organisasi kecuali ada keputusan onboarding tenant baru.
• SAAS-03: Modul perangkat lunak, plugin jenis program, subscription entitlement dan role/permission disimpan serta dievaluasi sebagai konsep berbeda. Aksi memerlukan keempat kondisi yang relevan (termasuk tenant context), bukan sekadar menu tersembunyi.
• PROG-01: Program baru non-UMV dapat dibuat tanpa braille_waqf; program UMV historis tetap terbaca dengan pemetaan kompatibilitas yang tervalidasi.
• PROG-02: Campaign melekat pada program bila relevan. Pencapaian campaign ≠ seluruh perolehan program ≠ perolehan organisasi.
• BIZ-01: Freemium, layanan premium, BYOK dan white-label mengikuti keputusan pemilik; SAKILA tidak mengambil persentase donasi. Harga/kuota/SLA masih memerlukan keputusan produk.

2. Keuangan — kontrak perilaku server

• FIN-01: amount raw/original transaksi terverifikasi tidak dapat berubah. Koreksi menulis riwayat adjustment yang immutable dan current_amount sesuai definisi; operasi satu transaksi atomik.
• FIN-02: Endpoint web edit umum tidak boleh mengubah program, akun, status, nominal, atau metadata kritis dari transaksi paid|verified|adjusted. Koreksi berhak harus lewat prosedur khusus, bukan PUT /wakaf/{id} biasa.
• FIN-03: State adjustment: draft → approved → applied, serta penolakan yang sah; state ilegal dan replay harus ditolak tanpa perubahan data. HTTP boleh disesuaikan kontrak API, tetapi kegagalan harus dapat diamati.
• FIN-04: Pembuat draft tidak boleh menyetujui draftnya sendiri; nilai pembuat dan approver diverifikasi terhadap user autentik, bukan request payload. Penyelarasannya juga berlaku pada klaim idempotent.
• FIN-05: Persetujuan harus diwajibkan aktor berbeda dan memiliki izin yang tepat; apply tidak dapat dilakukan sebelum approval; audit approval menyebut siapa, kapan, alasan, before/after.
• FIN-06: Bypass darurat super admin harus mempunyai permintaan, persetujuan pihak kedua yang independen, TTL maksimal 60 menit sesuai baseline, one-time consume dan jejak audit; approval/apply harus konsisten. Tidak boleh menganggap super_admin dapat melewati segala SoD.
• FIN-07: Lock transaksional dan idempotency key mencegah duplicate/retry serta race condition. Laporan konsisten terhadap suatu definisi finansial, tanpa salah memaknai nilai accessor saat SQL SUM.
• FIN-08: Definisi nominal 0, refund, status terhitung, ledger dan cash closing harus diputuskan eksplisit dan diuji dengan skenario numerik batas.
• FIN-09: Perolehan publik harus bisa dilacak: per transaksi → campaign → program → organisasi; aggregate tidak mengambil nilai keseluruhan ketika filter program diminta.

3. Keamanan, operasional dan aksesibilitas

• SEC-01: Auth, role, permission objek, entitlement dan tenant context berlaku di backend semua kanal; negative test membuktikan tidak ada side effect database.
• SEC-02: Webhook integrasi memverifikasi signature dan idempotency, credential BYOK scoped tenant serta tidak muncul di log/artifact.
• SEC-03: PII donor/penerima manfaat dibatasi, diaudit dan memiliki kebijakan retensi; kasus izin ditolak tidak membeberkan isi data.
• ACC-01: Semua alur kritis dapat diselesaikan memakai keyboard dengan NVDA/JAWS dan TalkBack/VoiceOver sesuai kanal; status, label, dialog, fokus dan galat semantik wajib diverifikasi.
• OPS-01: Deployment menuntut uji regresi, backup-restore, rollback, review diff, approval manusia, observability dan tidak ada akses production berdasarkan keberhasilan tes sandbox.

4. Matriks minimum uji finansial

5. Gerbang rilis

Semua QA P0 harus PASS dalam suite integrasi yang menjalankan middleware API dan aplikasi sesuai deployment target. Audit AuditTrail yang gagal diam-diam tidak boleh dianggap memenuhi persyaratan jejak finansial bila audit tersebut wajib. Data sintetis wajib dipakai di sandbox; uji pada LAB nyata hanya setelah isolation gate jelas, dengan otorisasi dan backup; production terpisah membutuhkan approval operasi spesifik.

15 TAHAP31 HANDOFF SIGNOFF

Tahap 31 — Validasi editorial, serah terima dan sign-off

Status akhir yang akurat

Tahap 29–31 penyusunan paket selesai; paket PRD Candidate 2.0 siap review pemilik/engineering, belum otomatis menjadi dokumen kanonis, belum diadopsi di LAB, dan belum dibuktikan seluruhnya terhadap source serta seluruh requirement V5.2/V6. Tidak ada perbaikan source aktif dalam paket ini.

Checklist validasi editorial (dilakukan untuk paket ini)

• Membedakan platform, organisasi, unit, program, campaign, modul, plugin, entitlement, permission.
• Mengklasifikasikan V5.2 baseline, V6 roadmap, keputusan pemilik 16 Sep sebagai arah bisnis.
• Memisahkan SOURCE_OBSERVED dari SANDBOX_TESTED serta risiko dari bukti eksploitasi.
• Menautkan backlog temuan keamanan P0 dengan acceptance test positif/negatif dan before/after database.
• Menjaga source LAB/production tetap tidak disentuh selama pembuatan dokumen.
• Menyediakan HTML semantik dan berkas Markdown untuk pembaca layar.
• Menyamakan setiap subpasal V5.2/V6/keputusan asli satu-per-satu dengan reviewer manusia.
• Sign-off domain keuangan, privasi, keamanan, aksesibilitas dan arsitektur tenant.
• Pemilik menyetujui PRD Candidate 2.0 sebagai kanonis beserta status keputusan terbuka.

Keputusan yang masih terbuka

1. Peran mana selain finance_manager yang boleh mengajukan, menyetujui dan menerapkan tiap jenis koreksi? Tentukan matriks per aksi dan kanal; hindari kebijakan berbeda antara route dan controller.
2. Apakah paid wajib melalui prosedur final sama seperti verified? Rekomendasi sementara: ya, kecuali kebijakan tertulis berbeda.
3. Apakah nol boleh sebagai active amount pascapenyesuaian? Kebijakan sementara mobile: tidak. Tetapkan alur pembatalan/refund terpisah.
4. Apa definisi nominal yang dipakai tiap metrik, termasuk refund, fee, cash closing dan kampanye?
5. Apakah kegagalan audit ledger wajib membatalkan transaksi? Rekomendasi: audit finansial kritis harus durable/transactional.
6. Bagaimana finance_manager dan super_admin membagi tahap apply/bypass dengan akuntabilitas pihak kedua?
7. Modul core wajib, harga/kuota freemium, SLA, retensi data, protokol cabang dan support lintas tenant.
8. Pemetaan braille_waqf bagi program lama saat migrasi tenant; tidak boleh otomatis diterapkan pada organisasi lain.

Instruksi eksekusi untuk AI Agent setelah sign-off

1. Baca 00_README_MULAI_DI_SINI.md, keputusan owner, V5.2 pasal terkait, V6 roadmap, AGENTS.md, kemudian backlog+acceptance.
2. Konfirmasi scope: tugas PRD/editorial atau perubahan kode? Berkas produksi tidak tersentuh bila tidak ada instruksi deploy eksplisit.
3. Tentukan baseline commit/dirty state dan dokumentasikan snapshot file; jangan menimpa perubahan agen VoIP atau pekerjaan lain.
4. Buat branch/worktree terpisah, mulai dari tes regresi merah yang diturunkan dari QA-01/03; baru lakukan refactor policy/service secara sempit.
5. Jangan sekadar menambal abort(403) sebagai solusi final: rancang jalur koreksi berwenang, policy berbasis kemampuan, dan pemisahan pemohon–penyetuju–pelaksana sesuai keputusan.
6. Jalankan suite middleware web/API, SoD dan concurrency; verifikasi nilai raw DB, saldo, audit, laporan serta klien mobile. Laporkan FAIL, bukan memperlunak assertion.
7. UAT dengan pengguna dan screen reader, dokumentasikan regression dan bukti rollback.
8. Handover ke reviewer dengan diff, bukti tes, status fitur, risiko residual, keputusan serta persetujuan; production tetap membutuhkan safety gate terpisah.

Status tiga tahap

Artefak sumber acuan

• /var/www/dev/docs/KEPUTUSAN_ARAH_SAKILA_2026_09_16.md: keputusan pemilik.
• /var/www/dev/docs/PRD_SAKILA.md: baseline detail V5.2.
• /var/www/dev/docs/PRD_SAKILA_ENTERPRISE_ECOSYSTEM.md: V6 arah enterprise.
• /var/www/dev/AGENTS.md, /var/www/dev/docs/SAKILA_MASTER_HANDOFF.md: konteks implementasi, bukan pengganti PRD.
• Audit tahap 24, 25, 27, 28: bukti sandbox terpenting; gunakan log/run fixture saat melakukan verifikasi ulang.

16 PENETAPAN BASELINE AUDIT

16 — Penetapan baseline audit dan aturan prioritas

Identitas: SAKILA ERP SaaS lintas organisasi. UMV adalah contoh organisasi; wakaf Al-Qur'an Braille merupakan program UMV, bukan inti produk dan bukan pilihan bawaan setiap tenant.

Status tegas dokumen

AUDIT-READY: YA. Paket v2.1 ini merupakan baseline pemeriksaan yang dapat langsung dipakai untuk gap assessment, review desain, penulisan tes, estimasi, dan engineering di sandbox/branch terisolasi. Untuk setiap perbedaan implementasi dengan requirement, keluarkan temuan serta bukti, bukan mengubah requirement diam-diam.

BUILD-READY: YA, TERBATAS untuk komponen dengan requirement dan acceptance telah lengkap, dengan perubahan terisolasi, tes regresi, dan review diff. PRODUCTION-DEPLOY-READY: TIDAK. Persetujuan pemilik untuk dokumen bukan otomatis izin operasi produksi.

Urutan kewenangan bila ada konflik

1. Keputusan tertulis pemilik 16 September 2026 untuk arah bisnis dan identitas platform.
2. Baseline V5.2 untuk aturan operasional/finansial/privacy/security terperinci yang tidak ditimpa keputusan baru secara eksplisit.
3. Paket v2.1 untuk terminologi SaaS, penggolongan temuan, kontrak uji penerimaan dan status kesiapan audit.
4. V6 enterprise untuk roadmap kemampuan masa depan, bukan sebagai bukti bahwa fitur sudah dideploy.
5. Source code dan AGENTS.md sebagai bukti implementasi saat ini, bukan otomatis kebijakan bisnis kanonis.

Aturan konflik: Bila paket v2.1 berbeda dari V5.2 pada fakta finansial atau kewajiban hukum, gunakan aturan yang lebih aman sambil mencatat ADR/permintaan keputusan. Tidak ada penghapusan kewajiban PRD lama dengan alasan “ringkasan baru”.

Pelaksanaan audit langsung

• Inventaris requirement memakai MATRIKS_REQUIREMENT.csv dan 14_TAHAP30_KONTRAK_ACCEPTANCE.md.
• Per requirement tandai implemented / partial / missing / conflicting / unverified serta bukti kode, tes, commit, tanggal dan risiko.
• Untuk kontrol P0 gunakan tes negatif dan perbandingan isi database sebelum/sesudah. Tidak boleh mengklaim PASS dari pencarian string source.
• Pertahankan model domain tenant → organisasi → program → campaign sesuai aturan bahwa cabang/unit tidak otomatis menjadi tenant. Modul dan plugin tidak identik dengan program.
• Selesaikan kesenjangan sebelum penerimaan rilis melalui gerbang di dokumen 18.

17 KEPUTUSAN IMPLEMENTASI DAN ADR

17 — Keputusan operasional yang dapat dipakai Agent

Ditetapkan sebagai kebijakan aman untuk desain dan pengujian (tidak mengubah production)

Klasifikasi: D-01 sampai D-12 adalah baseline engineering konservatif untuk audit dan penyusunan solusi. Keputusan hukum, akuntansi, tarif, dan produksi hanya sah bila disetujui pemilik yang berwenang; Agent tidak boleh mengklaim persetujuan pengguna yang tidak pernah diberikan.

Hal yang belum dapat dikunci tanpa otoritas bisnis dan data sebenarnya

Batasnya tegas: ADR terbuka tidak menghalangi audit, tetapi menghalangi aktivasi fitur terkait pada rilis nyata. Agent membuat usulan ADR dengan opsi, risiko, tes, dan dampak migrasi; bukan menebak jawaban pemilik.

18 GERBANG GO NO GO DEPLOY

18 — Gerbang GO / NO-GO audit, development, LAB dan production

Keputusan tahap sekarang

Gerbang mandatory untuk naik kelas

1. Requirement sign-off: cakupan bisnis, aktor, batas tenant, metrik akuntansi, audit dan privacy diputuskan pada ADR relevan.
2. Rekonsiliasi: setiap aturan material V5.2/V6 dipetakan ke requirement final; konflik direkam, diselesaikan, dan reviewer menerima hasilnya.
3. Security P0: uji employee mengganti transaksi final gagal tanpa mutasi; maker-checker gagal untuk self-approval dan berhasil untuk dua aktor sah; bypass darurat valid lengkap; web/mobile selaras.
4. Data: rekonsiliasi nominal original/current, ledger, akun, program dan campaign; tes concurrency/idempotency dan event jobs.
5. Tenant: dua organisasi sintetis dengan koneksi terpisah; tidak ada kebocoran query, cache, file, queue, log, backup atau BYOK.
6. Quality: seluruh tes P0/P1 dan UI keyboard/screen reader PASS; tidak ada regresi terhadap modul yang dipakai.
7. Operations: snapshot backup diuji restore, rencana cutover/rollback, monitoring, reviewer, pemilik perubahan dan otorisasi target lingkungan.

GO production baru boleh dinyatakan berdasarkan bukti di lingkungan target dan persetujuan deploy tersendiri. Lulus PHPUnit di SQLite saja bukan GO production.

Daftar pekerjaan yang masih diperlukan sebelum ada GO production

• P0: perbaiki endpoint web transaksi final dan SoD; sinkronkan permission route/controller; uji bypass.
• P0: rekonsiliasi sum(amount) vs sum(current_amount) dan audit ledger.
• P0: selesaikan tenant boundary server-side dan isolasi resource sebelum onboarding tenant kedua nyata.
• P1: selesaikan kontrak migrasi program generik dan legacy UMV; adopsi rute dan konfigurasi modul scoped tenant.
• P1: verifikasi backup/rollback, privacy, aksesibilitas, dan integrasi pihak ketiga.

19 PAKET KERJA AGENT AUDIT

19 — Prompt penugasan mandiri untuk AI Agent

Mandat

Audit implementasi SAKILA terhadap baseline PRD v2.1. SAKILA adalah ERP SaaS lintas organisasi, bukan sistem yang berpusat pada program wakaf Braille UMV.

1. Baca 16_PENETAPAN_BASELINE_AUDIT.md, 17_KEPUTUSAN_IMPLEMENTASI_DAN_ADR.md, 18_GERBANG_GO_NO_GO_DEPLOY.md, 14_TAHAP30_KONTRAK_ACCEPTANCE.md, dan MATRIKS_REQUIREMENT.csv. Baca juga keputusan pemilik 16 Sep, PRD V5.2 dan V6 lengkap.
2. Inspeksi source read-only; catat lokasi, commit, status dirty dan test fixture. Jangan menimpa file operasional, secrets, VoIP worktree atau database yang ada.
3. Hasilkan tabel requirement → evidence → status (implemented/partial/missing/conflicting/unverified) → severity → acceptance test → owner → tindakan.
4. Untuk setiap P0, buat tes negatif di sandbox sintetis; verifikasi HTTP dan database before/after, ledger, audit, serta tenant boundary.
5. Pisahkan fakta source, bukti tes, hipotesis, dan keputusan pemilik. Jangan melemahkan tes agar PASS.
6. Keluarkan rekomendasi per komponen: reuse, refactor, rewrite isolated component, atau new SaaS foundation; jelaskan migration/rollback.
7. Jangan menjalankan deploy, merge, migrasi produksi, atau mengubah database nyata tanpa mandat eksplisit dan gate di dokumen 18.

Deliverable audit tunggal

SAKILA_GAP_ASSESSMENT.md, SAKILA_SECURITY_P0.md, SAKILA_MODERNIZATION_PLAN.md, SAKILA_TEST_EVIDENCE.md, dan SAKILA_ADR_DECISIONS_REQUIRED.md. Semua menyebut versi sumber, tanggal dan lingkungan. Ketidakpastian dinyatakan, bukan disembunyikan.