# Analisis Risiko Persisten dan Laten pada Modul `master_project`

Berdasarkan audit mendalam terhadap pola kode pada modul `master_project` (terutama pada file `MasterData.php`, `FollowUp.php`, `Create.php`, dan model-model terkait), saya menemukan beberapa risiko sistemik (laten maupun persisten) yang perlu menjadi perhatian utama untuk stabilitas jangka panjang.

## 1. Concurrency & Race Condition Tanpa Row Locking (Persisten)
Meskipun kita sudah memperbaiki `simpanTasklist` dan `simpanTasklistTambahan`, **hampir seluruh operasi tulis lainnya di dalam sistem tidak menggunakan mekanisme Row Locking**.
- **Temuan:** Terdapat lebih dari 48 pemanggilan `$this->db->trans_start()` di seluruh *controller* `master_project`, namun **hanya 2** yang memiliki proteksi `SELECT ... FOR UPDATE` (yakni yang baru saja kita tambahkan).
- **Risiko Laten:** Fitur krusial lainnya seperti `addData()` (penambahan komposisi, fase, atau tim pekerja), fitur *approval* di `FollowUp.php`, hingga mutasi `_shoppingCart.php` rentan mengalami *double entry* atau perhitungan ganda jika *user* melakukan *double click* atau ada *request* paralel. Tanpa *lock* di tingkat database, *database transaction* bawaan CI3 tidak akan menahan benturan *request* tersebut.

## 2. Technical Debt: Raw Query Tanpa Binding pada Indexing (Laten)
Sistem masih banyak menggunakan query manipulasi string secara langsung alih-alih menggunakan *Query Builder* atau *Query Binding*.
- **Temuan:** Ditemukan puluhan *raw query* seperti ini di `FollowUp.php` dan `Create.php`: 
  ```php
  $this->db->query("UPDATE transaksi SET indexing_main_values = '$arrBlob' WHERE id=$insertID");
  ```
- **Risiko:** Sesuai dengan aturan standar keamanan yang berlaku, hal ini merupakan *technical debt*. Jika string JSON di dalam `$arrBlob` kebetulan mengandung karakter kutip tunggal (`'`) yang tidak di-*escape* dengan benar, query akan *crash* (Syntax Error). Pada skenario terburuk, ini membuka pintu kelemahan SQL Injection.

## 3. Isolasi Sesi Terbuka / Cross-Pollination Data (Laten)
Penggunaan sesi (`$_SESSION`) untuk menyimpan data form yang sangat besar (seperti `$_SESSION["NEW"]` pada `MasterData::addData()`).
- **Risiko:** Menyimpan *state* data form ke dalam variabel *Session Global* memiliki risiko "bocornya" konteks. Jika seorang *user* secara bersamaan membuka dua Tab Browser untuk mengerjakan dua SPK/Proyek yang berbeda, isi dari *session* tersebut akan saling tertimpa (Cross-Pollination). Akibatnya, material dari Proyek A berisiko tersimpan ke Proyek B tanpa disadari.

## 4. Ketidakkonsistenan Referensi Data Progress vs Penugasan (Persisten)
Kesalahan membaca tabel "Penugasan" vs "Progress QC" yang baru saja kita atasi pada `MdlProdukProject.php` memiliki potensi laten terjadi di modul pelaporan lainnya.
- **Risiko:** Karena struktur HMVC di CodeIgniter 3 memisahkan banyak model pelaporan (seperti `ActivityReport.php` atau fitur *Dashboard*), developer lain di masa lalu mungkin melakukan `JOIN` secara membabi-buta ke tabel `project_sub_tasklist_komposisi` (Tabel Progress) untuk menghitung RAB atau nilai awal penugasan. Perlu diadakan audit khusus pada menu laporan (Report) untuk memastikan sumber kebenaran (Source of Truth) material tidak tertukar lagi.

---
> [!IMPORTANT]
> **Rekomendasi Tindakan**
> 1. Secara perlahan mengadopsi standar *Row Locking* (seperti yang dilakukan pada SPK) ke fitur-fitur transaksi sensitif lainnya (seperti Approval / Follow Up).
> 2. Secara ketat mengganti pola `$this->db->query("... '$variabel' ...")` menjadi `$this->db->query("...", array($variabel))` pada fitur-fitur yang masih aktif dikembangkan.
> 3. Mempertimbangkan untuk menyimpan draf / state sementara menggunakan objek UI AJAX ketimbang mengandalkan `$_SESSION` global demi menghindari *cross-tab data leak*.