Pembagian Tim RuangKampus

Prinsip pembagian

Project dimulai dari scaffold bersama. Placeholder route bukan fitur selesai. Feature owner bertanggung jawab terhadap pengalaman pengguna dan acceptance criteria; Tech Lead menjadi backend/integration partner untuk semua feature slice.

flowchart TB
  lead["Tech Lead<br/>server, data, integration"]
  member2["Anggota 2<br/>public and shared UI"]
  member3["Anggota 3<br/>auth and user portal"]
  member4["Anggota 4<br/>staff and admin portal"]

  lead <-->|contracts and API| member2
  lead <-->|contracts and API| member3
  lead <-->|contracts and API| member4
  member2 -. shared components .-> member3
  member2 -. shared components .-> member4

Ownership folder

Folder src/server dan component domain baru dibuat ketika task implementasi pertama membutuhkannya. Jangan membuat folder kosong hanya agar struktur terlihat lengkap.

Deliverable Tech Lead

Platform dan data

• Menetapkan shared Zod schema/type untuk role, status, facility, reservation, dan report.
• Menyiapkan schema/index Convex, environment, dan seed development.
• Membuat query/mutation Convex yang dipakai portal secara real-time.
• Menjaga validasi dan mutation atomik agar approval reservasi tidak mengalami race condition.

Auth dan API

• Mengintegrasikan Better Auth untuk registrasi, login, logout, session cookie, dan role guard.
• Menetapkan validasi server dan authorization setiap Convex function.
• Menyediakan endpoint yang dibutuhkan Anggota 2–4 sesuai urutan roadmap.
• Menentukan storage foto dan generator export bersama tim sebelum implementasi terkait dimulai.

Integration dan delivery

• Review contract antara UI dan backend sebelum kedua sisi dikerjakan.
• Menangani integrasi lintas route, CI, environment docs, migration verification, dan deployment.
• Menulis integration test untuk auth, authorization, conflict reservation, dan error response.
• Menjaga main selalu dapat di-install dan di-build.

Deliverable Anggota 2

• Menjaga design tokens dan primitives shadcn tetap konsisten serta accessible.
• Membuat public header/navigation, landing page, dan responsive shell.
• Implementasi daftar fasilitas, filter tipe/lokasi/kapasitas, empty state, loading state, dan error state.
• Menampilkan ketersediaan per slot tanpa membocorkan pemohon atau tujuan reservasi.
• Menyediakan komponen fasilitas reusable yang dapat dipakai portal lain setelah direview.
• Menguji public route pada desktop/mobile serta keyboard navigation.

Deliverable Anggota 3

• Membuat layout login/register dan pesan status verifikasi akun.
• Membuat portal navigation pengguna.
• Implementasi form reservasi, riwayat, detail, status, dan pembatalan milik sendiri.
• Implementasi form laporan dengan kategori, deskripsi, foto, riwayat, dan status.
• Menambahkan client-side validation memakai schema yang disepakati dengan Tech Lead.
• Menguji state form, validation feedback, success/error state, dan responsive behavior.

Deliverable Anggota 4

• Membuat dashboard dan navigation untuk petugas/admin.
• Implementasi antrean reservasi serta aksi approve/reject/cancel berikut dialog alasan.
• Implementasi antrean laporan, perubahan status, catatan resolusi, dan status perbaikan fasilitas.
• Implementasi UI pembuatan/verifikasi akun serta pengelolaan fasilitas oleh admin.
• Membuat tampilan rekap okupansi/kerusakan dan tombol export CSV dengan state yang jelas.
• Menguji table state, filter, confirmation dialog, permission state, dan responsive behavior.

Pembagian user story

Tech Lead adalah backend/integration partner pada semua baris.

Detail acceptance setiap user story terdapat di REQUIREMENTS.md.

Dependency antaranggota

flowchart LR
  contracts["Lead: contracts"] --> publicUI["A2: public facilities"]
  contracts --> userUI["A3: user forms"]
  contracts --> staffUI["A4: staff/admin tables"]
  database["Lead: database/services"] --> facilitiesAPI["Lead: facilities API"]
  facilitiesAPI --> publicUI
  authAPI["Lead: auth/session"] --> userUI
  authAPI --> staffUI
  publicUI --> reservations["A3 + Lead: reservations"]
  reservations --> approvals["A4 + Lead: approvals"]
  userUI --> reports["A3 + Lead: reports"]
  reports --> handling["A4 + Lead: report handling"]

Anggota boleh mulai UI menggunakan typed fixture setelah contract disetujui. Fixture harus berada dekat feature dan dihapus ketika API integration selesai; jangan membuat API palsu global.

Git workflow

Branch

Gunakan pola berikut:

docs/<topik>
chore/<infrastruktur>
feat/<domain>-<hasil-kecil>
fix/<domain>-<masalah>

Contoh: feat/public-facility-filter, feat/user-reservation-form, atau feat/staff-report-status.

Commit

Setiap anggota membuat minimal tiga commit bermakna selama project. Commit harus kecil, dapat dibuild, dan memiliki satu tujuan.

feat(facilities): add facility filter form
feat(reservations): validate thirty minute slots
test(reports): cover resolution status update
docs(team): update completed user stories

Pull request checklist

• Scope PR hanya satu hasil kecil yang jelas.
• Tidak ada file ownership lain yang diubah tanpa koordinasi.
• Loading, empty, error, dan success state ditangani bila relevan.
• Client dan server validation sesuai contract.
• Tidak ada data privat bocor ke public response/UI.
• pnpm check berhasil.
• Screenshot desktop/mobile dilampirkan untuk perubahan UI.
• Minimal satu reviewer menyetujui.

Review silang

flowchart LR
  lead[Tech Lead] -->|review integration| member2[Anggota 2]
  member2 -->|review UX| member3[Anggota 3]
  member3 -->|review flow| member4[Anggota 4]
  member4 -->|review operasional| lead

Reviewer memeriksa behavior dan acceptance criteria, bukan hanya tampilan. PR Tech Lead tetap harus direview anggota lain agar kontribusi tidak bergantung pada satu orang.