Claude Code istek günlüğü

Bu bana defalarca oldu: akşam ekiple bir bloğun birkaç seçeneğini değerlendirdik, sabah biri başlığın neden kısaldığını soruyor. Yazışmada onlarca mesaj var, hafızada "sanırım arka plan açık renkti" gibi bir şey kalıyor, kesin karar ise düzeltmeler arasında eriyip gidiyor.

Tam da böyle anlarda requests.log imdada yetişiyor. Bu, sıradan bir editörde açıp yukarıdan aşağı okuyabileceğiniz, kısa ve harici bir çalışma izi. Onu satır sayısı için değil, isteği sonunda gerçekten bırakılmasına karar verilen şeyle ilişkilendirebildiğim için değerli buluyorum.

Harici İz Neden Gerekli?

Yıllar içinde dört şeyi birbirinden ayırmaya alıştım: istek, karar, yazışma ve dosyanın kaydedilmiş sürümü. Bunlar farklı sorulara yanıt verir, ama tek bir oturum sırasında kolayca birbirine karışıp belirsiz tek bir hikayeye dönüşür.

Günlük, bir işaretçi gibi çalışır: sizi doğru ana ve tam kelimelere geri götürür. Kodun kendisini ise geri getirmez. Sayfanın kaydedilmiş sürümünü görmeniz gerekiyorsa dosyalara ve projenin sürüm geçmişine bakın.

Şemada, günlüğü incelerken önemli olan fark net görülüyor. Üst zincir çalışmanın gidişatını gösterir, alt zincir ise günlükte kalanı. Otomatik satır sonuçtan önce oluşur; karar notu ise ancak kontrolden sonra belirir. Biri diğerinin yerini tutmaz.

Yararlı Bir Kayıt Nelerden Oluşur?

Üç kayıt örneği üzerinden göstereyim. Gerçek projelerde bunların her birine rastladım.

tamam

Böyle bir satır neredeyse işe yaramaz: kimin ne yaptığı, ne zaman yaptığı ve bu "tamam"ın hangi göreve ait olduğu belli değil.

Kullanıcı: Kart başlığını kısalt...
Claude: Peki, önce bileşene bakayım...
Kullanıcı: Boşluğu da azalt...
Claude: Düzelttim...

Burada ise hızlı arama için gereğinden fazla şey var. Tam akış, sohbet geçmişinde iyi durur, ama ayrı bir günlük hızla onun kullanışsız bir kopyasına dönüşür. Böyle yapmayı denedim, sonra ekranı kaydırmakla vakit kaybeden yine ben oldum.

2026-09-08T14:32:11+03:00 | prompt_submitted | actor=user | ref=card-header | text="Kart başlığını tek satıra indir"
2026-09-08T14:41:06+03:00 | decision_recorded | actor=user | ref=card-header | text="Kısa başlık kabul edildi, boyut 24 px"

Üçüncü örneği en çok beğeniyorum: içinde kısa bir olgu, saat dilimiyle birlikte zaman, yazan kişi ve satırları birbirine bağlayan ref etiketi kalıyor. Alanların adları burada eğitim amaçlı proje için uydurulmuştur. Bu bizim dosyamızın biçimidir, Claude Code'un zorunlu bir şeması değildir. Bu incelemede ref etiketleri, ilişkili satırlara elle eklenmiştir. Hook, isteğin hangi bloğa ait olduğunu tahmin etmez: temel UserPromptSubmit olayı böyle bir anlamsal etiket içermez. Bağlantı alanı yoksa, günlüğünüzde yine de tam ifadeyle arama yapabilirsiniz.

Kayıt Anında Ne Biliniyordu?

