# LENTERA Kab Bogor

**Layanan Integrasi Izin Riset dan Magang Kabupaten Bogor**

## ATURAN WAJIB - PRIORITAS TERTINGGI

### 0. Sumber Instruksi dan Aturan Markdown
Antigravity wajib bekerja dengan mengikuti tiga file Markdown yang disediakan untuk proyek ini sebagai sumber instruksi utama:

1. `konteks.md`
2. `plan.md`
3. `task.md`

Gunakan isi ketiga Markdown tersebut sebagai acuan utama dalam memahami konteks, batas scope, aturan, rencana, dan daftar pekerjaan proyek.

Jangan membuat file Markdown tambahan untuk dokumentasi implementasi, laporan implementasi, catatan progres, ringkasan perubahan, atau dokumen sejenis secara otomatis.

Secara khusus, jangan membuat file seperti:

- `IMPLEMENTATION.md`
- `IMPLEMENTATION_PLAN.md`
- `IMPLEMENTATION_NOTES.md`
- `PROGRESS.md`
- `CHANGELOG.md`
- `SUMMARY.md`
- `NOTES.md`
- atau Markdown baru sejenis

kecuali ada instruksi eksplisit dari pengguna untuk membuatnya.

Fokus pada pengerjaan proyek berdasarkan tiga Markdown utama tersebut. Jika ada konflik antaraturan, ikuti aturan yang berada pada bagian `ATURAN WAJIB - PRIORITAS TERTINGGI` dan jangan membuat asumsi atau dokumentasi tambahan tanpa instruksi.


### 1. Batas Scope Pengerjaan Saat Ini
Fokus hanya pada proses administrasi Kesbangpol sampai peserta resmi terdaftar/diterima.

Alur batas tahap saat ini:

Peserta Register
-> Lengkapi Profil
-> Pilih Dinas/OPD
-> Booking Slot
-> Pengajuan Layanan KKL / PKL / MAGANG
-> Verifikasi Kesbangpol
-> Disetujui / Ditolak
-> Jika disetujui, peserta resmi terdaftar dan statistik Dinas diperbarui

Setelah titik tersebut, hentikan pengerjaan sampai ada instruksi baru.

### 2. Modul Absensi Jangan Disentuh
Jangan:

- Mengubah modul absensi lama.
- Melakukan refactor absensi.
- Mengintegrasikan absensi dengan struktur baru.
- Membuat fitur absensi baru.
- Mengubah database, route, controller, UI, atau logic absensi.

Modul absensi akan dikerjakan pada tahap berikutnya setelah modul Kesbangpol dan pendaftaran selesai.

### 3. GitHub
Jangan melakukan tindakan Git secara otomatis.

Secara khusus, jangan:

- `git commit` tanpa instruksi eksplisit.
- `git push` tanpa instruksi eksplisit.
- Mengubah remote repository tanpa instruksi.

Semua perubahan tetap berada di environment lokal sampai ada perintah langsung dari pengguna.

### 4. Database
Jangan menggunakan tipe database `ENUM`.

Untuk role, status, dan data yang berpotensi berkembang, gunakan master/reference data atau tabel referensi yang fleksibel.

Contoh:

- roles
- permissions
- booking_statuses
- application_statuses
- internship_statuses
- master data lain yang relevan

Utamakan relasi dan foreign key ke tabel master apabila sesuai.

### 5. Aturan Umum Implementasi
- Jangan menghapus atau merombak fitur lama yang tidak termasuk scope tanpa alasan dan instruksi.
- Validasi proses penting harus dilakukan di backend.
- Gunakan database transaction dan locking yang sesuai untuk booking agar tidak terjadi overbooking.
- Booking bukan berarti peserta diterima.
- Booking aktif maksimal 1 jam dan slot harus dilepas ketika expired.
- Booking kelompok maksimal 3 peserta.
- Peserta tambahan wajib sudah memiliki akun dan dipilih dari data user terdaftar, bukan input nama bebas.
- Semua perubahan status penting harus dapat ditelusuri melalui riwayat/audit yang sesuai.


# Plan



