memory'ye ne yazmalı? 5 kaydımı tek tek denetledim

Önceki yazı, CLAUDE.md'nin yalnızca Claude'un kodu okuyarak göremediği şeyleri barındırması gerektiğini savundu. Bir okuyucu hemen sordu: peki ya memory? Memory de bağlam — gerçek fark nerede?

Çoğu kişi zamanla memory'yi CLAUDE.md'nin "yedek uzantısı" gibi kullanmaya başlıyor — aklına geleni tıkıyor. Zamanla memory şişiyor, Claude onu her seçişte okuyor ve kararlar güncelliğini yitirmiş bilgiyle alınıyor.

Bu yazı soyut tanımları atlıyor. Bu projede şu anda çalışan 5 memory dosyasını da açıp tek tek denetledim — hangisi kalıyor, hangisi gidiyor, hangisi hiç yazılmamalıydı. Yol boyunca, CLAUDE.md vs memory sorusu kendiliğinden cevaplanıyor.

Tek cümlede fark

• CLAUDE.md her oturumun system prompt'una girer. Statik. Değişmezler için.
• memory, Claude'un kendisi tarafından okunur ve güncellenir. Dinamik. Değişen gerçekler ya da saklamaya değer tek olaylar için.

Yararlı soru "bunu nereye koymalıyım" değil — "bu bilgi ne kadar yaşar ve onu kim günceller?"

5 memory dosyam

feedback_commits               — ben "commit" diyene kadar commit yapma
feedback_article_authenticity  — uygulamalı yazılar uydurulamaz
project_i18n_strategy          — "tüm dilleri aynı anda çıkar" kararı
project_howdev_plan            — how2claude.dev için yarım kalmış plan
project_article_workflow       — makale yayın hattı

Tipe göre gruplandırılmış.

Tip A: Kalıcı kurala dönüşen tek bir düzeltme (feedback_commits)

Gövde kısa: "don't auto-commit, wait for user to confirm."

Bu, memory'nin en yüksek ROI'li türüdür. Bir düzeltme → sonraki tüm oturumlarda kalıcı.

Neden CLAUDE.md'de değil? Bu bir proje kuralı değil — benim kişisel çalışma alışkanlığım. Başka bir katkıcı projeye katılsa, aynı kurala uymak zorunda değil. CLAUDE.md takım düzeyidir. Memory "benimle Claude arasında"dır.

Neden her konuşmanın başında yinelemiyorum? Çünkü memory oturumlar arasında kalıcıdır. Claude gelecek hafta bana yardım ederken hâlâ hatırlıyor.

Tetikleyici net: Bir kez düzelttim ve o düzeltmenin sonsuza kadar sürmesini istiyorum.

Tip B: Tarih taşıyan bir olay dosyası (feedback_article_authenticity)

Bu memory'nin gövdesi alışılmadık derecede spesifiktir:

2026-04-16'da, multi-agent serisinin sonunu yazarken, "üç Agent'in bir webhook özelliği kurduğu" hikâyeyi uydurdum... tamamen kurgu. Kullanıcı "bu gerçek mi uydurma mı" diye sordu — bu, önceki iki (metodolojik) yazıdan farklı bir ölçüt...

Önemli nokta: Why alanı soyut bir ilke değil — spesifik olay + tarih + ne olduğu.

Neden böyle yazılı? Altı ay sonra, soyut bir kural olarak "uygulamalı yazılar gerçek malzeme gerektirir" kafamı karıştıracak — ne zaman konuldu, neden konuldu? Ama "4-16, bir agent hikâyesi uydurdum ve yakalandım" anında hatırlatıyor ve kuralın hâlâ geçerli olup olmadığını yerinde yargılamamı sağlıyor.

Bu, 5'imden en "ağır" kayıttır. Sadece bir kural değil — hem Claude'un hem benim sorgulayabileceğim bir olay dosyasıdır.

Tip C: Stratejik karar arka planı (project_i18n_strategy)

İçerik: bu projenin neden tüm dilleri aynı anda agresif şekilde çıkardığı — Claude üzerinden çeviri maliyeti ~$0 ve resmi dökümanın yalnızca İngilizce olması merkezi fırsat penceresi.

Bunu koddan göremezsin. Kodda yalnızca 19 locale dosyası görünür. Neden 19, neden aynı anda, neden Japonca ve Korece öncelikli — bunların hepsi benim kafamda.

Memory bu "kafanın içindeki kararı" kalıcı bir şeye dönüştürür; böylece Claude daha sonra bir özellik önerdiğinde sorabilir: bu, i18n stratejisiyle çelişiyor mu?

Operasyonel bir kural değil (CLAUDE.md'ye girmez). Stratejik arka plan (memory'ye girer).

Tip D: Oturumlar arası devir (project_howdev_plan)

Grubun en geçicisi: how2claude.dev geliştirici sitesi için 9 dosyalık bir uygulama planı, sonunda "bir sonraki oturumda devam edilecek" yazıyor.