prompt_submitted satırı tam olarak tek bir şey söyler: oturuma böyle bir istek geldi ve hook bunu kaydetti. Genellikle bu sizin metninizdir, ama her zaman değil. UserPromptSubmit, /loop'un bir sonraki turunda da, arka plandaki bir subagent'ın raporunda da, başka bir oturumdan gelen mesajda da tetiklenir; bu yüzden formatımızdaki actor=user eğitim örneğinin bir varsayımıdır. Bundan, Claude Code'un sayfayı değiştirdiği, kontrolün başarılı olduğu ya da sonucun herkesi memnun ettiği çıkmaz.

Sonuç, bilindiği andan sonra kaydedilmelidir. Bizim örneğimizde bu, sayfa incelendikten sonraki ayrı bir nottur. Biçiminizde result veya error alanları varsa, bunları görevin gelecekteki sonucu hakkında bir varsayımla değil, gözlemlenen olgularla doldurun.

Alınan Karar Nereye Not Edilir?

Karar, ancak birisi onu açıkça kaydettiğinde ortaya çıkar. Yukarıdaki örnekte satırı, sayfayı inceledikten sonra kullanıcı ekledi. Yazan kişi actor alanında belirtilir, istekle bağlantıyı ref=card-header tutar.

Not manuel olabilir, bu normaldir. Otomatik kayıt girdiyi saklar, insan ise sonucun anlamını onaylar. Yazan kişisi ve bağlantısı olmayan "tamam" satırına güvenilmemelidir.

İstek Günlüğünü Okumak

Beş satırlık küçük bir günlüğü inceleyelim. Bir kararın gidişatını yeniden kurmam gerektiğinde genelde tam da böyle kısa parçalarla başlarım.

2026-09-08T14:32:11+03:00 | prompt_submitted | actor=user | ref=card-header | text="Kart başlığını tek satıra indir"
2026-09-08T14:36:20+03:00 | prompt_submitted | actor=user | ref=card-header | text="İki seçenek göster: 24 px ve 28 px"
2026-09-08T14:41:06+03:00 | decision_recorded | actor=user | ref=card-header | text="Kısa başlık kabul edildi, boyut 24 px"
2026-09-08T15:03:44+03:00 | prompt_submitted | actor=user | ref=card-shadow | text="Kart gölgesini yumuşat"
2026-09-08T15:08:17+03:00 | prompt_submitted | actor=user | ref=card-header | text="Başlık için daha koyu bir renk dene"

Başlığın biçimiyle ilgili son alınan kararı bulmanız gerektiğini düşünün. Editörde card-header ile aramaya başlayın. Dört satır çıkacak. Sonuncusu renkle ilgili yeni bir istek içeriyor, ama karar değil. Bu yüzden çıkarım 14:41:06 saatindeki satıra dayanır: 24 px boyutunda kısa başlık kabul edildi.

Benim çalışma sıram basit:

1. Önce soruyu netleştiriyorum: istek mi, karar mı yoksa gözlemlenen bir hata mı arıyorum.
2. Ortak etiketi, bileşen adını ya da tam ifadeyi buluyorum.
3. Yalnızca ihtiyacım olan türdeki kayıtları ayırıp zamana göre okuyorum.
4. Çıkarımı doğrulayan satırları belirtiyorum. Geri kalan her şeyi dürüstçe bilinmeyen olarak bırakıyorum.

Bu inceleme Claude Code'u çalıştırmadan da yapılabilir. Bu yararlı bir alışkanlık: önce çıkarımı kendiniz dosyayla karşılaştırın, aynı işi ajana ancak ondan sonra verin.

Günlükte Karar Yoksa

Şimdi 14:41:06 satırını kaldıralım. Geriye iki boyutu gösterme isteği ve daha sonraki renk değiştirme isteği kalır. Hangi boyut kabul edildi? Günlük yanıt vermiyor.

Böyle yerlerde, ilk önerilen seçenek olduğu için 24 px'i seçmek çok cazip gelir. Yapmayın. İstek, seçenekleri kontrol etme niyetini gösterir, ama seçimin sonucunu göstermez. Buradaki dürüst çıkarım tek bir şeydir: boyutla ilgili alınan karar günlükte kayıtlı değil.

