Roadmap Implementasi

Arsip perencanaan awal. Beberapa item di bawah (misalnya Drizzle/PostgreSQL) tidak mencerminkan implementasi Convex saat ini dan bukan instruksi setup. Lihat arsitektur, ADR, dan UAT untuk kondisi sekarang.

Cara memakai roadmap

• Satu item idealnya selesai dalam satu pull request kecil.
• Kerjakan item hanya jika seluruh dependensinya sudah selesai.
• Owner adalah penanggung jawab utama, bukan satu-satunya orang yang boleh membantu.
• Reviewer mengikuti matriks di TEAM-WORK.md.
• Jangan menggabungkan perubahan database, API, dan beberapa halaman besar dalam satu PR.

Urutan delivery

flowchart LR
    D[Dokumentasi] --> C[Contracts dan validasi]
    C --> DB[Database foundation]
    DB --> F[Facility vertical slice]
    DB --> A[Auth dan session]
    F --> R[Reservation workflow]
    A --> R
    F --> P[Report workflow]
    A --> P
    R --> S[Staff dan admin workflow]
    P --> S
    S --> X[Analytics, export, hardening]

Alur tersebut sengaja membuat fasilitas sebagai vertical slice pertama. Tim dapat belajar pola schema → service → Route Handler → UI pada domain yang paling sederhana sebelum mengerjakan autentikasi dan workflow transaksi.

Milestone 0 — Fondasi bersama

Tujuan: semua anggota memiliki bahasa domain, aturan validasi, dan lingkungan pengembangan yang sama.

Exit criteria:

• Kontrak dasar dapat diimpor dari server maupun komponen client.
• Database lokal dapat dinyalakan dan migration kosong dapat dijalankan.
• Ketiga shell tidak mengandung data palsu yang menyerupai fitur selesai.

Milestone 1 — Fasilitas read-only

Tujuan: menghasilkan vertical slice pertama dari database sampai halaman publik.

Exit criteria:

• Pengunjung dapat melihat fasilitas nyata dari database tanpa login.
• UI tidak menampilkan detail pemohon atau tujuan reservasi.
• API dan halaman memiliki empty/error state yang dapat diuji.

Milestone 2 — Autentikasi dan otorisasi

Tujuan: menyediakan identitas pengguna dan pembatasan route berdasarkan role.

Exit criteria:

• Registrasi, login, logout, dan session persistence bekerja.
• Route user, staff, dan admin memiliki guard server-side.
• Password tidak pernah disimpan atau dikirim kembali sebagai response.

Milestone 3 — Reservasi

Tujuan: pengguna dapat membuat, melihat, dan membatalkan reservasi; petugas dapat memprosesnya.

Exit criteria:

• Aturan jam 07.00–20.00 WIB dan slot 30 menit dipastikan di server.
• Bentrok dicegah dalam transaksi, bukan hanya melalui UI.
• Pengguna hanya dapat membaca dan membatalkan reservasinya sendiri.

Milestone 4 — Laporan kerusakan

Tujuan: pengguna dapat membuat laporan dan petugas dapat menangani lifecycle laporan.

Exit criteria:

• Foto divalidasi di server dan disimpan melalui adapter yang disepakati.
• Fasilitas menjadi maintenance saat laporan ditangani dan kembali active setelah selesai.
• Pengguna hanya dapat melihat laporan miliknya sendiri.

Milestone 5 — Administrasi

Tujuan: admin dapat mengelola master fasilitas, akun, dan verifikasi registrasi.

Exit criteria:

• Hanya admin yang dapat memanggil endpoint administrasi.
• Fasilitas yang memiliki histori tidak dihapus secara destruktif.
• Semua aksi sensitif tervalidasi ulang di server.

Milestone 6 — Rekap, kualitas, dan penyerahan

Tujuan: menutup kebutuhan tugas kuliah dan menyiapkan demo yang stabil.

Jalur kerja paralel

Setelah fondasi untuk suatu milestone tersedia, UI dapat dikerjakan paralel dengan test dan endpoint berikutnya.

flowchart TB
    L[Tech Lead: contract, DB, API] --> H{Handoff contract stabil}
    H --> U2[Anggota 2: public UI]
    H --> U3[Anggota 3: auth dan user UI]
    H --> U4[Anggota 4: staff dan admin UI]
    U2 --> I[Integrasi dan review silang]
    U3 --> I
    U4 --> I
    L --> I

Handoff dianggap stabil ketika schema input/output sudah disepakati, contoh response tersedia, dan perubahan breaking diumumkan kepada seluruh tim.

Definition of Done per item

Sebuah item baru boleh ditandai selesai jika:

• scope item dan acceptance criteria terpenuhi;
• tidak mengambil ownership folder anggota lain tanpa koordinasi;
• loading, empty, error, dan permission state yang relevan ditangani;
• test ditambahkan sesuai risiko perubahan;
• pnpm format:check, pnpm lint, dan pnpm typecheck lulus;
• pnpm build lulus untuk perubahan yang memengaruhi runtime;
• dokumentasi/API contract diperbarui jika interface berubah;
• minimal satu anggota lain sudah melakukan review;
• commit message menjelaskan satu perubahan yang bermakna.

Pekerjaan berikutnya yang direkomendasikan

Fokus berikutnya adalah review silang, browser test untuk tiga role, accessibility/responsive pass, penyiapan akun demo final, lalu deployment production terkontrol.