Complete ADR Files

docs/decisions/ADR-001-monorepo.md

@@ -0,0 +1,50 @@
+# ADR-001: Monorepo Structure
+
+## Status
+
+Accepted
+
+## Date
+
+2026-06-05
+
+## Context
+
+QueueNova Health dikerjakan oleh tim 2 developer dengan pembagian frontend dan backend.
+Kami membutuhkan strategi manajemen repository yang memungkinkan:
+
+- Koordinasi perubahan lintas frontend dan backend dalam satu PR jika diperlukan
+- Satu pipeline CI yang dapat memverifikasi keseluruhan sistem
+- Kemudahan onboarding karena semua kode ada di satu tempat
+- Konsistensi dokumentasi, Docker, dan konfigurasi GitHub Actions
+
+Alternatif yang dipertimbangkan adalah polyrepo (dua repository terpisah untuk frontend dan backend).
+
+## Decision
+
+Kami menggunakan **monorepo** dengan struktur:
+project/
+├── .github/
+├── backend/
+├── infrastructure/
+├── docs/
+├── frontend/
+├── README.md
+└── docker-compose.yml
+Setiap bagian memiliki scope yang jelas dan tidak saling mengintervensi,
+namun tetap dalam satu repository untuk kemudahan koordinasi.
+
+## Consequences
+
+### Positif
+
+- Satu repository untuk di-clone, satu CI pipeline untuk dikelola
+- Perubahan yang membutuhkan update frontend dan backend bisa masuk dalam satu PR
+- Dokumentasi dan keputusan arsitektur terpusat di `docs/`
+- Docker Compose root dapat mengorkestrasikan semua service sekaligus
+
+### Negatif
+
+- CI pipeline harus didesain dengan hati-hati agar job frontend dan backend tidak saling memblokir secara tidak perlu
+- Akses kontrol per-folder tidak bisa dilakukan di level repository (hanya lewat konvensi tim)
+- Ukuran repository akan lebih besar seiring waktu karena semua artifact ada di satu tempat

docs/decisions/ADR-002-react-vite.md

@@ -0,0 +1,46 @@
+# ADR-002: React + Vite Frontend
+
+## Status
+
+Accepted
+
+## Date
+
+2026-06-05
+
+## Context
+
+QueueNova Health membutuhkan frontend yang mampu mendukung pengembangan antarmuka pengguna secara cepat dan maintainable oleh tim yang terdiri dari 2 developer.
+
+Kebutuhan frontend meliputi:
+
+- Pengembangan SPA (Single Page Application) dengan pengalaman pengguna yang responsif
+- Dukungan ekosistem library yang luas untuk kebutuhan UI, routing, state management, dan integrasi API
+- Startup development server yang cepat untuk meningkatkan produktivitas pengembangan
+- Konfigurasi yang sederhana dan mudah dipahami oleh seluruh anggota tim
+- Dukungan TypeScript untuk meningkatkan maintainability dan type safety
+
+Alternatif yang dipertimbangkan adalah Vue + Vite.
+
+## Decision
+
+Kami menggunakan **React** sebagai framework frontend dan **Vite** sebagai build tool dengan **TypeScript** sebagai bahasa utama pengembangan.
+
+Arsitektur frontend akan berupa Single Page Application (SPA) yang berkomunikasi dengan backend melalui REST API.
+
+## Consequences
+
+### Positif
+
+- Tim telah familiar dengan React sehingga onboarding dan pengembangan lebih cepat
+- Ekosistem React menyediakan banyak library pendukung yang matang
+- Vite memberikan startup development server yang cepat dan build yang efisien
+- TypeScript membantu mengurangi kesalahan pada tahap development
+- Struktur SPA sederhana dan mudah diintegrasikan dengan backend Laravel API
+
+### Negatif
+
+- SEO tidak sebaik pendekatan SSR karena aplikasi menggunakan SPA
+- Pengelolaan state dapat menjadi kompleks seiring bertambahnya fitur
+- Bundle frontend berpotensi bertambah besar jika dependensi tidak dikelola dengan baik
+- React memberikan fleksibilitas tinggi sehingga diperlukan konvensi tim yang konsisten

