Flow Implementasi: Pembubaran Yayasan

Tanggal: 2026-08-28 · Branch: dev/5 · Status: rancangan disetujui, belum ada kode diubah
Revisi: 2026-08-28 sore — keputusan koran ditutup, 3 sampel nyata masuk, temuan dari akta asli

Dokumen ini menetapkan alur Pembubaran Yayasan di sistem OCR: UI-nya mengikuti
permohonan yang sudah ada (Pendirian, Perubahan, Perbaikan) sepersis mungkin,
dan input manual ditekan dengan membaca data langsung dari Akta Pembubaran.

1. Ringkasan: yang sudah berdiri jauh lebih banyak dari dugaan

Pemeriksaan kode pada 2026-08-28 menemukan alur ini sudah hampir lengkap.
Yang tersisa bukan membangun alur, melainkan menyambungkan tiga kabel yang
komponennya sudah ada di repo.

2. Alur SABH yang ditiru

Dibaca dari controllers/yayasanbaru/PembubaranController.php dan diverifikasi
terhadap 80 transaksi 2025 (id_aksi_transaksi = 28).

Empat alasan resmi (AlasanForm::listAlasan): Rapat Pembina, Berakhirnya jangka
waktu, Tujuan tercapai/tidak tercapai, Putusan pengadilan. Data 2025 hanya
memakai dua yang pertama dan ketiga.

Tidak ada verifikator. Seluruh 80 baris berstatus status_transaksi = 1,
dan tangga UI kita sudah menganggapnya self-service (4 rung, berakhir di
"Selesai · Pembubaran tercatat").

Tidak ada transaksi "berakhirnya" untuk yayasan. Berbeda dengan PT yang punya
aksi 36 sebagai tahap terpisah, likuidasi di sisi yayasan adalah langkah ke-5 di
dalam pembubaran itu sendiri.

3. UI: sama persis dengan permohonan lain

Tangga yang dipakai identik bentuknya dengan Pendirian Yayasan, hanya beda
kalimat rung terakhir:

Unggah      AI mengklasifikasi otomatis
Ekstraksi   AI membaca dokumen
Tinjauan    Verifikasi & kirim
Selesai     Pembubaran tercatat

Rute pun mengikuti pola yang sama dengan Perbaikan dan Perubahan:

/:base/pembubaran/:submissionId/extraction
/:base/pembubaran/:submissionId/review
/:base/pembubaran/:submissionId/status

Masuknya lewat pintu unggah bersama, bukan halaman pilih entitas. Halaman
NirlabaPembubaranSelectPage sudah dihapus.

Yang datanya memang berbeda, dan bagaimana menampilkannya

Pembubaran punya empat blok yang tidak ada di permohonan lain. Semuanya tetap
memakai komponen yang sudah dipakai flow lain, hanya isinya berbeda:

Tidak ada komponen baru yang perlu dibuat dari nol.

4. Alur yang diusulkan

Resolve bukan langkah UI. Ia pass di backend sesudah ekstraksi: nama yayasan
hasil OCR diubah jadi baris registri (badan_hukum_id beserta organ, alamat,
NPWP, status blokir). Tanpa itu permohonan tidak punya kunci, dan kuorum 2/3
tidak punya pembanding.

Konfirmasi identitas terjadi di Tinjauan, sama seperti permohonan lain.
Bukan mengetik, hanya melihat dan menyetujui.

Kenapa resolve dari akta layak dipercaya

Diukur pada registri: dari 417.535 nama yayasan, 417.244 unik (99,93%). Hanya
291 nama kembar, menyentuh 589 dari 417.615 baris (0,14%).

Akta juga memuat penyempit tambahan yang sudah diekstrak: sk_pengesahan,
akta_pendirian, npwp, dan kedudukan.

Satu jebakan yang sudah tercatat di kode: akta menyebut SK pendirian, registri
menyimpan SK terakhir, jadi untuk yayasan yang pernah diubah keduanya berbeda.
SK dipakai sebagai penyempit, tidak pernah sebagai syarat. Kedudukan justru
penyempit yang lebih kuat.

