# MIKRO-FASE 5.3 — DISTRIBUSI HASIL KEPUTUSAN

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

Mikro-fase 5.2 selesai. Tiket dapat berstatus `DISETUJUI` atau `DITOLAK`.

## Tujuan Mikro-Fase

Menyempurnakan tampilan hasil keputusan bagi Pegawai, TU, dan Pimpinan serta menyiapkan antrean tiket disetujui untuk penetapan SLA.

## Dasar Perancangan Skripsi

TU menerima keputusan Pimpinan. Pegawai perlu memantau status dan notifikasi. Tiket disetujui menjadi dasar TU menetapkan SLA; tiket ditolak berhenti dengan catatan keputusan.

## Ruang Lingkup Implementasi

- Detail Pegawai menampilkan keputusan dan catatan yang boleh dilihat.
- Dashboard/antrean TU menampilkan tiket disetujui yang menunggu SLA.
- Dashboard TU dan Pimpinan menampilkan statistik keputusan nyata.
- Detail Pimpinan keputusan lama menjadi hanya-baca.
- Status ditolak memiliki penjelasan final.
- Siapkan link dari notifikasi ke detail yang tepat.

## Perubahan Database

Tidak membuat tabel baru. Tambahkan query dan presentasi data approvals.

## Route dan Hak Akses

Gunakan route detail yang sudah ada. Tambahkan antrean TU bila perlu:

```text
GET /tu/tiket/disetujui
```

Hanya TU. Route detail tetap mengikuti role dan ownership.

## Struktur Backend yang Diharapkan

- Query join approvals untuk detail.
- Status view mapper.
- Dashboard aggregation service diperbarui.
- Jangan membuat SLA pada mikro-fase ini.

## Antarmuka yang Diharapkan

- Panel keputusan dengan nama Pimpinan, hasil, catatan, dan waktu.
- Antrean “Menunggu SLA dan Penugasan” pada TU.
- Tiket ditolak menggunakan status final yang jelas, bukan tombol tindakan.

## Aturan Bisnis dan Keamanan

- Pegawai tidak dapat mengedit tiket disetujui/ditolak.
- Tiket ditolak tidak dapat masuk ke SLA.
- Catatan keputusan hanya ditampilkan kepada pihak berwenang.
- Jangan mengubah data approval.

## Dilarang pada Mikro-Fase Ini

- Penetapan SLA;
- penugasan;
- perubahan keputusan;
- pekerjaan Teknisi.

## Acceptance Criteria

- [ ] Pegawai melihat hasil keputusan.
- [ ] TU memiliki antrean tiket disetujui.
- [ ] Statistik dashboard diperbarui.
- [ ] Tiket ditolak bersifat final dan hanya-baca.
- [ ] Belum ada SLA atau assignment.

## Penutup

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