### 7. Bahasa Status
Semua status yang ditampilkan kepada pengguna pada website harus menggunakan **Bahasa Indonesia**.

Jangan menampilkan status berbahasa Inggris seperti:

- `pending`
- `active`
- `waiting_approval`
- `approved`
- `rejected`
- `cancelled`
- `expired`

Gunakan padanan Bahasa Indonesia, misalnya:

- Menunggu
- Booking Aktif
- Menunggu Verifikasi
- Menunggu Persetujuan
- Disetujui
- Ditolak
- Dibatalkan
- Kedaluwarsa
- Terdaftar
- Aktif
- Akan Berakhir
- Selesai

Untuk data master status di database, kode internal boleh menggunakan identifier teknis yang konsisten apabila diperlukan oleh sistem, tetapi **label/nama status yang ditampilkan pada UI wajib Bahasa Indonesia**.

### 6. Aturan Desain dan Referensi Visual
Desain harus mengikuti arah visual formal-modern yang sebelumnya dipilih untuk LENTERA Kab Bogor.

Gunakan dua referensi utama:

1. **SMART Setjen DPR RI**
   - Menjadi referensi utama untuk struktur visual dashboard/landing page.
   - Gunakan pendekatan card yang rapi, formal, modern, berhierarki jelas, dan terasa seperti sistem pemerintahan/profesional.
   - Informasi utama harus mudah dipindai melalui card dan statistik, bukan tampilan yang terlalu ramai.

2. **E-Magang Kementerian Luar Negeri**
   - Menjadi referensi tambahan terutama untuk penyajian angka/statistik peserta.
   - Tampilkan jumlah peserta diterima sebagai informasi yang menonjol dan mudah dipahami.
   - Konsep angka/statistik tersebut diintegrasikan ke dalam card bergaya SMART Setjen DPR RI, bukan dibuat sebagai tampilan terpisah.

Arah desain LENTERA:
- Formal dan profesional.
- Modern tetapi tetap cocok untuk sistem Pemerintah Kabupaten Bogor.
- Card-based layout.
- Statistik peserta diterima, booking aktif, kuota, dan slot tersedia harus jelas.
- Hindari desain generik dashboard admin yang terlalu gelap, ramai, atau terasa seperti template SaaS.
- Jangan menyalin referensi secara identik; gunakan sebagai inspirasi struktur, hirarki visual, dan pengalaman pengguna.
- Pertahankan identitas LENTERA Kab Bogor pada seluruh desain.

Untuk modul layanan Kesbangpol, gunakan juga referensi halaman pelayanan surat yang telah dicatat sebelumnya:
- Hero formal dengan visual gedung/instansi.
- Navbar sederhana.
- Card "Jenis Pelayanan Surat Izin Rekomendasi".
- Salah satu layanan: "KKL / PKL / MAGANG (MAHASISWA)".
- Kontak, jam layanan, WhatsApp, alamat, Google Maps, dan footer formal.


## Batas Scope Pengerjaan Saat Ini

Kerjakan hanya modul dari pendaftaran peserta sampai peserta selesai diproses oleh Kesbangpol dan resmi terdaftar/diterima.

**Jangan menyentuh modul absensi yang sudah ada.** Jangan melakukan refactor, integrasi, perubahan database, route, controller, UI, atau logic absensi pada tahap ini.

Tunda juga pengembangan operasional lanjutan Dinas/OPD dan Bidang, termasuk penempatan internal, aktivitas harian, izin, monitoring kehadiran, dan dashboard operasional bidang.

Fokus tahap ini berakhir setelah:

1. Peserta berhasil registrasi dan melengkapi data.
2. Peserta memilih Dinas/OPD dan melakukan booking.
3. Booking kelompok maksimal 3 orang diproses dengan benar.
4. Booking memiliki masa berlaku maksimal 1 jam.
5. Peserta melanjutkan pengajuan layanan KKL / PKL / MAGANG (MAHASISWA).
6. Kesbangpol memverifikasi dan memutuskan pengajuan.
7. Jika disetujui, booking berubah menjadi diterima/resmi terdaftar dan statistik Dinas diperbarui.

