Struktur vault dan debugging

Atur vault markdown sebagai memori kedua yang dapat dicari. Tinjau empat mode kegagalan ketika Claude melakukan sesuatu yang tidak terduga.

STATE.md dan MEMORY.md menyimpan apa yang dibutuhkan setiap sesi. Sebuah vault markdown (Obsidian atau folder apa pun) menyimpan segala sesuatu yang lain: catatan strategi, transkrip rapat, jurnal proyek, penelitian, analisis kompetitif.

Vault tumbuh menjadi memori institusional: keputusan yang Anda buat enam bulan lalu dan alasannya, materi referensi yang menginformasikan pekerjaan saat ini, pola yang mencakup proyek. Hubungkan melalui MCP Obsidian atau sistem file dan Claude dapat mencari seluruhnya sesuai permintaan. Tanpa vault, pengetahuan ini hanya ada di kepala Anda atau terkubur dalam dokumen lama.

Mengapa markdown mengalahkan basis data: file biasa dapat dicari, versi dengan git, dibuka di editor apa pun, dan bertahan dari setiap perubahan alat. Struktur kerja:

~/notes/

├── STATE.md # Selalu dimuat

├── MEMORY.md # Indeks, selalu dimuat

├── STRATEGY-DIGEST.md # Ringkasan dokumen strategi

├── strategy/ # Dokumen lengkap, dibaca sesuai permintaan

├── projects/ # Catatan proyek bertanggal

├── resources/

└── reference/Kunci penskalaan adalah pola ringkasan: ketika Anda menulis dokumen strategi 1.000 kata, tulis ringkasan 3 kalimat di sampingnya dan indeks ringkasan di MEMORY.md. Claude membaca sekitar 50 token di awal sesi alih-alih sekitar 1.500 kata dari dokumen lengkap. Dengan 25 dokumen strategi, itu adalah 1.250 token versus 37.500, dan sesi tetap cepat.

Ketika Claude melakukan sesuatu yang tidak terduga, periksa empat mode kegagalan secara berurutan, dari yang paling umum hingga paling tidak umum:

Memori usang: STATE.md mengatakan satu hal, kenyataan mengatakan hal lain. Claude mengikuti instruksi Anda dengan sempurna; instruksinya salah. Tanyakan "Tunjukkan STATE.md Anda" terlebih dahulu, setiap saat.

Konteks hilang: file yang relevan tidak pernah dimuat, jadi Claude membuat tebakan yang masuk akal. Muat file secara eksplisit dan tanyakan lagi.

Alat tidak tersedia: MCP mati atau hook memblokir perintah, dan Claude mengatasinya dengan buruk. Periksa ketersediaan alat sebelum menyalahkan penalaran.

Halusinasi: penyebab paling langka. Verifikasi terlebih dahulu: grep untuk fungsi, periksa apakah endpoint ada. Sebagian besar "halusinasi" ternyata adalah salah satu dari tiga yang pertama.

Satu pertanyaan diagnostik per mode kegagalan:

Memori usang: "Apa yang dikatakan STATE.md Anda tentang [topik]?" Konten dari tiga sesi yang lalu berarti status usang.

Konteks hilang: "File apa yang Anda muat tentang [topik]?" Tidak ada file yang relevan berarti muat yang benar.

Alat tidak tersedia: "Alat apa yang Anda miliki saat ini?"

Halusinasi: "Grep untuk [fungsi/endpoint] dan tunjukkan apa yang Anda temukan."

Urutan ini membutuhkan waktu dua menit dan menemukan penyebabnya hampir setiap saat. Langsung melompat ke "Claude berhalusinasi" biasanya menunda perbaikan sebenarnya dengan menulis ulang kode yang tidak perlu ditulis ulang.

Pencegahan lebih baik daripada debugging. Kebiasaan:

Pembaruan STATE.md akhir sesi. Menghilangkan 80% masalah memori usang.

Arsipkan proyek yang telah dikirim ke file project_* bertanggal.

Audit MEMORY.md bulanan: konfirmasi setiap penunjuk masih menunjuk ke file yang ada.

Ringkas setiap dokumen lebih dari 500 kata.

Tulis keputusan pada saat keputusan, bukan di akhir minggu. Penangkapan retroaktif menghilangkan penalaran.

Sebelum mengarsipkan catatan proyek, ekstrak pelajaran yang tahan lama ke entri feedback_*. Proyek menjadi sejarah; pelajaran tetap aktif.

Vault dengan 10 dokumen yang terawat baik lebih baik daripada satu dengan 200 dokumen usang. Kualitas dan mata uang mengalahkan volume.

Dengan MCP Obsidian atau sistem file, vault menjadi basis pengetahuan langsung:

Arkeologi keputusan: "Cari di vault mengapa kami memilih Postgres daripada MySQL." Perburuan manual 10 menit menjadi 15 detik.

Deteksi pola: "Temukan semua penyebutan masalah pembatasan laju atau kesalahan 429 di seluruh proyek." Claude menampilkan akar penyebab umum yang tersebar di lima file proyek.

Pencarian referensi: "Temukan informasi kontak di catatan vendor." Pengambilan instan dari file yang tidak terindeks.

Kualitas pencarian tergantung pada konsistensi penamaan: project_[nama]_[tanggal].md dan feedback_[aturan].md lebih baik daripada apa pun yang terasa alami pada saat itu. Konvensi penamaan adalah indeks yang Anda bangun sebelum Anda membutuhkannya.

Keempat mode diperiksa bersih dan hasilnya masih salah? Dua penyebab terlihat seperti halusinasi tetapi bukan.

Urutan konteks: ketika file yang dimuat bertentangan, konten yang dimuat belakangan cenderung menang. Jika catatan proyek lama bertentangan dengan STATE.md, tetapkan otoritas secara eksplisit: "STATE.md adalah kebenaran dasar saat ini. Ini menggantikan apa pun dalam catatan proyek."

Tabrakan batasan: CLAUDE.md mengatakan "parameterkan semua SQL," jadi Claude menulis ulang SQL selama apa yang Anda maksudkan sebagai refaktor gaya-saja. Bukan bug; cakupkan secara eksplisit: "Hanya gaya, jangan ubah pola SQL."

Diagnostik untuk keduanya: "Instruksi apa yang Anda ikuti yang mengatur [keputusan ini]? Sebutkan aturan-aturan dalam urutan prioritas." Anda akan menemukan sumber yang usang, aturan yang bertentangan, atau celah CLAUDE.md. Semuanya bisa diperbaiki.

Vault markdown dengan file ringkasan menskalakan memori kedua Anda; ringkasan menjaga sesi tetap cepat, dokumen lengkap dimuat sesuai permintaan. Ketika Claude berperilaku salah, lakukan triase secara berurutan: memori usang, konteks hilang, alat tidak tersedia, halusinasi, dan selalu mulai dengan "tunjukkan STATE.md Anda." Beri makan vault pada saat keputusan dan nilainya akan bertambah setiap minggu.