SOP Memori Tim AI

Memori yang acak-acakan merugikan dua hal:

1. Boros token. Untuk mencari satu hal, AI harus menyisir banyak teks. Makin banyak klien, makin boros, sampai jatah mingguan bisa habis dalam sehari.
2. Jawaban tidak relevan. Aturan lama & baru tercecer di beberapa tempat, sesi chat panjang di-compact, akhirnya jawaban ke prospek melenceng atau berputar-putar.

Prinsipnya sama dengan relational database: data ditata per tabel, punya indeks, jadi mencari tidak perlu menyisir semuanya. Menulis memang sedikit lebih repot (harus ditaruh di tempat yang benar); mencari jadi murah dan cepat.

Prinsip kedua: jangan mengandalkan ingatan sesi chat. Yang diandalkan adalah memori yang tertulis di tempatnya.

Untuk apa: supaya CS langsung tahu siapa yang sedang chat, tanpa membaca ulang semua obrolan lama. Kapan diisi: saat orang pertama kali chat (baris orang dibuat), tiap tahap berubah (orang_produk), dan tiap sesi ditutup (profil dirangkum ulang).

Contoh isi (contoh FIKTIF: Budi, kode org-0412):

Profil (versi berlaku): "Budi, jualan perlengkapan bayi di Bekasi. Member CNC sejak Agustus, paham dasar Meta Ads, suka penjelasan pakai angka. 12/10 tertarik TBA trial, keberatan: takut LP tidak sesuai brand. Janji: kirim foto produk 13/10. Gaya: santai, panggil 'Mas Budi'."

Profil = rangkuman UTUH yang ditulis ulang tiap sesi ditutup. Bukan tumpukan catatan per tanggal.

Untuk apa: semua yang perlu diketahui untuk MENJUAL & MELAYANI satu produk, baik produk sendiri (Labbaik, TBA, Magic) maupun produk klien (Otopia). Kapan diisi: saat produk mulai dijual, dan setiap ada keputusan baru soal produk dari Pak Adi/pemilik produk.

Contoh baris pk_harga (harga Otopia per UKURAN mobil, mengikuti pegangan Opi): otopia · anti-karat · medium · Rp2.250.000 · berlaku sejak … · berlaku. Pemetaan mobil → ukuran ada di pk_daftar jenis ukuran-mobil, contoh avanza → medium. Kalau harga beda per cabang, kolom lokasi diisi cabangnya.

Contoh baris pk_penjelasan:

Harga berubah → baris lama jadi usang, baris baru ditambah (slug sama). Tidak ada lagi harga di tiga tempat.

Untuk apa: supaya pembuat produk (Eko, Dika, atau AI lain di kemudian hari) bisa melanjutkan pekerjaan tanpa bertanya ulang. Dua berkas berpasangan di folder kode proyek: <PROYEK>_MAP.md dan <PROYEK>_BRAINSTORMING.md.

MAP = peta yang SUDAH dibangun, dibagi per modul (tampilan, database, pembayaran, dll.) dengan petunjuk "modul ini ada di file mana". Contoh potongan MAP Caang:

BRAINSTORMING = yang BARU direncanakan. Contoh: "Catat kode error Cloudflare saat publish gagal (usul Eko 12/10, menunggu izin)". Begitu dibangun: tulis di MAP, HAPUS dari brainstorming (tanpa tanda "done").

MAP hanya mencerminkan kode yang benar-benar ada. Kalau kode dan MAP berbeda, kode yang benar dan MAP diperbarui.

Untuk apa: karakter & aturan yang harus SELALU dipegang, otomatis termuat tiap sesi. Dua tingkat:

• Umum (semua staf). Contoh: "Gambar tanpa aurat; perempuan wajib jilbab syar'i." "Jangan janjikan seumur hidup." "Akui terus terang kalau tidak tahu." "Jangan baca berkas besar sekaligus." "Hal yang masih diskusi tidak dikerjakan sebelum Pak Adi bilang final."
• Per peran (pendek). Contoh untuk Ary: "Bukti transfer dilihat sendiri, diteruskan ke Pak Adi, aktivasi hanya sesudah 'valid'." Contoh untuk Opi: "Tanya teknis ke grup cabang, tag admin cabang."

Kalau CLAUDE.md mulai panjang, itu tanda ada isi yang seharusnya masuk PK, Akses & alat, atau papan tugas.

Untuk apa: "peta mesin": cara masuk, alat apa di mana, cara menyalakan ulang. Contoh isi:

• "PC 250: SSH lewat VPS port …; kunci di /root/.ssh/… (path saja, bukan isinya)."
• "Penjaga WA Ary mati → jalankan tunggu_pesan.sh sebagai proses latar; jangan reload tab WA."
• "Pasang kampanye Meta: resep langkah 1–12 …"