Setelah itu jangan melanjutkan ke modul absensi atau operasional magang sampai ada instruksi baru.



## Tujuan
Mengembangkan sistem absensi magang sebelumnya menjadi Sistem Informasi Manajemen Magang Pemerintah Daerah yang mencakup booking kuota, pelayanan surat/rekomendasi Kesbangpol, penerimaan peserta, pengelolaan peserta per Dinas/OPD, bidang, dan absensi.

## Rencana Arsitektur

### Backend
Gunakan arsitektur backend yang sudah digunakan pada proyek sebelumnya dan pertahankan pola proyek yang sudah ada.

Database dapat tetap menggunakan MySQL atau dipersiapkan agar mudah menggunakan PostgreSQL. Jangan melakukan migrasi teknologi tanpa kebutuhan yang jelas.

### Konsep Otorisasi
Gunakan Role-Based Access Control dengan role:

- superadmin
- admin_kesbangpol
- admin_dinas
- admin_bidang
- participant

Superadmin secara implementasi digunakan oleh Diskominfo.

Hak akses harus berbasis permission dan tidak hanya mengandalkan nama role di frontend.

## Tahap 1: Analisis Struktur Sistem

Petakan entity utama:

- Users
- Roles
- Permissions
- OPDs/Dinas
- Bidangs
- Internship Quotas
- Internship Bookings
- Booking Participants
- Internship Applications
- Recommendation Letters / Documents
- Internship Periods
- Internship Placements
- Extensions
- Attendances
- Activities
- Audit Logs
- Notifications

Pastikan relasi mendukung riwayat, sehingga data penempatan lama tidak tertimpa.

## Tahap 2: Sistem Booking

Implementasikan alur:

1. User login.
2. User melengkapi profil.
3. User memilih Dinas/OPD.
4. Sistem menampilkan kuota dan statistik.
5. User memilih booking individu atau kelompok.
6. Maksimal total 3 peserta.
7. Peserta tambahan dipilih dari akun yang sudah terdaftar.
8. Sistem mengecek status seluruh peserta.
9. Sistem mengecek slot.
10. Jika tersedia, slot di-reserve.
11. Sistem membuat waktu expired maksimal 1 jam.
12. User melanjutkan pengajuan administrasi.

Status booking minimal:

- pending
- active
- waiting_approval
- approved
- rejected
- cancelled
- expired

Nama status dapat disesuaikan dengan struktur kode yang sudah ada, tetapi alurnya harus tetap jelas.

### Ketentuan Keamanan Booking

Proses reserve slot harus menggunakan transaksi database dan mekanisme locking yang sesuai.

Tujuan:

- Mencegah overbooking.
- Mencegah dua request mengamankan slot yang sama.
- Mencegah peserta masuk ke dua booking aktif yang bertentangan.

Booking expired harus melepaskan slot secara otomatis.

Gunakan mekanisme scheduler/queue/background job yang sesuai dengan arsitektur proyek.

## Tahap 3: Pengajuan Surat Kesbangpol

Setelah booking aktif, peserta diarahkan ke proses pelayanan:

KKL / PKL / MAGANG (MAHASISWA)

Pengajuan memuat data yang diperlukan sesuai proses administrasi.

Admin Kesbangpol dapat:

- Melihat pengajuan.
- Verifikasi.
- Menyetujui.
- Menolak.
- Meminta perbaikan jika diperlukan.
- Memantau masa magang.
- Memproses perpanjangan.

Setelah disetujui:

- Booking berubah ke status approved/accepted.
- Peserta masuk ke data Dinas/OPD.
- Statistik/card Dinas diperbarui.
- Peserta memperoleh tampilan sesuai status magangnya.

## Tahap 4: Pengelolaan Per Dinas

Admin Dinas hanya dapat mengakses data dalam Dinas/OPD-nya.

Fitur:

- Dashboard Dinas.
- Kuota.
- Peserta diterima.
- Peserta aktif.
- Bidang.
- Admin bidang.
- Penempatan.
- Monitoring.