Bila ketemu lebih dari satu, jangan menebak: tampilkan kandidat untuk dipilih.
Resolver sekarang sudah benar, dua baris bernama sama menghasilkan not_found.

5. Checklist SABH jadi hasil, bukan pertanyaan

Meniru centang SABH apa adanya berarti memindahkan formulir ke layar tanpa
menambah nilai. Tiap syarat diganti validasi yang menjawab sendiri.

Yang tetap manual, dan memang seharusnya:

• Deklarasi likuidasi (Pasal 66 UU 16/2001). Pernyataan tanggung jawab
  notaris, bukan data. Tidak boleh disimpulkan dari dokumen.
• Sisa kekayaan. Akta hanya memuat klausa tujuan, bukan angka; angkanya baru
  ada setelah likuidasi selesai. Skema kita sudah menyatakan ini.
• Koreksi hasil OCR. Itu inti produknya.

6. Tiga kabel yang belum tersambung

6.1 Resolve identitas tidak pernah dipanggil

services/nirlaba-pembubaran-autoresolve.ts sudah ada, lengkap dengan tesnya
(autoResolveNirlabaPembubaran). Tapi grep ke seluruh src menunjukkan
satu-satunya pemanggilnya adalah tesnya sendiri.

document-processor.ts baris 2279-2301 memanggil extractNirlabaAkta untuk
akta pembubaran lalu return — tidak ada langkah resolve sesudahnya.

Akibatnya submission.oldData hanya terisi lewat POST /:id/select, endpoint
yang frontend tidak panggil lagi. Jadi identitas registri praktis kosong,
dan setiap aturan yang membandingkan ke registri berstatus SKIPPED.

Yang perlu: panggil autoresolve setelah ekstraksi akta pembubaran selesai.

6.2 Kliping koran belum diekstrak untuk nirlaba

services/bukti-pengumuman-extract.ts sudah ada dan dipakai PT. Ia
mengembalikan nama_koran, tanggal_pengumuman, nomor_pengumuman.

Untuk nirlaba, namaSuratKabar dan tanggalCetak masih diketik ke form. Artinya
KORAN_PEMBUBARAN dan KORAN_LIKUIDASI saat ini memverifikasi ketikan, bukan
bukti — dua aturan yang menghitung selisih hari dari angka yang diketik sendiri
oleh yang mengetik.

Ini penghematan input manual terbesar: dua kliping, empat field, dua aturan yang
langsung jadi bermakna.

6.3 Kehadiran masih default manual

KehadiranSource sudah bertipe "akta" | "registry" | "manual", tapi default-nya
"manual" dan hasil ekstraksi kehadiran_rapat belum mengisinya. Jalurnya sudah
disiapkan, tinggal dialiri.

7. Urutan pengerjaan yang disarankan

8. Keputusan yang sudah diambil

Koran likuidasi boleh menyusul — mengikuti PT. (Diputuskan 2026-08-28.)

Pengumuman pembubaran terbit maksimal 5 hari sejak likuidator ditunjuk;
pengumuman likuidasi 30 hari sejak likuidasi berakhir. Saat akta baru
ditandatangani, koran likuidasi hampir pasti belum ada.

Konsekuensinya untuk implementasi: KORAN_LIKUIDASI tidak memblokir submit.
Statusnya menyusul, divalidasi belakangan, persis pola PT yang aturannya berbunyi
"boleh menyusul". KORAN_PEMBUBARAN tetap diperiksa karena jendelanya 5 hari dan
biasanya sudah terbit saat permohonan diajukan.

Masih terbuka: Perkumpulan ikut sekarang atau menyusul?
PEMBUBARAN_PERKUMPULAN masih jatuh ke tangga Pendirian dan belum punya skema
ekstraksi pembubaran. Aturan pembubaran saat ini hanya terikat ke set yayasan.

9. Risiko

