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: otopia · anti-karat · avanza · bali · Rp2.100.000 · berlaku sejak 07/10 · berlaku

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.

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.

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

Uji coba dulu di satu produk/peran (mis. CS Labbaik), bandingkan mutu & token dengan cara sekarang, baru diperluas.

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; Ary tidak bisa mengubah PK tanpa izin. 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.