docs/decisions/ADR-003-laravel-api.md

@@ -0,0 +1,48 @@
+# ADR-003: Laravel REST API Backend
+
+## Status
+
+Accepted
+
+## Date
+
+2026-06-05
+
+## Context
+
+QueueNova Health membutuhkan backend yang dapat mendukung pengembangan fitur sistem antrean dan appointment booking dengan cepat serta mudah dipelihara oleh tim kecil.
+
+Kebutuhan backend meliputi:
+
+- Penyediaan REST API untuk frontend
+- Struktur aplikasi yang produktif dan mudah dikembangkan
+- Dukungan fitur bawaan yang mengurangi kebutuhan implementasi manual
+- Kemampuan menjalankan proses asynchronous menggunakan queue
+- Pemisahan frontend dan backend secara jelas meskipun berada dalam satu repository
+
+Alternatif yang dipertimbangkan adalah NestJS.
+
+## Decision
+
+Kami menggunakan **Laravel** sebagai framework backend dan mengimplementasikan komunikasi melalui **REST API**.
+
+Frontend dan backend dipisahkan secara arsitektural (decoupled architecture), namun tetap berada dalam satu monorepo untuk memudahkan koordinasi pengembangan.
+
+Fitur queue Laravel akan digunakan untuk mendukung kebutuhan proses asynchronous apabila diperlukan pada pengembangan berikutnya.
+
+## Consequences
+
+### Positif
+
+- Tim telah menguasai Laravel sehingga pengembangan lebih efisien
+- Banyak fitur bawaan tersedia tanpa memerlukan library tambahan
+- Struktur proyek dan praktik pengembangan Laravel sudah matang
+- Queue system tersedia dan siap digunakan untuk kebutuhan background processing
+- REST API mudah diintegrasikan dengan frontend React
+
+### Negatif
+
+- Konsumsi resource dapat lebih tinggi dibanding framework yang lebih minimalis
+- Ketergantungan terhadap ekosistem Laravel cukup besar
+- Pemisahan frontend dan backend memerlukan pengelolaan kontrak API yang disiplin
+- Skalabilitas horizontal memerlukan perencanaan tambahan ketika sistem berkembang

docs/decisions/ADR-004-postgre.md

@@ -0,0 +1,48 @@
+# ADR-004: PostgreSQL Database
+
+## Status
+
+Accepted
+
+## Date
+
+2026-06-05
+
+## Context
+
+QueueNova Health membutuhkan database yang mampu menyimpan data relasional untuk sistem antrean dan appointment booking secara konsisten dan andal.
+
+Kebutuhan utama meliputi:
+
+- Penyimpanan data relasional yang terstruktur
+- Dukungan transaksi yang konsisten
+- Kemampuan mendukung kebutuhan reporting
+- Solusi open source yang dapat digunakan tanpa biaya lisensi
+- Kemudahan integrasi dengan Laravel
+
+Alternatif yang dipertimbangkan adalah MySQL.
+
+## Decision
+
+Kami menggunakan **PostgreSQL** sebagai database utama aplikasi.
+
+PostgreSQL dipilih karena bersifat open source, memiliki kepatuhan ACID yang kuat, serta mampu mendukung kebutuhan data relasional dan reporting yang menjadi fokus aplikasi.
+
+Pada tahap awal, sistem menggunakan satu instance database.
+
+## Consequences
+
+### Positif
+
+- Open source dan bebas biaya lisensi
+- Menyediakan implementasi ACID yang kuat untuk menjaga konsistensi data
+- Cocok untuk data relasional yang menjadi kebutuhan utama aplikasi
+- Mendukung kebutuhan reporting dengan baik
+- Integrasi dengan Laravel sudah matang dan stabil
+
+### Negatif
+
+- Membutuhkan pemahaman administrasi database yang lebih baik dibanding solusi yang lebih sederhana
+- Scaling database memerlukan perencanaan tambahan ketika beban meningkat
+- Operasional backup dan recovery tetap perlu dikelola secara disiplin
+- Satu instance database menjadi single point of failure apabila tidak disertai strategi redundansi