think
16px
820px
← all files

Perubahan Yayasan + Perkumpulan — rencana implementasi (component-first)

Status: DRAFT untuk review Efran. Tanggal 2026-08-13.

Increment pertama dari ekspansi transaksi nirlaba (di luar Pendirian yang sudah ada).
Keputusan yang sudah disepakati (Q&A 2026-08-13):

  • Urutan: per-transaksi lintas entitas — kerjakan Perubahan untuk yayasan DAN perkumpulan dulu, baru lanjut Pembubaran, Perbaikan, Penggabungan.
  • Entitas: dua-duanya paralel lewat lapisan komponen bersama.
  • Status akhir: ikut SABH — jalur Persetujuan Menteri (PAD) berujung verifikator; jalur Pemberitahuan (PPAD/PPD) terminal.
  • Blocker S5: bangun scaffolding sekarang, akurasi ekstraksi nyusul sampel akta asli.

Catatan ownership: di catatan kerja, yayasan domain dev5 dan perkumpulan domain dev_4. Increment ini menyentuh dua-duanya atas arahan langsung — perlu koordinasi supaya tidak tabrakan.

1. Apa yang sudah ada dan dipakai ulang

Kebutuhan Perubahan Sudah ada di Rencana pakai
Pola tambah flow (registry, defineFlow) flow-engine ikuti apa adanya
Rules bersama nirlaba (AKTA_PRESENT, ORGAN, NAMA) rules/nirlaba-shared pakai ulang
Cek ketersediaan nama (SABH) services/nirlaba-nama-availability.ts pakai ulang
Ekstraktor akta nirlaba (variant yayasan/perkumpulan) services/nirlaba-akta-extract.ts tambah variant perubahan
Review diff sebelum-vs-sesudah review/projectors/pt-perubahan-review.ts (makePtDeltaReviewProjection) jadikan factory nirlaba
Pilih jenis perubahan (multi-select + kontradiksi) PP: services/pp-jenis.ts + PpPerubahanFormPage mirror untuk nirlaba
Old-data (keadaan sebelum) PP: resolveLatestPpTransaction; PT: loadOldData (SABH) GAP — bangun baru
Routing terminal vs verifikator routes/* (inline per rute) mirror, cabang PAD vs Pemberitahuan

2. Gap utama: sumber "old data" nirlaba

Perubahan itu diff sebelum-vs-sesudah, jadi butuh keadaan lama badan hukum. Untuk nirlaba
belum ada sama sekali (Pendirian companyLookup: false, hanya cek nama).

Rencana: layanan baru services/nirlaba-badan-hukum-lookup.ts, meniru pola null-safe
nirlaba-nama-availability.ts:

  • Query SABH read-only (tbl_badan_hukum + tabel transaksi yayasan/perkumpulan), discan by base ("yayasan"/"perkumpulan") + nama/nomor SK.
  • Kembalikan null kalau SABH belum dikonfigurasi atau query gagal (bukan "kosong = tidak ada perubahan"). Rule memetakan null ke SKIPPED, sama seperti cek nama.
  • Kolom DDL diverifikasi ke source SABH (TransaksiYayasan.php, TransaksiPerkumpulan.php, BadanHukum.php) sebelum dipakai; disentralkan di satu konstanta SOURCES seperti NAMA_SOURCES.

Karena scaffolding-now: skeleton dulu (null-safe), kolom-kolom final menyusul verifikasi DDL.

3. Jenis perubahan dan routing status

Dari form SABH, Perubahan nirlaba terbagi tiga jalur. Catalogue SSOT baru:
services/nirlaba-jenis-perubahan.ts (mirror pp-jenis.ts).

Yayasan:

  • PAD (Persetujuan Menteri): nama, kegiatan
  • PPAD (Pemberitahuan AD): kedudukan, pasal_lain
  • PPD (Pemberitahuan Data): organ, pengangkatan_kembali, alamat

Perkumpulan:

  • PAD (Persetujuan Menteri): nama, keseluruhan_ad, organ_kepengurusan, kedudukan, data_lain
  • PPD (Pemberitahuan Data): nama_pengurus_pengawas, pengangkatan_kembali, alamat

Routing status = fungsi dari jenis terpilih:

flowchart TD A[Submit Perubahan] --> B{Ada item PAD terpilih?} B -- ya --> C[COMPLETED + VerifikasiPerubahan MENUNGGU_VERIFIKATOR] B -- tidak, hanya Pemberitahuan --> D[COMPLETED terminal, tanpa verifikator]

Aturannya: kalau ada satu saja item jalur PAD, seluruh permohonan masuk antrean verifikator.
Kalau semua item cuma Pemberitahuan (PPAD/PPD), terminal. Helper requiresVerifikator(jenis)
di catalogue jadi satu-satunya tempat keputusan ini.

4. Alur end-to-end (target)

sequenceDiagram participant U as Pemohon participant FE as Frontend participant API as Route nirlaba-perubahan participant ENG as Flow engine participant SABH as SABH (read-only) U->>FE: Pilih badan hukum + centang jenis perubahan FE->>API: POST /start {base, entityRef, jenis[]} API->>SABH: lookup old data (nirlaba-badan-hukum-lookup) API->>ENG: jalankan flow (extract akta perubahan) ENG-->>API: hasil ekstraksi + validasi (diff vs old data) API-->>FE: review (delta sebelum/sesudah + roster organ) U->>FE: Konfirmasi / override / submit FE->>API: POST /submit API->>API: requiresVerifikator(jenis)? alt ada PAD API-->>FE: MENUNGGU_VERIFIKATOR else hanya Pemberitahuan API-->>FE: COMPLETED end

5. Lapisan komponen bersama (yang dibangun)

Supaya yayasan dan perkumpulan tidak copy-paste:

  1. services/nirlaba-badan-hukum-lookup.ts — old data, base-parameterized (baru).
  2. services/nirlaba-jenis-perubahan.ts — catalogue PAD/PPAD/PPD + requiresVerifikator (baru).
  3. flow-engine/context/nirlaba-perubahan-context.ts — builder ctx variant-parameterized (baru).
  4. flow-engine/rules/nirlaba-perubahan/index.ts — rule set bersama, di-config per base (baru).
  5. review/projectors/make-nirlaba-delta-review.ts — factory delta review organ-aware (baru, adaptasi dari makePtDeltaReviewProjection).
  6. Halaman frontend generik nirlaba-perubahan (select, extraction, review, status) yang di-parameter base.

Tiap flow (yayasan/perkumpulan) lalu cuma deklarasi tipis di atas lapisan ini.

6. Urutan build (Perubahan)

Fase A — fondasi bersama (tanpa sentuh enum, aman, bisa typecheck sendiri):

  1. nirlaba-jenis-perubahan.ts (catalogue + routing helper) + unit test.
  2. nirlaba-badan-hukum-lookup.ts (skeleton null-safe) + unit test.

Fase B — enum + skema (memaksa registry lewat compile error, jadi dibundel dengan flow def):

  1. Prisma: DocumentType += AKTA_PERUBAHAN_YAYASAN, AKTA_PERUBAHAN_PERKUMPULAN;
    SubmissionType += PERUBAHAN_YAYASAN, PERUBAHAN_PERKUMPULAN. Bikin file migrasi
    (bukan cuma db push — staging pakai migrate deploy).
  2. bun run db:gen-enums.

Fase C — mesin per-flow:

  1. Skema ekstraksi perubahan (best-effort, S5) + wiring variant di document-processor.ts + nirlaba-akta-extract.ts.
  2. nirlaba-perubahan-context.ts (extract blob + old data + jenis).
  3. rules/nirlaba-perubahan/index.ts (shared nirlaba + JENIS_PRESENT, DATA_ACTUALLY_CHANGED, organ PAD checks, gated by jenis).
  4. review/projectors/make-nirlaba-delta-review.ts + dua projector tipis (yayasan, perkumpulan).
  5. Flow def yayasan-perubahan.ts, perkumpulan-perubahan.ts + daftar di registry.ts + submission-type-inference.ts.

Fase D — rute + UI:

  1. Route family nirlaba-perubahan (start dengan jenis, submit dengan cabang PAD/pemberitahuan).
  2. Halaman frontend generik + routes.tsx.

Fase E — verifikasi:

  1. bunx tsc --noEmit backend + frontend; jalankan suite backend+frontend; migration ke test DB.

7. Yang S5-blocked (jujur di depan)

  • Akurasi prompt ekstraksi akta perubahan (skema struktur boleh jalan, angka akurasi nunggu sampel).
  • Verifikasi DDL kolom SABH untuk old-data (skeleton null-safe dulu).

Struktur, rules, review, routing, UI semua bisa selesai dan diuji tanpa sampel; hanya ketepatan
ekstraksi dan query old-data nyata yang menunggu.