Perubahan Yayasan/Perkumpulan Naik ke Pola Halaman Perubahan PT

Sesi 2026-08-19 (Dian, dev/5). Permintaan: "membuat flow perubahan yayasan mengikuti halaman perubahan PT — upload, classify, extract, review — sambil menyesuaikan requirement perubahan yayasan di SABH."

Hasil singkat

Kedua flow perubahan nirlaba (yayasan + perkumpulan) sekarang memakai struktur halaman yang sama dengan perubahan PT, tanpa mengubah aturan SABH yang sudah dienkode (katalog jenis PAD/PPAD/PPD, kuorum 2/3, attestation syarat dokumen, wajib-beda per jenis, routing PAD ke verifikator).

flowchart LR A["1. Unggah\n/:base/klasifikasi\nboard klasifikasi (sudah pola PT)"] --> B["2. Ekstraksi\nDITULIS ULANG pola PT:\n2 kolom + gate Lanjut"] B --> C["3. Tinjauan\nDITULIS ULANG di atas\nReviewData engine (65/35 + PDF)"] C --> D["4. Status\nPAD -> verifikator\npemberitahuan -> terminal"]

Yang berubah

Backend

Projector delta nirlaba — file baru backend/src/review/projectors/make-nirlaba-delta-review.ts
Factory ber-parameter base (pola component-first yang sama dengan context builder dan rule set), menghasilkan dua projection yang kini terdaftar di REVIEW_REGISTRY (sebelumnya PERUBAHAN_YAYASAN/PERUBAHAN_PERKUMPULAN masih stub null). Ini persis "Fase C" pada rencana 2026-08-13. Seksi yang diproyeksikan:
- data_sabh (registry-entity): data lama hasil autoresolve (submission.oldData) — identitas, nomor SK, notaris, NPWP, kedudukan/alamat, status blokir.
- perubahan (diff "Ringkasan Perubahan"): sebelum vs sesudah per slice. Verdict diambil dari komparator nirlaba-slice-diff yang SAMA dengan yang dipakai rules dan deteksi jenis, jadi halaman tidak mungkin berbeda pendapat dengan gate.
- Seksi diff per jenis dengan gate-by-hiding (sectionsForJenis): identitas (nama), kegiatan (yayasan), kedudukan, alamat, pasal-lain/adart/data-lain (isi = perubahan_dinyatakan dari akta), dan roster delta organ (baris tambah/hapus/tetap; bila data lama tak tersedia, roster baru tampil tanpa mengklaim "semua anggota baru").
- akta (field-list): nomor/tanggal akta + notaris dari ExtractedField, bisa dikonfirmasi/diedit dan klik-ke-bbox.
- Pemetaan rule ke seksi untuk lompat-dari-validasi; AKTA_PRESENT + JENIS_PERUBAHAN_PRESENT ditandai non-overridable (cermin gate submit route).
GET /api/nirlaba/perubahan/:id/prefill kini juga mengembalikan resolved (entitas SABH yang ter-resolve autoresolve: nama, nomor SK, notaris, NPWP, blokir) — sumber data kartu entitas di halaman ekstraksi.
Kebijakan override (validation-override-policy.ts): JENIS_PERUBAHAN_PRESENT masuk daftar locked, konsisten dengan gate submit route nirlaba.

Frontend

Halaman ekstraksi ditulis ulang (NirlabaPerubahanExtractionPage) mengikuti YayasanExtractionPage/PerubahanExtractionPage:
- dua kolom: kiri daftar dokumen (progress, tambah via drag-drop untuk surat pendukung, hapus, ulangi, pratinjau), kanan kartu entitas + panel Hasil Validasi (dengan override beralasan) / kartu "validasi berjalan";
- komponen baru NirlabaPerubahanEntityCard — analog CompanyCard PT: identitas menurut akta, entitas ter-resolve di SABH, dan jenis perubahan terdeteksi (dengan sumber bukti: "terdeteksi dari data lama" / "dinyatakan di akta"), read-only;
- gate "Lanjut ke Tinjauan" ala PT: FAIL yang belum di-override memblokir (WARNING seperti kuorum diselesaikan di Tinjauan), dengan tombol lompat ke pemblokir dan bypass debug;
- status bar + banner selesai + live region + stepper yang benar per base (bug lama: stepper perkumpulan memakai label yayasan karena type di-hardcode — sudah diperbaiki);
- halaman lama (dropzone tunggal + auto-pindah ke review tanpa gate) dihapus.
Halaman review ditulis ulang (NirlabaPerubahanReviewPage) sebagai tenant ReviewData engine (pola PtPerubahanReviewPageV2/YayasanReviewPage):
- ReviewProgressHeader sticky + engine 65% + PtDocumentPicker+ReviewPdfViewer 35% (akta selalu chip pertama; surat pendukung bisa dibuka);
- tiga kartu SABH tetap dipertahankan DI ATAS engine (pola RupsKehadiranSection PT): Jenis Perubahan (konfirmasi hasil deteksi; simpan = re-validasi + refetch engine), Pernyataan Kelengkapan Dokumen, Daftar Hadir Rapat;
- konfirmasi/edit field akta lewat endpoint dokumen generik, dialog edit dengan alasan wajib;
- submit tetap POST /api/nirlaba/perubahan/:id/submit dengan decode HAS_FAIL / ATTESTATION_INCOMPLETE; sukses menuju status (?v=1 bila ke verifikator); read-only setelah COMPLETED/IN_VERIFICATION; deep-link saat ekstraksi belum selesai dialihkan balik ke halaman ekstraksi.
Wiring SSOT: case PERUBAHAN_YAYASAN/PERUBAHAN_PERKUMPULAN di reviewBackNav (flow-nav); komentar route basi soal halaman select dihapus di routes.tsx.