Sengaja berkas, bukan database: kalau database/servernya bermasalah, cara masuk & memperbaikinya harus tetap bisa dibaca. Password tidak pernah ditulis.

Untuk apa: tahu siapa sedang mengerjakan apa, dan tidak ada janji yang terlewat. Contoh baris:

Begitu selesai, status = selesai (tidak dihapus, tapi tidak tampil di daftar kerja).

Untuk apa: jejak kejadian kalau suatu saat perlu ditelusuri ("kapan pelanggan X dikirimi link reset?"). Contoh baris: 12/10 15:10 · Eko · caang · org-0099 · kirim ulang link Lupa password ke email pelanggan.

Hanya ditambah. Tidak pernah dibaca semua; dicari per tanggal/orang/produk.

Sesi dibuka per SATUAN KERJA, seperti cara Pak Adi membuka chat "Monyil 1, Monyil 2": satu masalah satu sesi.

Grup WA

• Grup = satu "ruang" dengan sesinya sendiri (kunci kode_grup), aturan buka/tutup sama dengan CS (diam 30 menit).
• Tiap pesan grup: skrip tahu SIAPA pengirimnya. Yang dimuat: profil grup (tujuan, aturan, konteks umum) + 20–30 obrolan terakhir grup + catatan grup si pengirim (grup_anggota + grup_topik yang aktif).
• Jawab dengan balas/kutip pesannya + sebut nama pengirim, sesuai kepentingan orang itu.
• Urusan pribadi (harga khusus, data akun, pembayaran) dipindah ke japri; catatannya masuk ke profil JAPRI orang itu.
• Catatan grup dan japri TERPISAH: profil_versi = khusus japri; grup_anggota + grup_topik = apa yang orang itu sampaikan di grup tertentu. Sesi GRUP tidak pernah memuat profil japri (supaya hal pribadi tidak bocor ke grup), paling hanya tahap produk dasar. Sesi JAPRI boleh membaca catatan grup orang itu dengan label "disampaikan di grup X (publik)".
• Saat sesi grup ditutup: yang diperbarui profil grup + grup_anggota + grup_topik tiap orang yang bicara. Saat sesi japri ditutup: yang diperbarui profil japri.
• Balasan yang ditunggu dari grup (mis. admin cabang Otopia menjawab pertanyaan untuk konsumen X): sesi grup memperbarui tugas "menunggu jawaban cabang (konsumen X)" → status siap, lalu penyambung membangunkan sesi konsumen X untuk menjawab konsumennya.

Alur CS (contoh Budi chat)

1. WA masuk → skrip penyambung (bridging) cari kode_orang dari nomor WA (belum ada = dibuat).
2. Cari di tabel sesi: sesi aktif milik orang itu yang terakhir aktif < 30 menit.
3. Ada → lanjutkan sesi itu. Tidak ada → buat sesi baru, diisi paket: profil terbaru + baris orang_produk + 10–15 chat terakhir (diambil dari WA) + bagian PK yang relevan.
4. Pesan beruntun dalam 30–60 detik digabung jadi satu panggilan.
5. Sebelum ditutup: sesi menulis profil BARU yang merangkum ulang secara utuh (profil lama + obrolan sesi ini), bukan ditempel di bawah profil lama. Tahap di orang_produk & janji FU (baris tugas) diperbarui.

• Yang berjaga adalah skrip biasa (0 token), dijalankan alarm sistem tiap menit: "ada tugas yang jatuh tempo menit ini?" Ringan sekali (±1–2 detik CPU per hari).
• Kalau ada → skrip menaruh pesan ke kotak masuk staf yang bersangkutan (jalur yang sama dengan WA masuk). Staf itu baru bangun & bekerja.
• Skrip yang sama menutup sesi CS yang sudah diam 30 menit (setelah profil dirangkum).
• Claude TIDAK mengecek jadwal sendiri, karena itu yang boros token.

Aturan menulis

1. Cari dulu tempatnya (produk + topik yang tepat), lalu UPDATE di situ (lihat kotak "Arti UPDATE" di bawah). Jangan menempel di ekor, jangan membuat berkas/dokumen baru.
2. Satu hal hanya ada di satu tempat. Kalau menemukan hal yang sama di dua tempat, laporkan ke Akbar.
3. Tulis saat itu juga, bukan menunggu akhir hari (tahan compact).
4. Tulis ringkas & pasti: kesimpulan, bukan salinan obrolan.
5. Selalu isi tanggal berlaku & siapa yang mengubah.
6. Hal yang masih diskusi dengan Pak Adi belum boleh ditulis sebagai aturan, diteruskan ke staf, atau dikerjakan sampai Pak Adi menyatakan final.

