# MIKRO-FASE 9.1 — DASHBOARD OPERASIONAL BERBASIS DATA

Anda bertindak sebagai senior PHP developer dan mengerjakan repository yang sudah tersedia.

## Konteks Aplikasi yang Wajib Dipahami

Aplikasi ini merupakan sistem web internal untuk mendigitalisasi proses usulan dan penanganan perbaikan inventaris di Perwakilan BKKBN Provinsi Sumatera Utara.

Identitas penelitian:

- Peneliti: Renanda Nauval
- NIM: 2112000080
- Program Studi: Informatika
- Judul: Rancang Bangun Aplikasi Usulan Perbaikan Inventaris Kementerian Kependudukan dan Pembangunan Keluarga/Perwakilan BKKBN Provinsi Sumatera Utara

Alur bisnis utama:

```text
Pegawai
→ Bagian Tata Usaha memeriksa tiket
→ Pimpinan menyetujui atau menolak
→ Bagian Tata Usaha menetapkan SLA dan menugaskan teknisi
→ Teknisi mengerjakan dan mengunggah bukti penyelesaian
→ Tiket selesai dan seluruh riwayat tersimpan
```

Empat role resmi sistem:

```text
PEGAWAI
TU
PIMPINAN
TEKNISI
```

Jangan membuat role `ADMIN` karena role tersebut tidak terdapat pada perancangan skripsi.

Fitur utama yang harus tercapai secara bertahap:

- autentikasi dan profil;
- tiket perbaikan oleh Pegawai;
- foto kerusakan wajib;
- pemeriksaan dan permintaan revisi oleh TU;
- pengajuan tiket valid kepada Pimpinan;
- persetujuan atau penolakan oleh Pimpinan;
- penetapan SLA dan penugasan Teknisi oleh TU;
- progres dan tindakan perbaikan oleh Teknisi;
- foto bukti penyelesaian wajib;
- notifikasi otomatis pada perubahan tahap;
- pemantauan SLA dan keterlambatan;
- laporan, riwayat aset, dan audit trail.

## Kondisi Teknis Proyek

Gunakan proyek yang sudah tersedia dengan folder lokal:

```text
bkkbn_eticketing
```

URL pengembangan:

```text
http://localhost/bkkbn_eticketing/public
```

Teknologi wajib:

- PHP Native 8.2 atau lebih baru;
- MySQL atau MariaDB;
- PDO;
- Composer dan autoload PSR-4;
- HTML5, CSS3, dan JavaScript sederhana;
- Bootstrap 5 melalui CDN;
- Apache melalui XAMPP atau Laragon;
- arsitektur MVC sederhana.

Jangan menggunakan:

- Laravel;
- CodeIgniter;
- Symfony;
- Node.js;
- npm;
- framework frontend;
- proses build frontend.

Arsitektur yang harus dipertahankan:

```text
Request
→ public/index.php
→ Router
→ Middleware
→ Controller
→ Service
→ Model/Repository
→ PDO/MySQL
```

Controller harus tipis. Aturan bisnis, transaksi, perubahan status, notifikasi, dan audit ditempatkan pada service. View tidak boleh menjalankan query.

## Sistem Desain UI

Pertahankan sistem desain yang sudah dibuat pada Fase 1:

- warna utama hijau tua;
- permukaan putih;
- kanvas abu-abu muda;
- sidebar responsif;
- topbar;
- kartu putih dengan radius lembut;
- status selalu memakai teks, tidak hanya warna;
- tampilan mendukung lebar minimum 360 piksel.

Baca dan patuhi:

```text
docs/09-UI-DESIGN-SYSTEM.md
```

Jangan mengganti identitas visual utama tanpa instruksi eksplisit.

## Dokumen yang Harus Dibaca Sebelum Coding

Baca terlebih dahulu:

```text
AGENTS.md
docs/00-PROJECT-CONTEXT.md
docs/01-PRD-LENGKAP.md
docs/02-ARCHITECTURE.md
docs/05-CODING-STANDARDS.md
docs/06-STATUS-PROJECT.md
docs/09-UI-DESIGN-SYSTEM.md
docs/12-APPLICATION-CONTEXT-FOR-AGENTS.md
docs/13-SKRIPSI-ALIGNMENT-MATRIX.md
docs/14-MICRO-PHASE-ROADMAP.md
docs/18-DATABASE-CONSISTENCY-RULES.md
docs/19-ROUTE-AND-ROLE-MATRIX.md
```

Periksa juga implementasi fase sebelumnya. Jangan mengasumsikan sebuah class, helper, service, route, atau tabel tersedia sebelum memeriksanya.

## Aturan Eksekusi Global