Kesesuaian dengan SABH (tidak berubah, hanya ditata ulang posisinya)

Requirement SABH	Tempatnya sekarang
Cari badan hukum + blokir (step 1 SABH)	Autoresolve dari akta; kartu entitas di Ekstraksi + seksi Data Terdaftar di Tinjauan; rules `ENTITY_FOUND`/`ENTITY_NOT_BLOCKED`
Kuorum daftar hadir 2/3 (1/2 rapat ke-2)	Kartu Daftar Hadir di Tinjauan + rule `KUORUM_KEHADIRAN`
Pilih jenis (step 4 SABH — setelah akta)	Terdeteksi otomatis, dikonfirmasi di kartu Jenis pada Tinjauan (urutannya justru cocok dengan wizard SABH)
"Masih sama dengan sebelumnya" per jenis	Rules wajib-beda + seksi diff per jenis di engine
Syarat dokumen (checklist I-VI + lapis per jenis)	Kartu Pernyataan Kelengkapan (attestation), gate submit
3 surat pendukung wajib unggah	`SURAT_PENDUKUNG_PRESENT` (WARNING) + drag-drop di Ekstraksi
PAD = Persetujuan Menteri; PPAD/PPD = pemberitahuan	Routing submit (verifikator vs terminal) + badge di kartu jenis

Verifikasi

Typecheck backend + frontend: bersih.
Suite backend: 3811 lulus; 4 merah yang SEMUANYA sudah merah sebelum sesi ini (fitness ukuran file routes/submissions.ts, fork rute pembubaran/perbaikan/penggabungan nirlaba, model-dependencies, dan pt-pendirian-review yang bergantung urutan data DB seed) — tidak ada yang menyentuh permukaan yang saya ubah.
Suite frontend (vitest): 1235 lulus, 0 gagal — termasuk test yang mem-pin stepper 4 langkah dan hilangnya route select.

Lanjutan sesi yang sama: roadmap dokumen R1 + R2 diimplementasikan

R1 — Notulen Rapat Pembina + daftar hadir (jawaban dari "kenapa daftar hadir kosong"):
- DocumentType baru NOTULEN_RAPAT_NIRLABA + migrasi Prisma 20260819100000_nirlaba_notulen_doctype.
- Classifier lane nirlaba mengenali judul "NOTULEN / BERITA ACARA / RISALAH RAPAT|KEPUTUSAN" (ter-anchor judul; akta yang mengutip rapat tidak tertangkap — ada unit test-nya).
- Carrier OCR-only + focused pass nirlaba-notulen (backend/src/services/nirlaba-notulen-extract.ts): tier deterministik (jenis rapat, tanggal, "rapat kedua") + satu panggilan 3B guided-JSON untuk daftar hadir; tiap nama di-ground ke teks OCR, nama tak ter-ground dibuang.
- Pass ini memprefill Submission.nirlabaKehadiran (hanya saat masih kosong — input notaris tidak pernah ditimpa) sebelum validasi jalan, jadi kartu Daftar Hadir terbuka sudah terisi dan KUORUM_KEHADIRAN menilai di run yang sama. Unggahan notulen juga auto-memenuhi butir attestation notulen_rapat.

R2 — dokumen identitas reuse dari PT:
- Lane perubahan yayasan kini menerima KTP, Paspor, KITAS, NPWP, Surat Pernyataan Domisili, Data Kontak (semua opsional); extractor-nya sudah flow-agnostic jadi langsung bekerja tanpa perubahan pipeline.
- ATTESTATION_EVIDENCE diperluas (nilai kini daftar DocumentType): NPWP memenuhi fotokopi_npwp + alamat_npwp; surat domisili memenuhi butir kedudukan/alamat.
- Bug ikutan diperbaiki: tiga surat pendukung yayasan dulu ditulis dengan documentType="AKTA" (fallback mapToDocumentType); sekarang memakai tipe jujurnya, begitu pula JENIS_PERUBAHAN_PRESENT kini terkunci di kebijakan override (konsisten dengan gate submit).

Verifikasi ulang: typecheck dua sisi bersih; backend 3819 lulus (8 test baru ikut), frontend 1235 lulus; 3 merah backend tetap set lama yang sudah merah sebelum sesi (offender file-size tidak bertambah).

Masih terbuka setelah R1+R2: validasi silang KTP vs susunan organ baru; tanda terima SPT (belum ada DocumentType); katalog dokumen perkumpulan (menunggu sampel surat pendukungnya).

Catatan lanjutan

Deep-link akta yang tidak terbaca: POST /:id/select masih dipertahankan sebagai satu-satunya jalan manual menimpa entitas, tapi belum punya rumah di UI (catatan lama, belum berubah).
Endpoint yang kini yatim total (GET /lookup, POST /start, POST /:id/extract) bisa dibersihkan pada increment berikutnya kalau diputuskan tidak dipakai CLI/ops.
Akurasi ekstraksi masih terverifikasi pada satu akta asli (NURUS SYURO No. 74) — hardening menunggu sampel (S5).