1. Ambil hanya yang dibutuhkan: satu orang, satu produk, satu topik, satu tugas. Pakai alat/kueri yang menyaring per kolom.
2. Jangan pernah menyisir semuanya (full scan) untuk mencari satu hal. Jangan membaca berkas besar sekaligus.
3. Pertanyaan sederhana dijawab langsung dari yang sudah ada; jangan menggali arsip untuk hal remeh.
4. Arsip log hanya dibuka untuk menelusuri kejadian tertentu, disaring per tanggal/orang/produk.
5. Kalau data tidak ketemu → laporkan (Akbar/Eko), jangan mengarang.

Prinsip: membaca selalu lewat alat baca (skrip #4), disaring dengan kunci tetap (kode_orang, kode_grup, slug_produk, slug_topik, slug_tugas), hanya baris yang berlaku/aktif, dan dibatasi jumlahnya. Tidak pernah "ambil seluruh tabel", dan tidak pernah membaca arsip/log tanpa saringan tanggal + orang/produk.

Tanda bahaya: kalau untuk menjawab satu pertanyaan kamu membaca lebih dari beberapa baris atau satu topik penuh yang tidak terkait, berhenti. Berarti alat/indeksnya kurang. Laporkan ke manajer supaya topiknya dipecah, jangan membaca semuanya.

Bukan aplikasi besar. Beberapa skrip Linux kecil di server uranus (dikerjakan Eko, diawasi Akbar):

Uji coba (keputusan Pak Adi 13/10 06:18): (1) PUTAR ULANG offline 20–30 percakapan lama nomor Ary ke sistem baru, bandingkan dengan jawaban Ary saat itu (nyambung, tidak mengulang, patuh aturan, token per balasan); (2) BAYANGAN: sistem baru mendengar chat masuk sungguhan & menyiapkan jawaban TANPA mengirim, dibandingkan harian dengan jawaban Ary; (3) sesudah itu LANGSUNG LIVE PENUH. Mutu jawaban dinilai MANAJER (Akbar), bukan Pak Adi.

Satu database untuk semua server

• Semua staf AI, baik di server uranus (Akbar, Ary, Dika, Eko) maupun mars (Opi), memakai SATU database yang sama. Tidak ada database terpisah per server atau per klien.
• Alasannya: satu sumber kebenaran (profil, PK, papan tugas tidak dobel/bertentangan), manajer bisa memantau semua tugas dari satu tempat, dan satu orang yang dilayani beberapa staf tetap tersambung.
• Letak yang diusulkan: mars, karena sudah masuk backup harian. (Kalau diputuskan di uranus, uranus wajib dimasukkan ke backup lebih dulu.) Uranus ↔ mars satu jaringan, jadi kecepatannya tidak terasa.
• Tiap staf punya akun database sendiri dengan hak terbatas. Contoh: Opi hanya baris proyek Otopia; hanya manajer (Akbar/Opi) yang bisa menulis PK. Tujuannya supaya tidak saling menimpa.

Sinkron "Akses & alat" dan CLAUDE.md antar server

1. Satu naskah induk (Akses & alat + CLAUDE.md umum + CLAUDE.md per peran) disimpan di satu tempat (usulan: mars) dalam repositori git. Git mencatat tiap perubahan (siapa, kapan, apa) dan bisa dikembalikan kalau keliru.
2. Git di sini bukan GitHub: cukup folder git di server induk itu sendiri; server lain menariknya lewat SSH jaringan rumah (akses sudah ada). Sengaja tidak di layanan luar karena isi Akses & alat sensitif.
3. Menyunting HANYA di induk.
4. Server lain (uranus, dll.) menyimpan salinan baca-saja. Skrip kecil menarik versi terbaru dari induk tiap 5 menit. Salinan dikunci supaya tidak ada yang menyunting di salinan.
5. Kalau induk/jaringan mati, salinan terakhir tetap ada di tiap server, jadi cara masuk dan cara memperbaiki tetap terbaca.
6. CLAUDE.md per peran hanya dipakai di server tempat peran itu bekerja (Ary di uranus, Opi di mars), tetapi tetap disunting di induk yang sama.

Skrip tambahan untuk ini masuk daftar skrip (bagian 11): penarik salinan tiap 5 menit + pengaturan akun database per staf.

1. "Satu baris berlaku per kunci" dipaksa database (unique index parsial WHERE status='berlaku'), bukan disiplin. Semua perubahan lewat SATU fungsi/alat yang menandai usang + menyisipkan versi baru dalam satu transaksi. Staf tidak pernah menulis SQL mentah.
2. Kolom kunci yang boleh kosong (mis. lokasi) diberi nilai default kosong ('') atau NULLS NOT DISTINCT, supaya unique index tetap menjaga.
3. Tabel identitas yang tidak berversi (orang, produk, grup, daftar topik PK) jadi sasaran foreign key; tabel isi berversi menunjuk ke sana. Salah ketik slug ditolak database.
4. WA sering hanya memberi ID …@lid tanpa nomor → kolom wa_lid + pemetaan saat nomor diketahui (penyambung WAJIB menyimpan nomor asli begitu terlihat dari kartu kontak/order); satu orang boleh punya beberapa nomor.
5. Sesi: CHECK num_nonnulls(kode_orang, kode_grup, slug_tugas) = 1; satu sesi aktif per orang/grup (unique parsial); penyambung mengunci per orang (advisory lock) saat membuka/menutup sesi supaya dua pesan bersamaan tidak membuat dua sesi; rangkuman profil gagal → sesi TIDAK ditutup.
6. Alarm memakai jatuh_tempo <= now() AND belum diingatkan (bukan "menit ini"), lalu ditandai sudah diingatkan. Kalau timer terlewat atau server restart, pengingat tidak hilang dan tidak terkirim dua kali. Waktu disimpan timestamptz, ditampilkan WIB. "Kotak masuk staf" = baris di events.jsonl staf itu (format sama dengan WA masuk).
7. Database di server lain: kalau server/jaringan mati, penyambung CS punya cadangan (pesan diantre + balasan penahan ke konsumen). Password database tiap staf disimpan di /root/.secrets (bukan di Akses & alat). Batas "Opi hanya Otopia" memakai Row-Level Security.
8. Sinkron git: Claude berjalan sebagai root, jadi kunci izin berkas tidak menahan. Skrip tarik = reset ke induk + ALARM kalau menemukan suntingan lokal di salinan. CLAUDE.md diletakkan tepat di path yang dibaca Claude Code.
9. Folder memory bawaan Claude Code (±90 berkas) bukan salah satu 7 model: isinya dipindah (feedback → CLAUDE.md, akses → model 5, proyek → PK/MAP) dan CLAUDE.md menegaskan sesi tidak menulis ke sana lagi.
10. Program latar (mis. pekerja unggah YouTube) yang perlu menulis lampiran "hasil" tanpa Claude memakai akun database program sendiri yang haknya terbatas pada tabel/jenis itu.
11. Alat baca punya perintah ringkas, mis. hasil <tugas> → hanya jumlah publik/tertahan; daftar lengkap hanya kalau diminta.
12. Pesan untuk staf pembuat (Eko/Dika) dari Akbar/Pak Adi masuk ke sesi umum staf itu (jenis topik), yang memilah: masuk tugas yang sudah ada, atau membuat tugas baru, lalu membuka/melanjutkan sesi tugasnya. Sesi umum = pemilah, sesi tugas = pengerjaan.
13. Alarm hanya membaca jatuh_tempo_berikutnya (tugas sekali jalan = salinan jatuh_tempo), satu sumber. Tugas berulang yang terlewat saat server mati: diingatkan SEKALI lalu loncat ke jadwal berikutnya (tidak menumpuk); sudah_diingatkan direset tiap kali jadwal maju; jadwal_ulang yang tidak dikenali ditolak alat saat ditulis.
14. tugas_induk ditutup MANUAL; saringan manajer menampilkan "induk yang semua anaknya selesai".
15. grup_topik punya penanda ada_janji + slug_tugas. Skrip TIDAK menandai usang selama ada_janji benar dan belum ada tugasnya; skrip membuat tugas "tinjau janji grup X" untuk manajer/CS grup itu. Topik diberi slug_topik pendek per grup (pakai ulang yang sama kalau cocok) supaya tidak dobel beda kata.
16. Isian baku lampiran.detail per jenis juga dipaksa CHECK di database (bukan hanya alat), karena program latar menulis tanpa alat. Pasangan (slug_produk+slug_topik) dihitung satu pemilik dalam CHECK "tepat satu pemilik". Nama kolom: keterangan (bukan "judul").
17. Aturan payung disimpan sebagai DATA: pk_daftar jenis "payung" (siapa, cakupan topik, sejak kapan, dari owner siapa), supaya alat bisa memeriksa "admin ini masuk payung topik ini?" tanpa mengandalkan ingatan.
18. Baris PK internal ikut paket sesi japri/CS dengan label [INTERNAL – jangan disebut ke pelanggan] (juga di keluaran pk lihat). Sesi GRUP hanya menerima baris publik.
19. log diberi kolom kode_grup + id lampiran (opsional), karena kejadian grup tidak selalu tentang satu orang.
20. Uji coba sesuai bagian 11 (putar ulang → bayangan → live penuh); ukur token sebelum & sesudah dengan cara yang sama (input + cache write + output).