think
16px
820px

Verifikator Improvement Wave — Laporan Selesai (2026-07-11)

TL;DR: keempat paket audit (P1 Integritas & Audit, P2 Satu Inbox, P3 Review UX Seragam, P5 Lanjutan) SELESAI dan live di staging. P4 di-drop sesuai keputusanmu (PP memang tanpa verifikator). Suite penuh: backend 2513/0, frontend 970/0. Audit asalnya: tidyup/2026-07-11-verifikator-audit.md.

P1 — Integritas & Audit (eed0d1ee)

Perbaikan Sebelum → Sesudah
override-validation (melewati gate FAIL — aksi paling sensitif, dipakai PT/PP/Apostille) Alasan opsional, tanpa audit, tanpa atribusi → alasan WAJIB + audit event VALIDATION_OVERRIDE_SET dengan requestId/IP/UA/principal + field actor/actorId
Keputusan Apostille (/decide) Nol jejak audit → event VERIFIKATOR_APPROVE/REJECT/REVISE per keputusan
REVISE lintas flow Hanya perbaikan yang me-reset override FAIL → perubahan-family DAN apostille kini ikut me-reset (paritas M7 — override basi tak bisa selamat dari loop revisi)
Keputusan Perbaikan Catatan opsional (APPROVE tanpa catatan sah), verifikatorUserId kolom mati, 5 panggilan audit tanpa konteks request → catatan wajib, atribusi hidup, semua lewat recordAuditEvent, + audit event keputusan
Role enforcement /api/apostille & /api/perbaikan (yang memuat decide) cuma AUTHEDguard requireVerifikatorRole in-handler di decide/advisory/unggah-spesimen — shadow-log sekarang, 401/403 nyata saat SECURITY_ENFORCE=on

Mekanik baru: recordAuditEvent menerima target {submissionIdDirect} (event ber-kunci submissionId untuk flow tanpa spine VerifikasiPerubahan) — satu query kini melihat SEMUA keputusan verifikator lintas flow.

P2 — Satu Inbox (44c303da)

  • Apostille/Legalisasi masuk GET /api/verifikator/submissions — satu antrean untuk 8 flow, dengan pemetaan status (IN_VERIFICATION→Menunggu, READY+REVISE→Perbaikan, COMPLETED→Selesai/Ditolak) + jalurPermohonan/slaDeadline per baris.
  • Fallback rekomendasi AI deterministik (dihitung dari ValidationResults) untuk flow tanpa advisory LLM — filter "Rekomendasi AI" dan sort "Risiko" kini adil untuk apostille/perbaikan/pembubaran/berakhirnya/peleburan (sebelumnya di-drop diam-diam / selalu di ekor).
  • Filter Flow baru (8 pilihan) + chip jenis flow per kartu + chip ⚡ Percepatan + SLA (merah saat lewat tenggat).
  • Queue polling 10 dtk (sebelumnya statis); badge jumlah pending di sidebar; copy salah-label ("Triage submisi Perubahan PT" padahal 7 flow) diperbaiki; judul halaman review kini type-aware (Akuisisi/Penggabungan tak lagi berjudul "Perubahan PT").
  • GET /api/apostille/list kini paginated + kontrol halaman di FE.

P3 — Review UX Seragam (e116a78e + bagian P1)

  • VerifikatorPdfPanel: halaman verifikator Pembubaran, Berakhirnya, dan Peleburan kini dua kolom DENGAN PDF sumber — sebelumnya verifikator menilai buta dari snapshot field tanpa bisa melihat scan.
  • Panel keputusan Perbaikan ditulis ulang ke bahasa visual bersama (tombol shadcn + ikon, catatan wajib untuk SEMUA keputusan) + DecisionReadbackBanner bersama (Disetujui/Ditolak/Dikembalikan + catatan + waktu).
  • Tombol kembali-ke-daftar di halaman perbaikan dan mode verifikator apostille (sebelumnya terdampar setelah memutus).

P5 — Lanjutan (e116a78e)

  • Keyboard triage di antrean: j/k (atau panah) memindah focus ring, Enter membuka — aman saat mengetik di kolom pencarian; baris petunjuk kecil di bawah daftar.
  • Advisory deterministik terpadu = fallback P2 di atas.
  • Sengaja dilewati, dengan alasan: (1) bulk-decide — APPROVE PT memicu email voting pemegang saham per submission dan tiap keputusan wajib bercatatan; persetujuan massal tidak aman untuk alur kepatuhan (keyboard-nav memberi kecepatan triage tanpa risiko itu); (2) identitas verifikator nyata — menunggu token issuance/SSO (semua decide masih verifikator-dev, tapi audit event kini juga merekam principal terverifikasi bila token hadir).

Deploy & verifikasi

ahu-ai-ocr:e116a78e live di Server 2 (:3520); gate konvensi (kedua suite penuh) hijau sebelum ship.

Verifikasi live di staging:
- GET /api/verifikator/submissions → envelope {items,total,page,pageSize}
- Submission apostille demo kudorong ke IN_VERIFICATION (bypass debug) supaya ada bahan smoke: ia langsung muncul di inbox terpadu sebagai APOSTILLE | MENUNGGU_VERIFIKATOR dengan aiRec FAIL hasil fallback deterministik (dia memang punya FAIL yang belum di-override) ✔ — siap kau pakai menguji alur keputusan verifikator apostille end-to-end (advisory + ringkasan + panel keputusan + banner read-back + audit event).
- GET /api/apostille/list paginated ✔; filter type=APOSTILLE ✔.
- Catatan: antrean PT kosong murni karena data — belum ada submission PT demo yang pernah di-submit ke verifikator (0 baris VerifikasiPerubahan/VerifikasiPerbaikan di DB staging); logika antrean terbukti lewat suite (verifikator-unified-inbox.test.ts dkk.).

Catatan lingkungan

VPN AHU (secure.ahu.go.id) putus lagi ±1 jam selama pengerjaan (kedua kalinya dalam 24 jam) — test yang menyentuh GPU/registry timeout selama jendela itu; pulih otomatis via vpn-monitor. Pola: sisi AHU tidak stabil; kalau berulang, patut dilaporkan ke pengelola VPN mereka.