1. Kerjakan hanya mikro-fase yang tertulis dalam prompt ini.
2. Jangan melanjutkan ke mikro-fase berikutnya.
3. Jangan membuat fitur yang belum diminta.
4. Jangan melakukan refactor besar terhadap fondasi yang sudah stabil.
5. Jangan menghapus file lama tanpa alasan yang terdokumentasi.
6. Jangan mengganti nama tabel atau kolom inti skripsi tanpa keputusan eksplisit.
7. Gunakan prepared statement dan transaksi database untuk perubahan multi-tabel.
8. Terapkan middleware role dan pemeriksaan kepemilikan data pada backend.
9. Semua output dinamis pada view harus di-escape.
10. Semua form perubahan data harus menggunakan CSRF.
11. File unggahan harus disimpan di luar direktori publik dan diakses melalui controller berizin.
12. Setiap perubahan status tiket harus dicatat pada `ticket_logs`.
13. Setiap tahap yang menurut skripsi menghasilkan notifikasi harus membuat record notifikasi.
14. Jangan membuat testing otomatis dan jangan menjalankan rangkaian testing besar pada mikro-fase ini.
15. Lakukan hanya pemeriksaan seperlunya saat coding, tanpa laporan testing panjang.
16. Setelah selesai, perbarui `docs/06-STATUS-PROJECT.md` dan isi ringkasan handoff.

## Format Laporan Akhir Agent

Berikan laporan singkat dengan struktur:

### Mikro-Fase Selesai

Tuliskan nomor dan nama mikro-fase.

### File Dibuat

Tuliskan file baru.

### File Diubah

Tuliskan file lama yang diubah.

### Perubahan Database

Tuliskan migration, tabel, kolom, indeks, dan data awal yang ditambahkan.

### Route dan Hak Akses

Tuliskan route baru serta role yang dapat mengaksesnya.

### Keputusan Teknis

Tuliskan keputusan yang dapat memengaruhi agent berikutnya.

### Belum Dikerjakan

Tegaskan fitur fase berikutnya yang sengaja belum dibuat.

Jangan melanjutkan ke prompt berikutnya.

## Prasyarat

Fase 3–8 selesai. Seluruh alur tiket utama dan notifikasi tersedia.

## Tujuan Mikro-Fase

Mengganti seluruh placeholder dashboard dengan statistik dan daftar tindakan nyata sesuai role.

## Dasar Perancangan Skripsi

Rancangan dashboard Pegawai, TU, Pimpinan, dan Teknisi memiliki ringkasan berbeda berdasarkan tanggung jawab masing-masing.

## Ruang Lingkup Implementasi

- Audit empat dashboard.
- Hapus placeholder dan angka statis.
- Pegawai: status tiket sendiri dan tiket terbaru.
- TU: antrean pemeriksaan, menunggu keputusan, menunggu SLA, mendekati, terlambat.
- Pimpinan: menunggu keputusan, setuju, tolak, ringkasan penyelesaian.
- Teknisi: tugas baru, dikerjakan, mendekati, terlambat, selesai.
- Tambahkan daftar tindakan prioritas dan tautan modul.

## Perubahan Database

Tidak membuat tabel baru. Optimalkan query agregasi dan indeks bila diperlukan. Hindari melakukan banyak query per kartu bila dapat digabung dengan aman.

## Route dan Hak Akses

Gunakan route dashboard masing-masing. Semua query dibatasi role dan lingkup data.

## Struktur Backend yang Diharapkan

- DashboardService per role atau satu service modular.
- DTO/array view data yang jelas.
- Cache ringan hanya jika sudah ada fondasi dan memang diperlukan; jangan menambah kompleksitas tanpa alasan.

## Antarmuka yang Diharapkan

- Ikuti referensi dashboard hijau.
- Kartu angka, panel antrean, dan ringkasan SLA.
- Jangan menyalin isi data dari gambar referensi.
- Empty state tetap rapi.
- Mobile satu kolom bila diperlukan.

## Aturan Bisnis dan Keamanan

- Tidak ada data dummy.
- Pegawai hanya data miliknya.
- Teknisi hanya assignment miliknya.
- Statistik TU/Pimpinan sesuai akses.
- Angka harus berasal dari query konsisten.

## Dilarang pada Mikro-Fase Ini

- Laporan ekspor;
- chart kompleks dengan library baru;
- perubahan alur bisnis;
- AI analytics.

## Acceptance Criteria

- [ ] Empat dashboard menggunakan data nyata.
- [ ] Tidak ada angka dummy.
- [ ] Setiap kartu memiliki tautan relevan.
- [ ] Scope data aman.
- [ ] UI responsif dan sesuai sistem desain.

## Penutup

Perbarui status proyek dan berikan laporan akhir sesuai format global. Berhenti setelah mikro-fase ini selesai.