• Salah resolve berarti membubarkan yayasan yang keliru. Ini tidak bisa
  dibatalkan. Karena itu kandidat ganda harus ditanyakan, tidak pernah ditebak,
  dan konfirmasi identitas di Tinjauan tidak boleh dihapus meski terasa
  mengulang.
• sisa_kekayaan bebas isi. Validasi numeriknya dikomentari di sumber SABH,
  jadi jangan berasumsi ia angka.
• Kliping koran belum punya sampel. Tiga akta sudah ada (lihat §10), tapi
  belum ada satu pun kliping koran di docs/samples/. Artinya ekstraksi koran
  bisa disambungkan tapi belum bisa diverifikasi sampai ada kliping nyata.

10. Sampel nyata (ditambahkan 2026-08-28)

Tiga akta pembubaran yayasan asli, dari unggahan notaris lewat aplikasi. Tiap
sampel disimpan bersama teks OCR mentahnya dan .expected.json, di
docs/samples/yayasan/pembubaran/.

10.1 Temuan yang mengubah rancangan

kehadiran_rapat kosong di KETIGA sampel, dan itu benar. Ketiganya berjudul
"Pernyataan Keputusan Pembina", bukan berita acara rapat, jadi tidak
mengenumerasi kehadiran.

Konsekuensinya besar: bila pola ini bertahan, kuorum 2/3 tidak akan pernah bisa
dihitung dari akta untuk jenis dokumen ini, dan organ Pembina dari registri
jadi satu-satunya pembanding. Itu memperkuat urutan di §7 — sambungkan resolve
lebih dulu, karena tanpanya KUORUM_KEHADIRAN selamanya SKIPPED.

npwp null di ketiganya, konsisten dengan 54% yayasan tanpa NPWP di registri.

alasan_kategori terpetakan benar ke "tujuan" di ketiganya, termasuk pada
sampel yang OCR-nya rusak. Langkah 1 wizard SABH memang bisa dihapus.

10.2 Pelajaran pipeline dari sampel CREW

Sampel ketiga bukan sekadar "scan jelek". Penyebabnya spesifik dan bisa
diperbaiki di hulu:

1. Deteksi orientasi halaman sebelum OCR, lalu putar otomatis. Halaman 3 dan
   4 dipindai terbalik dan menghasilkan sampah murni. Tidak ada penanda
   /Rotate di PDF, jadi tidak ada yang membetulkannya sendiri.
2. Jangan selalu mendahulukan lapisan teks bawaan PDF. Di dokumen ini
   lapisan bawaannya berbunyi AGUS KTTRNIAWAN dan 'ICREW TRAIEITG CETITER,
   sementara hasil OCR pipeline kita membaca nama yang benar.
3. Silang-periksa antar kemunculan. Nama yang benar muncul tiga kali di satu
   versi teks; versi cacat muncul sekali. Kemunculan mayoritas layak menang.

Catatan koreksi: analisis pertama menyebut ini halusinasi model. Itu keliru, dan
sudah dikoreksi di .expected.json sampel tersebut — ekstraktor membaca sumber
teks yang salah di antara dua yang tersedia, bukan mengarang.

11. Perkiraan waktu pengerjaan

Dasar perhitungan dari sesi 2026-08-28: satu putaran suite backend penuh
berjalan 200-350 detik, frontend 145 detik, dan tiap perubahan yang menyentuh
skema atau kode bersama dijalankan suite penuhnya.

Sekitar seperlima waktunya habis menunggu tes, bukan menulis.

Yang paling murah dan paling berdampak: nomor 1. Satu pemanggilan fungsi
yang sudah ada, dan sesudahnya seluruh aturan registri berhenti SKIPPED —
termasuk kedua kuorum. Sekitar 20-30 menit, dan bisa dikerjakan sendirian.

Yang perlu Anda sediakan dulu: kliping koran. Nomor 3 bisa saya tulis tanpa
sampel, tapi tidak bisa saya buktikan bekerja. Lebih baik menunggu satu kliping
nyata daripada mengirim ekstraksi yang belum pernah melihat dokumen aslinya.