# Kajian & Analisis Perancangan Poultry Management System

Dokumen ini merangkum hasil kajian terhadap berkas perencanaan yang tersedia (`poultrysystem-project.md`, `database+seed.sql`, dan Milestone Plans) serta memberikan rekomendasi perbaikan sebelum tahap implementasi dimulai.

## 1. Temuan Utama & Inkosistensi

Berdasarkan analisis dokumen, terdapat beberapa hal kritikal yang perlu diselaraskan:

### 1.1 Inkosistensi Tech Stack
- **Dokumen Utama (`poultrysystem-project.md`)**: Menyebutkan penggunaan **PHP 8.x Native**.
- **Milestone Plans (`implementation_plan-milestone-x.md`)**: Mengacu pada struktur **Laravel** (penggunaan `migrations`, `seeders`, `controllers`, dan `routes/api.php`).
- **Rekomendasi**: Mengingat kebutuhan sistem yang kompleks (JWT, RBAC, PWA, IoT, Financial Costing), **sangat disarankan menggunakan Laravel**. PHP Native akan meningkatkan beban pengembangan dan risiko keamanan/skalabilitas.

### 1.2 Kesenjangan Skema Database (Gap Analysis)
Terdapat perbedaan antara desain di dokumen (`3. Desain Skema Database`) dengan implementasi di `database+seed.sql`:

| Komponen | Status di Dokumen | Status di SQL | Analisis/Rekomendasi |
| :--- | :--- | :--- | :--- |
| **Farms (Farm/Blok)** | Ada | **Tidak Ada** | Perlu ditambahkan untuk mendukung multi-lokasi. |
| **Warehouses** | Ada | **Tidak Ada** | Penting untuk manajemen stok per kandang vs gudang pusat. |
| **IoT Sensor Logs** | Ada | **Tidak Ada** | Harus ada untuk menyimpan data stream ESP32/IoT. |
| **Financial Ledgers** | Ada | **Tidak Ada** | Diperlukan untuk perhitungan HPP & analisis laba-rugi per batch. |
| **Inventory** | Logistik Multi-Gudang | Stok Tunggal | Perlu diubah menjadi struktur `inventory_stocks` (per gudang) & `inventory_movements`. |

## 2. Usulan Perbaikan & Optimalisasi

### 2.1 Standardisasi Tabel Referensi (`ref_codes`)
Implementasi `ref_codes` di SQL sudah sangat baik. Namun, ada beberapa tabel yang masih menggunakan nama manual seperti `roles`.
- **Saran**: Tetap gunakan `ref_codes` untuk kategori universal, namun untuk entitas yang memiliki relasi kompleks (seperti `roles` dengan permissions), biarkan di tabel terpisah namun dengan pola penamaan yang konsisten.

### 2.2 Arsitektur IoT & Skalabilitas
- Karena data sensor (`sensor_logs`) akan sangat besar (ribuan data per hari), tabel ini harus dirancang untuk performa tinggi.
- **Saran**: Gunakan database terpisah untuk log (jika memungkinkan) atau implementasikan **Table Partitioning** di MySQL berdasarkan bulan/tahun di tabel `sensor_logs`.

### 2.3 Mekanisme Sinkronisasi PWA (Offline-First)
- Dokumen menyebutkan `Service Worker` & `IndexedDB`.
- **Saran**: Endpoint API harus mendukung mekanisme `Last-Modified` atau `ETag` dan penanganan konflik data saat sinkronisasi (misal: dua pekerja menginput data di kandang yang sama saat offline).

### 2.4 Integrasi Finansial (HPP Dinamis)
- Perhitungan HPP (Harga Pokok Penjualan) per Batch seringkali sulit jika harga pakan berubah-ubah.
- **Saran**: Gunakan metode **Moving Average** atau **FIFO** pada `inventory_movements` untuk mencatat harga modal barang pada saat mutasi ke kandang.

## 3. Rencana Aksi Segera (Action Plan)

1. **Konfirmasi Framework**: Memastikan apakah menggunakan **Laravel** (sesuai Milestone) atau **Native PHP**.
2. **Update Database Schema**: Memperbarui `database+seed.sql` (atau membuat Migrasi Laravel) untuk mencakup tabel yang hilang (`farms`, `warehouses`, `sensor_logs`, `financial_ledgers`).
3. **Penyelarasan Milestone**: Menyesuaikan milestone agar mencakup fase setup arsitektur PWA dan IoT di awal (prototyping).

---

> [!IMPORTANT]
> **Keputusan desain yang paling mendesak adalah pemilihan Framework.** 
> Jika kita menggunakan Laravel, saya akan segera mengonversi `database+seed.sql` menjadi Laravel Migrations untuk mempermudah pengerjaan Milestone selanjutnya.

> [!QUESTION]
> Apakah Anda setuju jika kita menggunakan **Laravel** sebagai basis framework utama untuk mendukung skalabilitas dan fitur-fitur modern seperti yang direncanakan?