Hasil Audit — Checklist Debug Flow Pendirian PT

Sumber checklist: checklist-debug-pendirian-pt.md
Repo yang diaudit: ahu-ocr-dev/dev_5 (branch dev/5, HEAD dd783691)
Metode: audit kode statis + hasil tes manual. Tidak ada kode yang diubah.
Tanggal: 2026-08-04

Bagian 0 (pra-cek penghapusan Domisili & Surat Pernyataan) sudah dihapus dari laporan ini — task 86ex78yf7 di-revert, Domisili & Surat Pernyataan Setor tetap wajib. Item domisili di bagian lain ditandai N/A.

Penomoran temuan memakai satu skema: B = blocker, M = major, N = minor, D = perlu keputusan.

Kolom Sumber: M = tes manual, K = bukti kode, M+K = keduanya sepakat.

Ringkasan

115 item · 84 PASS · 12 FAIL · 4 MANUAL · 15 N/A · 0 perlu keputusan

Lima blocker:

1. B1 — tidak ada UI override validasi, padahal finalize memblokir setiap FAIL yang belum di-override. Notaris bisa terkunci tanpa jalan keluar.
2. B2 — Step 3 tidak punya jalur error sama sekali; ID tidak valid berakhir di spinner abadi.
3. B4 — kewajiban kelima sub-tipe Bukti Setor hanya ditegakkan di Step 2; Step 3 dan Step 4 bocor.
4. B5 — Akta Pendirian tidak bisa diganti. Hapus lalu unggah ulang → 400 Cannot remove Akta Pendirian, seluruh sync batal.
5. B6 — Tinjauan bisa dibuka lewat address bar saat ekstraksi belum selesai; membukanya justru menstempel Ekstraksi sebagai selesai.

(B3 diturunkan ke M14 — tampilan checklist lengkap diputuskan tidak diperlukan.)