## Tahap 5: Pengelolaan Bidang

Admin Bidang hanya melihat peserta yang menjadi tanggung jawab bidangnya.

Fitur:

- Daftar peserta.
- Kehadiran.
- Izin.
- Aktivitas.
- Monitoring.

## Tahap 6: Absensi

Kembangkan modul absensi dari sistem sebelumnya dan sesuaikan dengan struktur baru.

Absensi harus terhubung ke penempatan aktif peserta, bukan hanya langsung ke user.

Dengan demikian, riwayat magang dan absensi tetap konsisten apabila user memiliki lebih dari satu periode magang.

## Tahap 7: Dashboard Publik

Landing page formal.

Komponen:

1. Hero.
2. Statistik sistem.
3. Card Dinas/OPD.
4. Informasi kuota dan ketersediaan.
5. Status peserta diterima.
6. Jenis pelayanan surat rekomendasi.
7. Informasi kontak.
8. Jam layanan.
9. WhatsApp.
10. Lokasi/Google Maps.
11. Footer.

Card Dinas harus membedakan:

- Kuota total.
- Peserta diterima.
- Peserta aktif.
- Booking aktif.
- Slot tersedia.

## Tahap 8: Lifecycle Peserta

Alur utama:

Register
-> Lengkapi Profil
-> Pilih Dinas
-> Booking
-> Countdown Maksimal 1 Jam
-> Pengajuan Surat/Rekomendasi
-> Verifikasi Kesbangpol
-> Disetujui
-> Peserta Diterima
-> Penempatan/Status Aktif
-> Operasional Dinas/Bidang
-> Masa Magang Berakhir
-> Perpanjangan atau Selesai

Jangan menganggap booking sebagai peserta diterima.

## Tahap 9: Masa Magang dan Perpanjangan

Kesbangpol mengelola masa magang administratif maksimal 3 bulan.

Sistem harus:

- Menghitung tanggal mulai dan berakhir.
- Menandai masa yang akan berakhir.
- Mendukung pengajuan perpanjangan.
- Menyimpan riwayat perpanjangan.
- Tidak menghapus riwayat periode sebelumnya.

## Tahap 10: Superadmin Diskominfo

Buat area superadmin yang tidak perlu ditonjolkan pada navigasi pengguna biasa.

Akses:

- User management.
- Role dan permission.
- OPD/Dinas master data.
- Konfigurasi.
- Audit log.
- Monitoring.
- Maintenance.
- Backup/security configuration jika relevan.

Superadmin dapat melakukan kontrol global, tetapi tidak mengubah batas domain operasional Kesbangpol dan Dinas pada penggunaan normal.

## Prinsip Implementasi

- Jangan merombak fitur absensi lama yang masih relevan tanpa alasan.
- Bangun modul baru secara bertahap.
- Utamakan reusable components.
- Gunakan status yang konsisten antara database, backend, dan frontend.
- Validasi seluruh perubahan status di backend.
- Gunakan database transaction untuk proses booking dan approval yang memengaruhi kuota.
- Hindari duplikasi data.
- Simpan audit trail untuk perubahan penting.


## Aturan Git dan Deployment

Selama proses pengembangan:

- Jangan melakukan `git push` otomatis.
- Jangan membuat commit otomatis.
- Jangan mengubah remote repository tanpa instruksi.
- Semua perubahan tetap berada di lokal sampai ada instruksi eksplisit dari pengguna untuk melakukan commit atau push.

Jika perubahan siap, cukup informasikan perubahan yang telah dilakukan dan biarkan pengguna menentukan kapan akan melakukan commit/push.

## Strategi Master Data

Jangan menggunakan database `ENUM` untuk data yang berpotensi berubah atau bertambah.

Gunakan master/reference data untuk:

- Role.
- Permission.
- Status booking.
- Status pengajuan.
- Status magang.
- Status perpanjangan.
- Status lain yang relevan.

Utamakan relasi database dan foreign key ke tabel master dibanding ENUM agar sistem mudah dikembangkan tanpa perubahan struktur database yang tidak perlu.