Ayrım, isteklerin sırasına değil, bulunan kaydın türüne bağlıdır. Açık bir karar notu varsa, çıkarım doğrulanabilir. Yalnızca istekler kaldıysa, bilinmeyeni not ederiz ve boşluğu tahminle doldurmayız. Bu temkinli tavır sonunda çok zaman kazandırır.

Günlüğün Dışında Ne Bırakılır?

Yararlı bir günlüğü her şeyin depolandığı bir yere dönüştürmeye çalışmıyorum. Kaydın içeriği, daha sonra ele alınacak soruya göre seçilmeli. Karar bulmak için genelde zaman, olay türü, yazan kişi, bağlantı etiketi ve kısa bir metin yeterlidir.

• Anahtarları, token'ları, .env içeriğini ve kişisel verileri kopyalamayın.
• Yalnızca durum ya da işlem kimliği gerekiyorsa, harici hizmetlerin yanıtlarını olduğu gibi taşımayın.
• Tam prompt'u yalnızca gerçekten gerekli olduğu yerde bırakın. Bu makalede tam hâliyle duruyor, çünkü örnek uydurma ve kısa.
• Dosya boyutunu ve eski kayıtların faydasını periyodik olarak kontrol edin. Tüm projeler için ortak bir saklama süresi yoktur.

Satırı yüz karaktere kısaltmak okunabilirliği artırır, ama sırları otomatik olarak silmez. Kısa bir token ilk yüz karaktere de rahatça sığar. Önce hangi verilerin kaydedilmesine izin verildiğine karar verin. Tam olarak bu kuraldan başlamak gerekir, satırın uzunluğundan değil.

Günlüğü Claude Code ile Birlikte İncelemek

Claude Code olayların zaman sırasını iyi çıkarır ve ilişkili satırları hızlı bulur. Ama bunun için dosyayı açıkça okuması gerekir: projede requests.log bulunması, içeriğinin zaten bağlamda olduğu anlamına gelmez.

Ajana somut bir görev verin:

requests.log dosyasını oku. Kart başlığının (card-header) boyutu
hakkında en son açıkça alınan kararı bul. Dayandığın kayıtları belirt.
Günlükte yalnızca istek varsa, bunu açıkça söyle.
Bilinmeyen kalan her şeyi ayrıca listele.

İyi bir yanıt, olguları çıkarımdan ayırır: zamanı, olay türünü ve karar metnini alıntılar, ardından doğrulanmamış soruları listeler. Bu referansları kaynak satırlarla karşılaştırın. Ajan son isteği "kabul edilen seçenek" diye adlandırdığında hata özellikle göze çarpar.

Buradaki eğitim amaçlı günlük için yanıt şöyle olur: boyutla ilgili kararı 2026-09-08T14:41:06+03:00 kaydı doğruluyor; sonra daha koyu bir renk isteği geldi, ama renkle ilgili alınan karar bilinmiyor. Ben tam da böyle bir yanıtı güvenilir buluyorum: dosyada olandan fazlasını vaat etmiyor.

• Hook, isteği işlenmeden önce kaydeder, bu yüzden bu kayıt sonucu doğrulamaz.
• Ayrı bir not, alınan kararı zaman veya etiket üzerinden istekle ilişkilendirir.
• Arama somut bir soruyla başlar ve kaynak satırlara bir referansla sona erer.
• Doğrulama yoksa, günlükte bir boşluk kalır. Onu tahminle doldurmayın.

Böylece requests.log küçük ve işlevsel bir çalışma izi olarak kalır: tartışmanın doğru dönüm noktasını bulmaya yardımcı olur, ama kendini ne projenin yedeği ne de tamamlanmış bir görevin kanıtı gibi göstermez. Günlük dürüstçe tutulduğunda, ona gerçekten geri dönmek istersiniz.