Satu cacat berat di luar checklist, terbukti lewat eksperimen langsung — M6. Seluruh endpoint /api/regions/* di backend yang sedang berjalan tidak merespons sama sekali. Pool MySQL SABH dibuat tanpa enableKeepAlive/idleTimeout, jadi setelah koneksi menganggur lewat wait_timeout (8 jam) permintaan menggantung selamanya alih-alih gagal. Dibuktikan: memicu reload modul mengubahnya dari tanpa respons jadi 200 dalam 0,09 dtk. Akan kambuh setiap 8 jam idle. M15: sabh-db.ts punya cacat identik, dan itulah pool yang dipakai rule PP29 & KBLI.

Sub-bagian Cross-validation sudah selesai — SABH terbukti hidup dari environment ini, jadi seluruh itemnya bisa ditutup tanpa menunggu tes UI.

Daftar perbaikan berprioritas

🔴 Blocker

B1 · Tidak ada UI override validasi

Finalize menolak setiap FAIL yang belum di-override — review-data.ts:104-113:

where: { submissionId: id, status: "FAIL", overridden: false }
→ 400 VALIDATION_FAILED "Ada validasi yang masih GAGAL dan belum di-override"

Tapi tidak ada cara meng-override di flow Pendirian PT. Backend-nya lengkap (submissions.ts:1948-2006 — alasan wajib, ada audit trail), hook frontend-nya juga ada (use-submission.ts:311 useOverrideValidation), tapi hook itu nol pemanggil. Panel validasi Step 3 sepenuhnya read-only — validation-results.tsx, 117 baris, nol kata "override". Yang memanggil endpoint itu hanya flow lain: BerakhirnyaReviewPage.tsx:183, LaporanRupsReviewPage.tsx:93, PembubaranReviewPage.tsx:65, PeleburanReviewPage.tsx:80.

Komentar kodenya sendiri mengakui masalah ini dan menyodorkan debug bypass sebagai jalan keluar — review-data.ts:90-97. Kasus paling mungkin: AKTA_DATE_WINDOW FAIL untuk akta di luar jangka 60 hari.

Perbaikan: sambungkan useOverrideValidation ke panel validasi, atau turunkan rule yang bisa FAIL secara sah menjadi WARNING.

B2 · Step 3 tidak punya jalur error

PendirianExtractionPage.tsx:37 bahkan tidak mengambil isError dari hook-nya. Satu-satunya guard adalah :158-164 — if (isLoading || !submission) yang merender spinner.

Jalurnya: backend 404 (submissions.ts:469-471) → apiFetch melempar ApiError (api-client.ts:118-125) → retry 1× lalu menyerah (main.tsx:12) → data tetap undefined → spinner abadi. Berlaku untuk ID salah, backend mati, dan koneksi putus sebelum data pertama masuk.

Rute Pendirian juga tidak dibungkus ErrorBoundary — routes.tsx:114 dan :117 telanjang, sementara enam rute verifikator dibungkus (:255, :259, :263, :267, :271, :294). Tidak ada errorElement di level router.

Perbaikan: tiru pola yang sudah benar di Step 4 — PtPendirianReviewPageV2.tsx:146-154. Perbaikan terkecil, dampak terbesar, dan berdiri sendiri.

~~B3~~ · Diturunkan ke Major (M14)

Keputusan: tampilan checklist lengkap tidak diperlukan — dokumennya tetap wajib dan tetap harus diverifikasi, tapi tidak perlu dirender sebagai daftar di Step 3.

Yang tersisa dari temuan ini pindah ke M14: saat tombol "Lanjut" mati, pesannya tidak menyebut dokumen mana yang kurang. Sisanya (panel hanya merender KTP/Paspor/NPWP) sekarang perilaku yang dikehendaki, bukan cacat.

Konsekuensi untuk B4: perbaikannya tidak lagi berarti "tampilkan lima baris checklist" — cukup gerbangnya yang menangkap, plus pesan yang menyebut apa yang kurang.

B6 · Akses langsung ke Tinjauan saat ekstraksi belum selesai

Terkonfirmasi lewat tes manual: mengganti address bar ke /pendirian/:id/review membuka halaman Tinjauan walaupun ekstraksi belum selesai dan validasi masih GAGAL. (Dari Step 2 tidak bisa karena id belum ada — jadi celahnya khusus setelah submission terbentuk.)

Tidak ada penjaga di lapisan mana pun:

• Frontend — routes.tsx hanya punya RoleGuard (berbasis peran), nol step guard
• Backend — review-data.ts:24-40 hanya 404 kalau submission tidak ada; tidak menggerbangi status
• Lebih jauh — membuka Tinjauan justru menandai Ekstraksi sudah lewat: PtPendirianReviewPageV2.tsx:106-108 mem-POST extraction-ack saat mount

Akibatnya notaris bisa meninjau dan mengonfirmasi field dari dokumen yang masih dalam proses ekstraksi — nilai yang dilihatnya bisa berubah di belakang layar setelah dikonfirmasi. Dan stempel extraction-ack membuat dashboard menganggap tahap itu selesai.

Komentar kodenya menyebut stempel itu disengaja ("routing refinement 2026-07-20") untuk mencegah deep-link terlempar balik ke Step 2 selamanya. Niatnya sah, tapi efek sampingnya jadi celah.

Perbaikan: gerbangi berdasarkan status — kalau submission belum READY/COMPLETED, alihkan ke halaman ekstraksi. extraction-ack tetap dikirim hanya ketika ekstraksi memang sudah selesai.

B4 · Kewajiban lima Bukti Setor hanya ditegakkan di Step 2

Kelima sub-tipe wajib — klasifikasi-doc-types.ts:9-13: Slip Bank, Rekening Koran, Neraca, Surat Keterangan Bank, Surat Pernyataan Setor.

Rule yang seharusnya menjaga ini tidak pernah jalan di Pendirian. REQUIRED_SUPPORTING_DOCS terdaftar di rule set (pt-akta/index.ts:34), tapi baris pertamanya langsung keluar — cross-validator-required-docs.ts:9-16:

if (!input.isPerubahan || !scope) {
  return { ruleCode: "REQUIRED_SUPPORTING_DOCS", …, status: "SKIPPED", message: "Bukan perubahan" };
}

Pendirian bukan Perubahan → selalu SKIPPED. Seandainya pun jalan, isinya hanya memeriksa AKTA_PEMINDAHAN_HAK, PENETAPAN_GANTI_NAMA, BERITA_ACARA_RUPS (:27-36) — nol pemeriksaan sub-tipe Bukti Setor. Karena SKIPPED disaring dari tampilan (ValidationResultsList.tsx:47), user tidak punya petunjuk bahwa pemeriksaan itu absen.

Skenario yang lolos: unggah kelimanya di Step 2 → lolos → di Step 3 hapus empat di antaranya → rematch me-reset baris BUKTI_SETOR lalu memenuhinya kembali karena masih ada satu tersisa → checklist hijau, tidak ada FAIL, tombol aktif → finalize lolos dengan empat dokumen wajib hilang.

Perbaikan (dua tempat, sebaiknya keduanya):
1. Pecah satu baris BUKTI_SETOR jadi lima baris per sub-tipe di submission-checklist.ts:116-122, dan ubah fulfillChecklist di pendirian-pt.ts:66-67 agar memenuhi baris spesifik. Ini otomatis menutup Step 3.
2. Tambahkan rule kelengkapan khusus Pendirian yang membaca PENDIRIAN_DOC_TYPES sebagai sumber kebenaran — menutup Step 4 sekaligus, dan tidak tertinggal saat daftar dokumen wajib berubah.

⚠️ Kerjakan bersama B3. Begitu kelima baris muncul, semuanya akan tidak terlihat di Step 3 — user akan terkunci oleh lima syarat sekaligus yang tak satu pun tampil di layar.

B5 · "Cannot remove Akta Pendirian" — Akta tidak bisa diganti

Ditemukan lewat tes manual; akar masalah terkonfirmasi di kode.

Repro: Step 2 → back ke Step 1 → hapus Akta Pendirian (berhasil) → tambah ulang Akta → "Lanjut" → gagal, 400 Cannot remove Akta Pendirian.

Rantainya:

1. Menghapus baris Akta di board hanya mengubah atom — tidak ada panggilan server, jadi terasa berhasil
2. Akta baru masuk sebagai baris tanpa documentId (file staging segar)
3. "Lanjut" memanggil boardDocumentDiff — store/klasifikasi.ts:178-189. Akta lama masuk remove (ID terlampir yang tidak lagi di board), Akta baru masuk add
4. POST /:id/sync-documents memproses remove lebih dulu — submissions-klasifikasi-board.ts:178-183
5. detachSubmissionDocument menolak tanpa syarat — submission-document-detach.ts:49-51, dengan UNREMOVABLE_TYPE = "AKTA_PENDIRIAN" (:21)
6. Handler langsung return pada penolakan pertama → seluruh sync batal, termasuk Akta baru yang seharusnya menggantikan

Akar masalahnya konseptual: board mengekspresikan "ganti Akta" sebagai remove + add, tapi penjaga hanya melihat remove-nya. Backend tidak punya konsep "replace" — hanya attach dan detach.

Cacat turunan — detach parsial. Loop di :178-183 tidak transaksional. Kalau remove berisi dokumen lain sebelum Akta, dokumen-dokumen itu sudah terlanjur ter-detach saat Akta memicu 400. Submission tertinggal setengah-jadi, dan board di layar tidak mencerminkannya.

Perbaikan:
- Kenali replacement di sync-documents: kalau remove memuat Akta dan add memuat baris berklasifikasi AKTA_PENDIRIAN, izinkan detach-nya (atau proses add dulu baru remove)
- Jadikan loop remove transaksional agar detach parsial tidak mungkin terjadi
- Selaraskan UI: kalau Akta memang tidak boleh dilepas, jangan biarkan barisnya dihapus di Step 1 tanpa peringatan — sediakan "Ganti Akta" sebagai satu aksi

🟠 Major

🟡 Minor

⚪ Perlu keputusan

Tidak ada lagi. Keempat pertanyaan terbuka sudah dijawab:

Satu yang tersisa sebagai pilihan implementasi, bukan pertanyaan terbuka: N6 — kode mati alamat manual (PtAddressForm, PATCH /:id/address, useUpdateAddress, semuanya nol pemanggil). Hapus, atau sambungkan sebagai pelengkap Domisili.

Checklist lengkap — status akhir

File checklist-debug-pendirian-pt.md sengaja tidak diubah — itu catatan tes manual Anda.

Bagian 1 — Upload (8 PASS · 1 terjawab)

Bagian 2 — Klasifikasi (17 PASS · 2 FAIL · 1 MANUAL · 2 N/A)

Bagian 3 — Orkestrasi (7 PASS)

Bagian 3 — Kolom kiri (6 PASS)

Seluruh enam item PASS dari tes manual: collapse/expand, thumbnail, progress per file, drop zone, hapus file di tengah step, tambah file setelah ekstraksi.

Bagian 3 — Kolom kanan (5 PASS · 1 FAIL · 2 N/A)

Bagian 3 — Cross-validation (15 PASS · 2 FAIL · 0 MANUAL · 1 N/A)

✅ Selesai. Semula diperkirakan butuh tes manual, ternyata bisa ditutup seluruhnya: SABH hidup dan terjangkau dari environment ini, sehingga jalur rule-nya bisa diuji langsung; logika rule-nya sendiri sudah dijaga 174 unit test yang semuanya lolos.

Cara verifikasinya (semuanya read-only):
1. Memanggil helper milik proyek sendiri — getBakumSetting() dan validateKbliCodes() di sabh-db.ts — yaitu jalur yang persis dipakai rule PP29_MODAL dan KBLI_VALID
2. Menjalankan bun test src/services/__tests__/cross-validator*.test.ts → 174 pass / 0 fail
3. Fault injection: mengarahkan SABH_DB_HOST ke IP blackhole untuk mengukur perilaku saat SABH mati

Koneksi nyata: AHU_BADAN_HUKUM @ 192.16x.x.x:3306, user bht-read — balas dalam 754 ms.

⚠️ Catatan penting: probe ini berjalan di proses baru, jadi pool-nya segar. Di backend yang hidup lama, pool sabh-db.ts rentan cacat yang sama seperti /api/regions/* — lihat M6 dan M15. Artinya rule PP29 & KBLI bisa menggantung, bukan gagal-cepat, walau logikanya sendiri sudah terbukti benar.

Beberapa item checklist menggabungkan dua klaim ("rule X berjalan dan hasilnya benar"). Baris seperti itu dipecah dua.

Inventaris rule set Pendirian PT (32 rule)

Sumber tunggal: pt-akta/index.ts:15-48.

NIK_KTP_AKTA · NAMA_NPWP_KTP · MODAL_BUKTI_SETOR · PEMEGANG_SAHAM_BUKTI_SETOR · SHARES_SUM_CONSISTENCY · MODAL_HIERARCHY · NOMINAL_RECONCILE · KTP_COMPLETENESS · NPWP_COMPLETENESS · DOMISILI_NAMA · NAMA_PT_CONSISTENCY · PS_TOTAL_100 · CONTACT_INFO_COMPLETE · OLD_DATA_CONSISTENCY · PERUBAHAN_MODAL · DATA_ACTUALLY_CHANGED · SHARES_TRANSFER_BALANCE · SHARES_TOTAL_LEMBAR · REQUIRED_SUPPORTING_DOCS · AKTA_DATE_WINDOW · PERSEROAN_STATE · NPWP_PERSEROAN_FUZZY · NOTARIS_TERAKHIR · JENIS_SELECTION_NONEMPTY · JENIS_DESELECT_REASONS_COMPLETE · UPLOADED_DOC_UNUSED · CONTRADICTORY_JENIS · PEMEGANG_SAHAM_CONTACT · PASSPORT_AKTA · PP29_MODAL✱ · KBLI_VALID✱ · PERUBAHAN_KBLI✱

✱ = async, butuh SABH. Rule #14–17, #21–27, #32 secara semantik milik flow Perubahan — di Pendirian diperkirakan selalu SKIPPED sehingga tersaring dari UI, tapi ini belum dibuktikan. REQUIRED_SUPPORTING_DOCS sudah dipastikan selalu SKIPPED → B4.

Bagian 3 — Alamat PT manual (1 PASS · 9 N/A)

Sub-bagian ini dibuat sebagai pengganti Surat Domisili. Setelah revert, alamat memang datang dari dokumen Domisili (pendirian-pt.ts:62-64), jadi seluruh item "field X tersedia di Step 3" menjadi N/A.

Yang tetap berlaku:

Bagian 4 — Review & Submit (12 PASS · 2 FAIL · 1 N/A)

Bagian 5 — Lintas-flow & ketahanan (12 PASS · 5 FAIL · 3 MANUAL)

Jotai memang dipakai (package.json:22), tapi hanya untuk board Step 1/2. Step 3 & 4 sepenuhnya server-driven lewat TanStack Query, nol atom.

Kesehatan test suite

Dijalankan penuh sebagai bagian audit ini.

Dua kegagalan backend keduanya environmental, bukan cacat produk — dan keduanya sudah ada sebelum audit ini (angka yang sama tercatat di commit dd783691):

Keduanya layak diperbaiki sebagai kebersihan test (isolasi env + mock servis), tapi tidak memblokir apa pun.

⚠️ Jangan menjalankan dua suite backend bersamaan. Saat suite penuh berjalan, run verifikator paralel menghasilkan 24 pass / 4 fail; dijalankan sendirian, 28 pass / 0 fail tiga kali berturut-turut. Test berbagi satu database, jadi eksekusi paralel saling menimpa — kegagalan seperti itu palsu.

Cek silang — tes manual vs audit kode

Tiga item bertanda [x] di checklist Anda berbenturan dengan kode.

K1 · "Checklist tidak menampilkan Surat Domisili & Surat Pernyataan"

Yang Anda lihat benar, tapi alasannya bukan penghapusan — DocumentChecklist membuang semua docType non-identitas sebelum render (document-checklist.tsx:22-54). Baris checklistnya tetap ada di DB dengan required: true. Setelah revert, ini berbalik jadi cacat → B3.

K2 · "Akses /pendirian/:id/extraction dengan ID tidak valid — error handling jelas"

Audit kode menghasilkan FAIL (B2). Jalurnya sudah dirinci di atas — tidak ada cabang isError yang bisa dieksekusi.

Perlu konfirmasi: kalau yang terlihat spinner tak berhenti, itu justru B2. Kalau Anda melihat pesan error nyata, ada jalur yang belum saya temukan dan perlu saya telusuri lagi.

K3 · "Approve per section berfungsi" — ditutup

Dicatat PASS dari tes manual. Untuk arsip: SectionApprovalBar tidak dirender halaman PT Pendirian (hanya Perubahan/Akuisisi/Perbaikan), dan gate submit-nya adalah konfirmasi per-field + nol FAIL belum di-override. Beda penamaan, bukan beda fungsi.

Konfirmasi — tes manual cocok dengan kode

Sisa item yang hanya bisa ditutup dengan tes manual (4)

Tinggal empat, dan semuanya butuh bahan atau mata manusia — bukan sesuatu yang bisa dibuktikan dari kode:

Yang paling disarankan didahulukan: simulasi flow verifikator di UI — satu-satunya tahap yang belum pernah disentuh, dan punya perilaku mengejutkan (mengembalikan berkas menghapus semua override validasi).

Catatan lingkungan

Audit ini dikerjakan terhadap dev_5 (dd783691). Kalau tes manual Anda dijalankan di worktree lain, sebagian hasil bisa berbeda — dev_6 misalnya tertinggal tiga commit: fix highlight preview (4b42996b), fix Surat Pernyataan Setor yang mengganjal finalize (e4e2de0d), dan fix debug toggle finalize (dd783691).

Pasangan dev_5 yang benar: frontend :47031 → backend :47015 (vite --strictPort, VITE_API_PROXY_TARGET=http://localhost:47015 — terverifikasi).