think
16px
820px

Perubahan Yayasan: Flow SABH vs Kondisi dev5

Tanggal: 2026-08-18. Sumber SABH: ahu-codebase/ahu-online/protected/modules/sabh (checkout lokal). Sumber dev5: branch dev/5 saat ini.

1. Ringkasan

Di SABH ada dua implementasi perubahan yayasan:

  1. Wizard legacy di YayasanController (actionPerubahan sampai actionPerubahanDetailPost, views views/yayasan/_formPerubahan*). Ini jalur yang dipakai notaris sekarang, wizard 5 langkah berbasis session (step1..step4).
  2. Modul yayasanbaru (controllers/yayasanbaru/*, models/yayasanbaru/perubahan/*). Rebuild dengan model form yang lebih rapi (PilihPerubahanForm, TransaksiPerubahanForm). Katalog jenisnya identik dengan legacy; sebagian validasi diff (kegiatan/kedudukan/domisili/organ "masih sama dengan sebelumnya") justru paling jelas terbaca di sini.

Kabar baiknya: struktur dev5 sudah benar dan katalog jenisnya sudah cocok 1:1 dengan SABH (diverifikasi 2026-08-13 terhadap _formPerubahanList.php). Yang belum ada di dev5 terutama: kuorum rapat pembina + daftar hadir, diff per jenis (termasuk kegiatan yang belum masuk state sama sekali), cek blokir, dan section review untuk beberapa jenis (kegiatan, alamat, pasal lain).

2. Flow SABH (wizard legacy, jalur notaris)

flowchart TD S1["Step 1: Data Yayasan\nnama + nomor SK\n+ voucher PAD/PPAD/PPD"] --> S2 S1 -.-> C1["checkYayasan: BadanHukum base=yayasan\n(nomor_sk ATAU nomor_sp_ad)\n+ cek BadanHukumBlokir\n+ cek voucher per jalur"] S2["Step 2: Persyaratan Utama\npilih dasar rapat + checklist syarat\n+ pernyataan wajib"] --> S3 S2 -.-> C2["rups_utama: 'bar' (Berita Acara /\nNotulen Rapat Pembina) atau\n'rups' (Rapat Gabungan)\nchecklist kuorum > 2/3,\nrapat ke-2 minimal 1/2, undangan/iklan"] S3["Step 3: Akta Notaris + Daftar Hadir\nnomor & tanggal akta,\ntanggal rapat pembina,\ninput nama peserta rapat"] --> S4 S3 -.-> C3["cekDaftarHadir:\njumlah hadir >= ceil(2/3 x organ terdaftar)\nnama harus ada di registri AHU\norgan per nama harus cocok\ntidak boleh duplikat"] S4["Step 4: Pilih Jenis Perubahan\nPAD / PPAD / PPD\n+ checklist syarat per item"] --> S5 S5["Step 5: Isi Data Baru + Submit\nfield editable dibatasi jenis terpilih\n+ BO form + syarat dokumen"] --> T S5 -.-> C5["diff wajib beda per jenis\ncek blokir ULANG saat submit\nsyarat dokumen 6 item"] T["Transaksi dibuat"] --> OUT OUT{"jalur?"} OUT -->|PAD| SK["Verifikasi menteri lalu\nSK Persetujuan (CetakSKPerubahan)"] OUT -->|PPAD / PPD| SP["Surat Pemberitahuan (CetakSP)\nterminal, tanpa persetujuan"]

2.1 Katalog jenis (SABH _formPerubahanList.php dan model yayasanbaru)

Jalur Item Syarat tambahan di SABH
PAD (Persetujuan Menteri) Nama Yayasan checklist ref RefPADPersetujuanYayasanNama: bukti persetujuan pemakaian nama, pernyataan notaris sudah cek nama, tidak sedang bersengketa
PAD Kegiatan Yayasan kegiatan baru wajib beda dari lama; wajib minimal satu kategori (sosial/kemanusiaan/keagamaan)
PPAD (Pemberitahuan AD) Kedudukan surat pernyataan pengurus diketahui Kepala Desa/Lurah; kedudukan (provinsi+kabupaten) wajib beda
PPAD Pasal lain yang berubah teks bebas, contoh "Pasal 5, Pasal 6"
PPD (Pemberitahuan Data) Perubahan Organ (Pembina/Pengurus/Pengawas) semua jenis organ wajib terisi; organ terpilih wajib ada yang berubah
PPD Pengangkatan kembali Pengurus dan Pengawas pilih Pengurus/Pengawas; legacy juga menangkap alasan + nomor_alasan
PPD Perubahan Alamat Lengkap ref RefNonPADJenisPerubahanYayasanAlamat: surat pernyataan Kades/Lurah + NPWP; domisili lengkap wajib beda

Katalog nirlaba-jenis-perubahan.ts di dev5 sudah persis memetakan tujuh item ini (nama, kegiatan, kedudukan, pasal_lain, organ, pengangkatan_kembali, alamat) dengan jalur yang sama. Tidak ada koreksi katalog yang diperlukan.

2.2 Validasi penting per langkah di SABH

Step 1 (identitas + voucher)FormDataPerubahanYayasan:
- checkYayasan: cari BadanHukum base yayasan by nama + (nomor_sk ATAU nomor_sp_ad); fallback data migrasi hanya by nama.
- Cek blokir (BadanHukumBlokir terbaru per badan hukum).
- checkPad / checkPpad / checkPpd: voucher billing per jalur (no_voucher_pad/ppad/ppd). Satu transaksi bisa membawa sampai tiga voucher sekaligus.

Step 2 (persyaratan utama) — pilihan dasar rapat menentukan organ mana yang dihitung kuorum:
- bar (Berita Acara / Notulen Rapat Pembina) -> kuorum dihitung dari pembina.
- rups (Rapat Gabungan) -> kuorum dari pengurus + pengawas.
- Checklist attestation: kuorum kehadiran dan hasil suara lebih dari 2/3; untuk rapat ke-2 kuorum minimal 1/2 kecuali AD menentukan lebih besar; undangan/iklan bila lewat Rapat Anggota.

Step 3 (akta + daftar hadir)FormDataPerubahanYayasanAkta::cekDaftarHadir, ini validasi paling berat:
- Jumlah peserta yang diinput >= ceil(2/3 * jumlah organ terdaftar di DB AHU).
- Setiap nama peserta harus cocok dengan data organ terakhir di DB AHU ("Nama Pembina yang diinput tidak sesuai dengan data terakhir...").
- Organ yang diklaim per nama harus cocok dengan registri.
- Kombinasi (nama, organ) tidak boleh duplikat.

Step 5 (data baru + submit) — paling jelas di yayasanbaru/TransaksiPerubahanForm:
- Field yang boleh diedit dibatasi oleh jenis terpilih (mekanisme editable attributes); npwp, nomor_spt, syarat_dokumen selalu editable.
- validateKegiatan: kegiatan baru tidak boleh kosong dan tidak boleh sama dengan lama. Ada rule baru: kegiatan "Makan Bergizi Gratis" tidak boleh dihapus kalau sebelumnya sudah ada.
- validateKedudukan: (provinsi, kabupaten) wajib beda dari lama.
- validateDomisli: domisili lengkap (alamat, RT, RW, kecamatan, kelurahan, kodepos, telepon) wajib beda dari lama.
- validateOrgan: semua jenis organ wajib terisi; untuk jenis organ yang dipilih, datanya wajib ada yang berubah.
- syarat_dokumen 6 item wajib dicentang semua: minuta akta, notulen rapat pembina, fotokopi NPWP + laporan SPT, bukti setor biaya, biaya persetujuan nama (bila ganti nama), surat pernyataan tidak sengketa dan tidak pailit.
- Cek blokir diulang saat submit final (checkBlokirBakum).

Output: PAD masuk antrean verifikasi lalu terbit SK Persetujuan (actionCetakSKPerubahan); PPAD/PPD terminal dengan Surat Pemberitahuan (actionCetakSP). Tagihan dicetak per voucher.

3. Kondisi dev5 saat ini

Fondasi Fase A/B sudah terpasang dan berjalan untuk dua base sekaligus (yayasan + perkumpulan, component-first):

Komponen File Status
Flow def backend/src/flow-engine/flows/yayasan-perubahan.ts v2-generic, route-driven, PAD -> verifikator
Katalog jenis backend/src/services/nirlaba-jenis-perubahan.ts cocok 1:1 dengan SABH
Route backend/src/routes/nirlaba-perubahan.ts /jenis, /lookup, /start, /:id/select (classifier-first), /:id/jenis, /:id/document (re-upload + purge PDF lama), /:id/submit
Lookup data lama backend/src/services/nirlaba-badan-hukum-lookup.ts resolve identitas dari DB SABH (nama + SK + notaris) ke Submission.oldData
Context backend/src/flow-engine/context/nirlaba-perubahan-context.ts "after" dari blob akta, "old" dari oldData; enrichment organ belum
Rules backend/src/flow-engine/rules/nirlaba-perubahan/ + nirlaba-diff.ts lihat tabel gap
Submit routing route /submit FAIL non-override memblokir; PAD -> VerifikasiPerubahan MENUNGGU_VERIFIKATOR; pemberitahuan murni -> COMPLETED terminal
FE frontend/src/pages/nirlaba/NirlabaPerubahan{Select,Extraction,Review,Status}Page.tsx empat halaman sudah ada

Rules yang sudah jalan: AKTA_PRESENT, JENIS_PERUBAHAN_PRESENT (FAIL, non-override), ENTITY_FOUND (FAIL/SKIP), DATA_ACTUALLY_CHANGED (WARNING, baru identitas + kedudukan), plus ORGAN_COMPLETENESS (FAIL) dan NAMA_AVAILABILITY yang di-gate per jenis lewat ruleCodes katalog.

Catatan yang sudah tertulis di flow def: skema ekstraksi akta perubahan masih memakai skema pendirian yayasan sebagai bentuk "after" (blocked-on-S5).

4. Perbandingan dan gap

flowchart LR subgraph SABH A[Identitas + voucher + blokir] --> B[Dasar rapat + syarat kuorum] B --> C[Akta + daftar hadir kuorum] C --> D[Pilih jenis PAD/PPAD/PPD] D --> E[Data baru + diff per jenis + syarat dokumen] E --> F[SK atau Surat Pemberitahuan] end subgraph dev5 A2[Lookup + pilih jenis] --> B2[Upload akta perubahan] B2 --> C2[Ekstraksi + rules] C2 --> D2[Review + submit] D2 --> E2[PAD ke verifikator / terminal] end
# Aspek SABH dev5 sekarang Gap / rekomendasi
1 Kuorum rapat pembina + daftar hadir (2/3 dari organ terdaftar, nama harus cocok registri, tanpa duplikat; rapat ke-2 kuorum 1/2) Tidak ada Gap terbesar. Pola sudah ada di PT: routes/perubahan-kehadiran.ts + desain kehadiran-dari-akta dan kuorum ke-2. Untuk yayasan, kuorumnya terhadap pembina (atau pengurus+pengawas bila rapat gabungan), dan sumber "organ terdaftar" adalah oldData; butuh enrichment organ dari SABH dulu (lihat #2)
2 Diff per jenis, wajib beda (kegiatan, kedudukan, domisili, organ masing-masing dicek "masih sama dengan sebelumnya") DATA_ACTUALLY_CHANGED satu rule agregat, WARNING, hanya identitas + provinsi/kabupaten; organ diff tertunda enrichment Naikkan jadi diff per jenis terpilih (gate lewat ruleCodes yang sudah ada). Prasyarat: enrichment organ + domisili pada nirlaba-badan-hukum-lookup
3 Kegiatan (maksud & tujuan) ikut diperiksa (tidak kosong, beda dari lama, rule MBG tidak boleh dihapus) NirlabaEntityState belum punya field kegiatan; jenis kegiatan ruleCodes: [] Tambah kegiatan ke state + ekstraksi akta perubahan; rule diff kegiatan. Rule MBG bisa dicatat sebagai validasi turunan (SABH baru menambahkannya)
4 Domisili lengkap (alamat, RT/RW, kecamatan, kelurahan, kodepos, telepon) untuk jenis alamat State kedudukan hanya provinsi + kabupaten Perlu perluasan state + skema ekstraksi bila jenis alamat mau divalidasi sungguhan
5 Cek blokir dua kali (step 1 dan submit final) Lookup tidak menyentuh tabel blokir Tambah rule ENTITY_NOT_BLOCKED (FAIL) dari tabel BadanHukumBlokir di query lookup yang sama
6 Section review per jenis (form SABH hanya membuka bagian yang dipilih) sectionKeys katalog menyebut maksud-tujuan, kedudukan, pasal-lain, alamat, tapi flow def hanya mendeklarasikan perubahan, identitas-perubahan, organ, akta, validasi Selaraskan: tambah section untuk kegiatan/kedudukan/pasal-lain/alamat, atau sengaja tampung di perubahan dan bersihkan sectionKeys
7 Syarat dokumen 6 item + pernyataan wajib per step Tidak ada Kandidat attestation checklist saat submit (pola perubahan-attestation-schema.ts PT bisa dipakai ulang)
8 Pengangkatan kembali menangkap alasan + nomor alasan Hanya jenis key, rule ORGAN_COMPLETENESS Nilai tambahnya kecil untuk PoC; cukup dicatat
9 Output: SK Persetujuan (PAD) / Surat Pemberitahuan (PPAD/PPD) Status COMPLETED + antrean verifikator, tanpa dokumen keluaran Increment lanjutan: generator SP/SK, meniru surat gen PP perubahan
10 Voucher/billing per jalur (PAD, PPAD, PPD ditagih terpisah) Tidak ada Sengaja di luar scope PoC; alasan memisah PPAD vs PPD di katalog sudah benar

5. Usulan urutan pengerjaan

  1. Enrichment oldData (organ + domisili + kegiatan dari row SABH yang sama dengan lookup sekarang). Ini membuka #1, #2, #4 sekaligus dan sudah disiapkan hook-nya di komentar nirlaba-badan-hukum-lookup.ts.
  2. Diff per jenis menggantikan WARNING agregat, digate ruleCodes katalog (tanpa ubah struktur).
  3. Kuorum + daftar hadir rapat pembina dari akta (port pola kehadiran PT), termasuk aturan rapat ke-2.
  4. Rule blokir di lookup.
  5. Section alignment flow def vs katalog (perubahan kecil, bisa bareng #2).
  6. Attestation syarat dokumen, lalu generator SP/SK sebagai increment terpisah.

Skema ekstraksi akta perubahan yayasan (bentuk "after" yang sebenarnya, bukan pinjaman skema pendirian) tetap blocked-on-S5, tapi butir 1, 4, dan 5 tidak bergantung padanya.

6. Status implementasi (2026-08-18, belum di-commit)

Butir 1 sampai 6 sudah dikerjakan di working tree dev/5. Butir 6 dikerjakan setelah sampel transaksi asli (akta + 3 surat pendukung + SK + SP dari transaksi 5026081436240139) tersedia di docs/samples/yayasan/perubahan/.

# Increment Isi File utama
1 Enrichment oldData Lookup membaca seluruh state lama dari tbl_badan_hukum: identitas, kedudukan, domisili lengkap, NPWP, tiga organ (parser toleran gaya Perseroan::json_decode_ untuk JSON gabungan koma dan literal NULL), dan kegiatan (keterangan_*). NirlabaEntityState diperluas dengan domisili + kegiatan services/nirlaba-badan-hukum-lookup.ts, schema/nirlaba-perubahan.ts
2 Diff per jenis Lima rule "wajib beda" baru, FAIL (bisa override) saat "masih sama dengan sebelumnya", SKIP saat salah satu sisi belum tersedia: NAMA_CHANGED, KEGIATAN_CHANGED (termasuk kegiatan kosong), KEDUDUKAN_CHANGED, DOMISILI_CHANGED (SKIP dulu, ekstraksi alamat belum ada), ORGAN_CHANGED (hanya slot yang punya data registry). Aktivasi lewat ruleCodes katalog; pengangkatan_kembali sengaja tidak mengaktifkan rule perubahan rules/nirlaba-perubahan/jenis-diff.ts, services/nirlaba-jenis-perubahan.ts
3 Kuorum + daftar hadir Kolom baru Submission.nirlabaKehadiran (+ migration), endpoint GET/PUT /:id/kehadiran (roster registry + simpan centang), rule KUORUM_KEHADIRAN paritas cekDaftarHadir SABH: duplikat, nama harus ada di registri, organ harus cocok, kuorum ceil(2/3) atau ceil(1/2) untuk rapat kedua; basis rapat pembina atau rapat gabungan. Kartu FE "Daftar Hadir Rapat" di halaman review rules/nirlaba-perubahan/kuorum.ts, routes/nirlaba-perubahan.ts, components/nirlaba/nirlaba-kehadiran-card.tsx
4 Blokir Lookup membaca baris terbaru tbl_badan_hukum__blokir (terblokir bila action = blokir atau last_status = 1); rule ENTITY_NOT_BLOCKED FAIL dengan pesan penolakan SABH, SKIP bila ledger tidak terbaca services/nirlaba-badan-hukum-lookup.ts, rules/nirlaba-diff.ts
5 Section alignment Semua sectionKeys katalog kini dideklarasikan di flow def yayasan + perkumpulan; ada test penjaga supaya katalog dan flow def tidak bisa saling lepas lagi flows/yayasan-perubahan.ts, flows/perkumpulan-perubahan.ts
6 Attestation + SP/SK Kolom Submission.nirlabaAttestation (+ migration): pernyataan kelengkapan dokumen (6 butir lapis B + butir per jenis lapis C), submit menolak sampai lengkap (ATTESTATION_INCOMPLETE); kartu FE "Pernyataan Kelengkapan Dokumen". Generator SP (Surat Penerimaan Pemberitahuan, komponen PPAD/PPD, terbit saat COMPLETED) dan SK (Keputusan Persetujuan, komponen PAD, terbit setelah verifikasi SELESAI) meniru layout sampel resmi; keduanya distempel PRATINJAU tanpa nomor dan tanpa nama pejabat karena penerbit resmi tetap SABH. Tombol unduh di halaman status services/nirlaba-perubahan-attestation.ts, services/nirlaba-surat-generator.ts, routes/nirlaba-perubahan.ts, components/nirlaba/nirlaba-attestation-card.tsx

Semua berlaku untuk dua base sekaligus (yayasan + perkumpulan); untuk perkumpulan katalog attestation sengaja kosong (SABH tidak punya checklist syarat dokumen perkumpulan) sehingga gate-nya otomatis lolos. Verifikasi akhir: typecheck backend + frontend bersih; suite backend 3769 lolos (1 kegagalan fitness anti-fork pada route nirlaba yang sudah gagal sejak sebelum sesi ini, diflag sebagai tugas terpisah); suite frontend (vitest) 1218 lolos.

Increment klasifikasi (2026-08-18, setelah increment 6): butir 2 dan 3 dari daftar kandidat sudah dikerjakan.
- Rule judul deterministik AKTA PERUBAHAN [ANGGARAN DASAR] YAYASAN/PERKUMPULAN ditambahkan ke pre-tier nirlaba, lintas-baris sesuai kepala sampel (judul dan nama yayasan di baris terpisah). Akta perubahan yayasan kini dikenali langsung dari dokumen dengan confidence 1, tidak lagi bergantung pada chain PT + lane ?track=.
- Tiga surat pendukung wajib jadi DocumentType baru (SURAT_TIDAK_SENGKETA_PAILIT, SURAT_PERNYATAAN_BO_YAYASAN, SURAT_PERNYATAAN_NOTARIS) + migration enum. Temuan penting dari uji live: paddle-OCR MENGHANCURKAN judul tebal surat-surat ini (sampel stsp ter-OCR jadi derau) sementara GPU melabelinya akta dengan sangat yakin (stsp = AKTA_PENDIRIAN 0.95, BO = AKTA_RUPS_TAHUNAN 0.9996) — jadi deteksinya bertingkat: (1) text layer PDF via pdftotext (surat SABH selalu PDF digital dengan text layer sempurna), (2) teks OCR, (3) prefix nama file slot SABH (stsp_/bo_yys_/spn_yys_), dan probe berjalan untuk label apa pun (aman karena kepala akta asli tidak pernah diawali "SURAT PERNYATAAN"), kecuali kartu identitas ber-confidence tinggi (jalur cepat tanpa OCR tetap hidup). Diverifikasi terhadap backend live: keempat sampel terklasifikasi benar. Ketiganya kategori resmi di board, store-only tanpa ekstraksi, kehadirannya ditagih rule SURAT_PENDUKUNG_PRESENT (WARNING, khusus yayasan).

Increment ekstraksi (2026-08-18, setelah increment klasifikasi): skema ekstraksi akta perubahan yang sebenarnya sudah dibangun.
- schema/akta-perubahan-yayasan.ts: superset aditif dari skema pendirian (komposisi string, bukan copy-fork; ada test penjaga). Field baru: alamat_lengkap (Pasal 1 "berkantor pusat di ..."), dasar_rapat (jenis + tanggal rapat pembina/gabungan), perubahan_dinyatakan (daftar perubahan yang dinyatakan akta sendiri), referensi_pendirian (nomor akta + SK pendirian yang disebut akta, untuk cross-check registri).
- Pipeline ekstraksi mendapat docKind ("pendirian" | "perubahan") yang diturunkan dari DocumentType, dithread sampai vision retry; guard/harvest/grounding tidak berubah. Perkumpulan tetap memakai skema pendirian sampai sampelnya ada.
- Context: alamat_lengkap kini mengisi domisili state sehingga rule DOMISILI_CHANGED aktif sungguhan untuk ekstraksi baru (blob pendirian lama tetap SKIP jujur).
- Uji live terhadap vLLM dengan akta NURUS SYURO: hasil draft pertama nyaris sempurna — nama, kedudukan (Banten/Tangerang), alamat lengkap (Kampung Sura RT001/RW001), dasar rapat (rapat_pembina 2024-02-08), tiga perubahan yang dinyatakan, referensi pendirian (akta 30 + SK C-1826.HT.01.02.TH 2006 + notaris lama), meta akta (No. 74, 14-08-2026, Sandra Tanod), dan susunan organ baru persis lampiran SK resmi (7 orang, jabatan benar semua).

Increment prefill + perbaikan alur (2026-08-18, terakhir): uji jalan nyata dari board menemukan dua bug laten scaffolding dan melahirkan alur "ekstraksi dulu, ketik belakangan":
- Route GET /api/submissions/:id ternyata tidak pernah ada — semua halaman select/status/review nirlaba memanggilnya dan selalu jatuh ke 404 ("Memuat pengajuan... Not found"). Dibuat sebagai router kecil terpisah (routes/submission-detail.ts, submissions.ts sudah di ceiling ukuran), payload berisi type/status/validationResults/documents.
- Keempat halaman ekstraksi nirlaba menunggu status VERIFICATION_READY yang tidak ada di enum — processor v2-generic mendarat di READY, jadi halaman "memproses" selamanya. Diperbaiki di keempatnya.
- Ekstraksi kini dimulai otomatis di halaman select (POST /:id/extract — ekstraksi tidak butuh identitas/jenis) dan GET /:id/prefill mengisi otomatis: nama badan hukum (dari akta), nomor SK pendirian (dari referensi_pendirian yang dikutip akta), daftar "akta menyatakan" (perubahan_dinyatakan) plus saran jenis hasil pemetaan kata kunci konservatif (suggestJenisFromDeclared — NURUS SYURO: "perubahan susunan pengurus" mencentang organ; "pembaruan anggaran dasar" sengaja tidak dipetakan karena ambigu). Ketikan pengguna tidak pernah ditimpa.
- Prefill basis kehadiran dari dasar_rapat (pola rupsKe PT: nilai tersimpan dulu, hasil ekstraksi kedua, default ketat terakhir) — rule KUORUM_KEHADIRAN dan kartu FE sama-sama memakainya; label AKTA_PRESENT juga dibetulkan ("Akta Perubahan", bukan "Akta Pendirian").
- Verifikasi live end-to-end di backend berjalan: create dari board, detail + documents terbaca, extract dini jalan, prefill mengembalikan nama NURUS SYURO + SK C-1826.HT.01.02.TH 2006 + saran jenis [organ]; suite penuh backend 3788 lolos (sisa 1 fitness anti-fork pre-existing), frontend 1223 lolos.

Increment attestation-UX + perbaikan lookup (2026-08-18, penutup):
- Bug kolom PK registry: SELECT enrichment memakai id_badan_hukum padahal PK tabelnya badan_hukum_id (nama itu hanya ada di tabel blokir) — setiap lookup live diam-diam gagal dan terbaca "unavailable", membuat roster organ/kehadiran kosong. Setelah diperbaiki, lookup NURUS SYURO live mengembalikan state lengkap: organ (JAMI; 5 pengurus; H. JASMAN), domisili, kegiatan, blokir false. Catatan: replika SABH sudah memuat hasil perubahan ini (nomor SK baru AHU-0003337), jadi diff terhadap akta yang sama wajar terbaca "masih sama".
- Attestation menampilkan hanya butir yang relevan: bukti_setuju (biaya persetujuan pemakaian nama) kini bersyarat jenis nama — teks SABH sendiri bilang "jika perubahan dilakukan terhadap nama Yayasan"; butir lapis C memang sudah per-jenis sejak awal.
- Auto-centang dari dokumen terunggah: butir yang didukung berkas nyata terpenuhi otomatis dan terkunci di kartu (peta bukti: surat_pernyataan dan nama_tidak_sengketa terpenuhi oleh upload Surat Pernyataan Tidak Dalam Sengketa dan Pailit). Gate submit ikut menghitung bukti unggahan. Butir lain (minuta, notulen, NPWP+SPT, bukti setor) memang tidak punya slot upload di SABH sehingga tetap berupa pernyataan.

7. Roadmap dokumen (DIPUTUSKAN Efran, 2026-08-18): pendirian + perubahan yayasan

Prinsip tetap: katalog OCR mengikuti kebutuhan DATA (mengganti ketikan manual notaris), bukan sekadar slot upload SABH. Status: Ada = sudah jalan; DISETUJUI = keputusan Efran untuk dibangun; dicoret = tidak dibangun.

Pendirian

Dokumen PT Yayasan Data yang digantikan
Akta pendirian Ada, wajib Ada, wajib Seluruh isi akta
KTP Ada, wajib DISETUJUI NIK, nama, TTL, alamat pendiri + organ
Paspor Ada DISETUJUI Organ WNA
KITAS/KITAP Ada Ada Izin tinggal WNA
NPWP perorangan Ada, wajib DISETUJUI NPWP pengurus
Bukti setor modal/kekayaan Ada, wajib (syarat riil PT) DISETUJUI, opsional-verifikasi (SABH yayasan deklaratif; paling bernilai untuk asing >= Rp100jt) Nilai kekayaan awal
Surat pernyataan domisili Ada, wajib DISETUJUI Alamat lengkap kantor
Data kontak Ada DISETUJUI Email, telepon
Surat Pertimbangan Kemenlu - Ada (varian asing) Syarat pendiri asing
Akta/kutipan wasiat - (tidak ada use case) DISETUJUI, hanya bila kekayaan dari hibah wasiat 4 kolom wasiat manual

Perubahan

Dokumen PT Yayasan Data yang digantikan
Akta perubahan Ada, wajib Ada, wajib Isi perubahan, susunan baru, dasar rapat
Berita Acara / Notulen rapat Ada DISETUJUI, PRIORITAS 1: notulen rapat Pembina + daftar hadir Prefill kuorum + tanggal rapat + butir notulen_rapat
KTP Ada DISETUJUI NIK anggota organ baru
Paspor / KITAS Ada DISETUJUI Organ WNA
NPWP Ada (perorangan) DISETUJUI: NPWP yayasan + tanda terima SPT (butir fotokopi_npwp) Verifikasi NPWP
Surat pernyataan domisili / Kades-Lurah Ada DISETUJUI: jenis kedudukan/alamat (butir attestation-nya) Alamat baru
Data kontak Ada DISETUJUI Email, telepon
Akta Pemindahan Hak Ada - Khas saham PT
Penetapan Ganti Nama PS Ada - Khas PT
Surat tidak sengketa & pailit - Ada Unggahan wajib SABH
Surat pernyataan BO GAP: slot SABH belum di lane PT Ada Unggahan wajib SABH
Surat pernyataan notaris - Ada Unggahan wajib SABH
Bukti persetujuan pemakaian nama tidak perlu dicoret: cukup NAMA_AVAILABILITY -
Bukti setor modal (perubahan) KEPUTUSAN FINAL 2026-08-18: DIHILANGKAN sepenuhnya — tanpa dokumen DAN tanpa checkbox baru, sama seperti perubahan PT yang sudah berjalan (tidak ada elemen bukti setor apa pun) dicoret sebagai dokumen; butir attestation bukti_setor yayasan (as-built, paritas checklist SABH yayasan) tidak berubah -

Roadmap eksekusi (urutan + perkiraan)

Fase Isi Perkiraan Catatan
A Pendirian yayasan: KTP + Paspor + NPWP + domisili + kontak masuk lane, presence rule per dokumen (mulai WARNING, naik wajib setelah stabil) 0.5 hari Reuse penuh: enum, classifier terlatih, ekstraktor flow-agnostic (document-processor dispatch by documentType, terverifikasi)
B Pendirian yayasan: bukti setor kekayaan (reuse keluarga BUKTI_TRANSFER, cross-check nilai vs kekayaan_awal + floor asing) + akta wasiat (enum baru, classifier judul, store-only, rule ter-gate bila akta menyatakan sumber hibah wasiat) 0.5 hari Wasiat = satu-satunya enum baru di pendirian
C Pendirian yayasan: verifikasi silang identitas (NIK KTP vs organ akta, nama NPWP vs pengurus — adaptasi matcher PT ke organ nirlaba) 1 hari Nilai jual utama OCR; rules yang dulu sengaja di-drop dari D11
D Perubahan yayasan PRIORITAS 1: notulen rapat Pembina + daftar hadir — enum baru, classifier judul (text-layer dulu), extractor kecil (tanggal + daftar hadir) yang memprefill nirlabaKehadiran + auto-memenuhi butir notulen_rapat 0.5-1 hari Penghapus input manual terbesar yang tersisa
E Perubahan yayasan: KTP/Paspor/KITAS/NPWP+SPT/domisili/kontak masuk lane + pemetaan ATTESTATION_EVIDENCE (NPWP+SPT -> fotokopi_npwp; surat domisili -> butir kedudukan/alamat) 0.5 hari Reuse penuh + mekanisme evidence yang sudah jadi
F Perubahan yayasan: verifikasi silang KTP vs susunan organ BARU di akta 0.5-1 hari Lanjutan C, roster sisi "after"
G Kartu attestation perubahan PT (checklist syarat_utama, opsi 2): butir ter-gate jenis yang relevan — TANPA butir bukti setor modal sama sekali (keputusan final 2026-08-18: disamakan dengan perubahan PT yang sudah berjalan, yang tidak punya elemen bukti setor apa pun) 0.5-1 hari Interpretasi terkonfirmasi bersama Efran

Total perkiraan: 4-5 hari kerja untuk semuanya; fase A+D+E (2 hari) sudah memberi sebagian besar nilai. Perkumpulan menyusul dengan pola yang sama begitu sampelnya ada.

Masih terbuka: akurasi prompt perubahan baru terverifikasi pada SATU akta (S5 terbuka sebagian; hardening menunggu sampel tambahan), dan set surat pendukung perkumpulan (slot SABH beda: kepengurusan + penunjukan BO, belum ada sampel).

8. Audit ulang menyeluruh (2026-08-20)

Seluruh langkah wizard SABH ditelusuri ulang dari source (YayasanController actionPerubahan..PerubahanDetailPost, FormDataPerubahanYayasan*, yayasanbaru/TransaksiPerubahanForm, _formPerubahanList.php) dan dicocokkan dengan implementasi dev5 per endpoint.

8.1 Paritas yang TERVERIFIKASI lengkap

Langkah SABH dev5 Catatan verifikasi
Step 1: identitas (nama + SK, terima nomor_sp_ad) lookup + autoresolve, attempt SK lalu nama-unik termasuk snapshot pra-filing (diff terhadap parent transaksi, paritas PT)
Step 1: cek blokir ENTITY_NOT_BLOCKED dari tbl_badan_hukum__blokir baris terbaru, kriteria sama dengan checkBlokirBakum
Step 2: dasar rapat + checklist syarat nirlabaKehadiran.basis + kartu attestation basis bar/gabungan menentukan organ kuorum, sama
Step 3: daftar hadir + kuorum KUORUM_KEHADIRAN duplikat, nama harus di registri, organ cocok, ceil(2/3), rapat ke-2 ceil(1/2) — paritas cekDaftarHadir; plus prefill dari notulen (nilai tambah OCR)
Step 4: katalog jenis 7 item, 3 jalur katalog 1:1; picker kini dikelompokkan 3 heading SABH (2026-08-20) sebelumnya grid datar; sekarang paritas dengan SABH dan picker PT
Step 4: pasalList teks bebas Submission.nirlabaPasalLain + input di kartu jenis + rule PASAL_LAIN_FILLED (2026-08-20) PASS diketik / WARNING fallback pernyataan akta / FAIL dua-duanya kosong
Step 5: validateKegiatan beda-dari-lama KEGIATAN_CHANGED + compareKegiatan dua level (bidang vs rincian, 2026-08-20) baseline 2016 label-only kini jujur "tidak dapat dibandingkan", tidak lagi false-changed
Step 5: validateKedudukan / validateDomisli / validateOrgan KEDUDUKAN_CHANGED / DOMISILI_CHANGED / ORGAN_CHANGED + ORGAN_COMPLETENESS per jenis, gate ruleCodes
Step 5: syarat dokumen 6 butir + Ref per jenis attestation lapis B (6 butir, bukti_setuju bersyarat nama) + lapis C (nama 3, kedudukan 1, alamat 2) teks item dicek ulang vs Settings::getRef — cocok
Upload akta + 3 surat wajib (stsp/bo_yys/spn_yys) SURAT_PENDUKUNG_PRESENT FAIL-overridable + classifier 3 tingkat slot BO yayasan = surat pernyataan saja, SABH juga tidak entry data BO di wizard ini
Output SP (PPAD/PPD) / SK (PAD pasca-persetujuan) generator PRATINJAU + gate suratGate SK menunggu verifikasi SELESAI — benar, tapi lihat gap #1

8.2 Gap yang MASIH ada

# Gap Bobot Detail
1 Antrean verifikator tidak memuat PERUBAHAN_YAYASAN/PERKUMPULAN BLOCKER jalur PAD verifikator-queue.ts:81 hanya memfilter tipe PT. Submit PAD membuat VerifikasiPerubahan MENUNGGU_VERIFIKATOR tapi baris itu tidak pernah muncul di antrean mana pun, jadi tidak ada jalan ke SELESAI dan unduhan SK selamanya NOT_APPROVED. Perlu: tambah kedua tipe nirlaba ke filter antrean + dukungan halaman review verifikator (projector sudah ada)
2 Blokir tidak dicek ULANG saat submit final kecil-menengah SABH memanggil checkBlokirBakum dua kali (step 1 dan submit). Kita hanya saat lookup/validasi; submit membaca hasil tersimpan. Entitas yang diblokir SETELAH validasi masih bisa submit. Murah: panggil fetchBlokir sekali lagi di /submit
3 Rule "Makan Bergizi Gratis tidak boleh dihapus" kecil TransaksiPerubahanForm::validateKegiatan:191 — kegiatan MBG lama wajib tetap ada di kegiatan baru. Belum ada padanannya di compareKegiatan/rule
4 Pengangkatan kembali: alasan + nomor_alasan tidak ditangkap kecil sudah dicatat sejak audit pertama; nilai PoC kecil
5 Nomor SPT tidak pernah masuk data kecil SABH: npwp + nomor_spt selalu editable di step 5; kita hanya butir attestation fotokopi_npwp (+ bukti NPWP upload). Tidak ada field/ekstraksi tanda terima SPT
6 Pembatasan editable per jenis (step 5) beda postur catatan SABH mengunci field di luar jenis terpilih; kita gate-by-hiding section review, tapi field akta lain tetap bisa diedit dari panel dokumen. Konsekuensi praktis kecil karena diff/submit tetap dinilai per jenis
7 Jalur PENYESUAIAN (UU 28/2004, badan hukum lama) out-of-scope sadar wizard SABH terpisah (actionPenyesuaian); step-1 kita sudah menerima nomor_sp_ad hasil penyesuaian, tapi flow penyesuaian itu sendiri belum discope
8 Voucher/billing per jalur + cetak tagihan out-of-scope (keputusan) billing tetap di SABH; alasan PPAD≠PPD di katalog sudah menjaga kesiapan
9 Yayasan asing pada perubahan kecil SABH hanya MENAMPILKAN flag jenis_transaksi=asing (checkbox disabled); tidak ada validasi tambahan di wizard — tidak ada tindakan
10 Akurasi prompt ekstraksi = 1 sampel terbuka (S5) belum berubah; hardening menunggu sampel tambahan
11 Set surat pendukung perkumpulan menunggu sampel slot SABH beda (kepengurusan + penunjukan BO)

8.2b Status gap (update 2026-08-20, sesi lanjutan)

Gap #1-#3 SELESAI dikerjakan:

# Gap Status
1 Antrean verifikator nirlaba SELESAI: kedua tipe masuk filter antrean (verifikator-queue.ts), baris diberi type/nama (oldData.state.nama)/label jenis dari katalog, filter pad/ppad/nonpad memetakan jalur PAD/PPAD/PPD; halaman baru VerifikatorNirlabaReviewPage (/verifikator/nirlaba/:id) memakai proyeksi ReviewData notaris secara read-only + DecisionPanel + AuditTrail; decide bercabang nirlaba: initial APPROVE langsung SELESAI (tanpa voting PS, paritas SABH: keputusan pejabat tunggal menerbitkan SK), REVISE membuka ulang submission + menghapus nirlabaAttestation + override; submit ulang nirlaba me-reset PERBAIKAN ke MENUNGGU_VERIFIKATOR (paritas PT)
2 Blokir dicek ulang saat submit SELESAI: resolveNirlabaBlokir (lookup service) dipanggil di /submit; terblokir = 409 ENTITY_BLOCKED dengan pesan SABH; ledger tak terjangkau = lanjut (posture SKIP)
3 Rule MBG SELESAI: KEGIATAN_MBG (jenis-gated kegiatan): registry lama memuat "Makan Bergizi Gratis" dan akta menghapusnya = FAIL (pesan SABH); cocok eksak per pilihan (paritas in_array SABH); senyap bila entitas tidak pernah terdaftar MBG

Gap #4 dst tetap seperti tabel 8.2 (dicatat / out-of-scope / menunggu sampel).

8.2c Keputusan surat keluaran (2026-08-20, setelah gap 1-3)

Efran memutuskan MENGIKUTI PT: sistem tidak menerbitkan surat apa pun (SP/SK pratinjau
increment 6 DIHAPUS — generator, endpoint unduhan, dan tombol di halaman status).
Baris "Output SP/SK" pada tabel 8.1 tidak lagi berlaku; penerbit surat resmi
sepenuhnya SABH. Halaman status ditulis ulang meniru SubmissionStatusPage PT:
guard redirect (pre-submit / PERBAIKAN kembali ke review), header badge status
verifikasi live + catatan penolakan, dan isi review read-only.

8.3 Rekomendasi urutan

  1. Gap #1 (antrean verifikator nirlaba) — satu-satunya yang mematikan alur; tanpa ini jalur PAD tidak pernah selesai end-to-end.
  2. Gap #2 (blokir ulang saat submit) — beberapa baris.
  3. Gap #3 (rule MBG) — kecil, satu cabang di compareKegiatan/rule kegiatan.
  4. Sisanya dicatat sebagai keputusan sadar / menunggu sampel.