En tehlikeli memory türü — kolayca zombi memory'ye dönüşür. İşi bitirir, silmeyi unutursun; bir dahaki sefere Claude onu hâlâ geçerli sayar ve güncelliğini yitirmiş bir plana göre öğüt verir ("step 3'ü henüz yapmamışsın").

Bu tür memory'lerin açık bir çıkış mekanizmasına ihtiyacı vardır: how2claude.dev yayınlandığı anda bu kaydı elle silmem gerekir.

Tip E: Silinmesi gereken (project_article_workflow)

Bunun bilgi yoğunluğu en yüksek. Başta en faydalı sandım — dikkatle okuyana kadar:

• /write-article ve /publish-article varlığı → .claude/commands/'a bak, tamam
• Draft dizin yapısı (meta.json + lang.md) → docs/drafts/ görür görmez belli
• API URL → .claude/publish-config.json'da
• Category/series slug listesi → seed dosyasında

Claude bunların hepsini kodu okuyarak türetebilir.

Memory'nin gerçekten sağladığı tek şey son blok: "Accounts (production): zh → @how2claude, en → @howtoclaude" — ve bu zaten bayatladı. Geçen oturum, production'ın aslında zh=@howtoclaude olduğunu gösterdi. Memory birkaç gün öncesinin anlık görüntüsünü saklıyor; kaymış durumda.

Sonuç: Bu memory'nin %90'ı gitmeli. Saklamaya değer kısım ("canlı hesapları sorgulamak için kamal kullan") CLAUDE.md'ye daha uygun — ya da daha iyisi, hiçbir yere yazmamak, çünkü memory'ye kodlanmış hesaplar yine kayacak.

Dört çıkarım

1. Memory'nin gerçek işi Claude'un giremediği odaları açmaktır.

• Kafama giremez → strateji, tercihler, nedenler
• Geçen haftaki oturuma giremez → seni neyde düzelttiğim
• Üç ay önceki bir başarısızlığa giremez → spesifik olay + tarih

2. Claude koddan okuyabiliyorsa memory'ye koyma.

Önceki CLAUDE.md yazısıyla aynı ilke. Dosya yolları, API URL'leri, dizin yapısı — hepsi kodun cevaplayabileceği sorular. Bir kez grep yapmamak için memory'ye tıkmak, hiçbir şeyin asla değişmeyeceğine bahse girmektir.

3. Memory bozulur.

project_article_workflow kanıt — birkaç gün önce yazıldı, hesap bilgisi zaten yanlış. Memory ne kadar eskiyse o kadar güvenilmez. Düzenli denetim > durmadan ekleme.

4. Why alanı seni kurtaran şeydir.

İki feedback'imi karşılaştır:

• feedback_article_authenticity Why'ı: "4-16, multi-agent yazısında bir hikâye uydurdum" → altı ay sonra hemen geçerli mi diye yargılayabilirim.
• feedback_commits Why'ı: yalnızca "user wants to review" → altı ay sonra, hangi spesifik düzeltmenin onu doğurduğundan emin değilim.

İkincisi çok daha zayıf. Soyut ilkeler hayatta kalmaz — kimse neden empoze edildiklerini hatırlamaz.

Karar ağacı: CLAUDE.md vs memory vs hiçbir şey

Yeni bir bilgi ortaya çıktığında üç soru sor:

1. Claude bunu koddan türetebilir mi? Evet → hiçbir şey yazma.
2. Tüm katkıcıların buna uyması gerekiyor mu? Evet → CLAUDE.md.
3. Zamanla değişecek mi? Evet → memory (spesifik Why + How to apply ile).

Üçüncü soru bir tuzak. Kaydetmek istediğin "değişmez" şeylerin çoğu aslında koddan türetilebilir — sen sadece Claude'un tekrar grep yapmasını istemiyorsun.

Denetim sonrası gördüklerim

Bir kez geçtikten sonra birkaç şey öne çıktı:

• project_article_workflow'un %90'ı koddan türetilebilir. En çok bu kayıt ameliyat gerektiriyor.
• project_howdev_plan geçici bir devir — teorik olarak çıkış mekanizması olmalı.
• project_i18n_strategy stratejik bir karar — birkaç ay sonra tekrar değerlendirmeye değer.
• feedback_commits'in Why'ı zayıf; spesifik bir olay eklemek onu daha sağlam kılar.

Yan gözlem: tip dağılımım feedback×2 + project×3, user veya reference türü sıfır. Yani Claude'a "ben kimim" veya "hangi dış sistemlerden durum okuyorum" demiş değilim. Muhtemelen yazılacak bir sonraki parti.

Kapanış

Memory'nin en büyük tuzağı "yazmam gerekip de yazmadığım şey" değil. "Yazdığım ama artık bayat olan şey"dir. 5 kayıtta bir kayma yeter — Claude sessizce güncelliğini yitirmiş bilgiyi karar vermek için kullanır ve bu kaymayı sana bildirmez.

5'imin içinde, şimdiden kıpırdatmak istediğim birkaç nokta görüyorum. Seninkilerde nasıl?