Bu mənim başıma dəfələrlə gəlib: axşam komanda ilə blokun bir neçə variantını sınayırıq, səhər isə kimsə soruşur ki, başlıq nə üçün qısalıb. Yazışmada onlarla mesaj var, yaddaşda "deyəsən, fon açıq idi" kimi bir şey qalır, dəqiq qərar isə düzəlişlərin arasında əriyib gedir.

Belə anlarda requests.log köməyə çatır. Bu, adi redaktorda açıb yuxarıdan aşağı oxumaq olan işin qısa xarici izidir. Onu sətirlərin sayına görə yox, sorğunu həqiqətən saxlamaq qərarına gəldiyimiz şeylə əlaqələndirmək imkanına görə qiymətləndirirəm.

Xarici iz nə üçün lazımdır

İllər boyu dörd şeyi ayırmağa öyrəşmişəm: sorğu, qərar, yazışma və faylın saxlanmış versiyası. Onlar müxtəlif suallara cavab verir, hərçənd bir sessiya ərzində asanlıqla bir-birinə qarışıb qeyri-müəyyən bir hekayəyə çevrilirlər.

MənbəOndan nə öyrənmək olarNəyi sübut etmir
requests.logNə istənilib və qeyd nə vaxt görünübDəyişikliyin edilib-edilmədiyini və qəbul olunub-olunmadığını
Qərar qeydiHansı variant seçilib və kim onu qeyd edibSaxlanmış faylın indi necə göründüyünü
Yazışma tarixçəsiMüzakirənin konteksti və cavablarLayihənin cari versiyasına nəyin düşdüyünü
Versiya nəzarəti sistemiHansı fayllar və sətirlər saxlanılıbMəhz bu variantın nə üçün seçildiyini

Jurnal göstərici kimi işləyir: sizi lazımi ana və dəqiq sözlərə qaytarır. Kodun özünü bərpa etmir. Səhifənin saxlanmış versiyasını görmək lazımdırsa, fayllara və layihənin versiya tarixçəsinə baxın.

Claude Code nəyi yazır

Burada mühüm bir sərhəd var və məhz bu yerdə xeyli yanlış nəticəyə rast gəlmişəm. UserPromptSubmit hadisəsinin hook-u mətni Claude Code sorğunu emal etməzdən əvvəl prompt sahəsində alır. Belə sətir mətnin göndərildiyini təsdiqləyir, amma tapşırığın nəticəsi bu anda hələ məlum deyil.

Sorğu UserPromptSubmit hadisəsindən keçərək Claude Code-a gəlir, avtomatik qeyd göndərilmiş mətni saxlayır, ayrıca əl ilə qeyd isə yalnız nəticə insan tərəfindən yoxlanıldıqdan sonra görünürrequests.log-da xarici izSorğunuzmətn göndərildiUserPromptSubmithadisə işə düşdüClaude Codeemal edirYoxlamanıznəticə görüldüAvtomatik qeydsorğu göndərildiƏl ilə qeydqərar qəbul edildi
Sorğu və qəbul edilmiş qərar xarici izə fərqli anlarda düşür

Sxemdə loqu araşdırarkən vacib olan fərq yaxşı görünür. Yuxarıdakı zəncir işin gedişini göstərir, aşağıdakı isə jurnalda qalanı. Avtomatik sətir nəticədən əvvəl yaranır; qərar qeydi isə yalnız yoxlamadan sonra görünür. Biri digərini əvəz etmir.

Faydalı qeyd nədən ibarətdir

Üç qeyd variantı üzərində göstərəcəyəm. Real layihələrdə onların hər birinə rast gəlmişəm.

hazırdır

Belə sətir demək olar ki, faydasızdır: kimin nə etdiyi, nə vaxt etdiyi və bu "hazırdır" sözünün hansı tapşırığa aid olduğu aydın deyil.

İstifadəçi: Kartın başlığını qısalt...
Claude: Yaxşı, əvvəlcə komponentə baxacağam...
İstifadəçi: Boşluğu da azalt...
Claude: Düzəltdim...

Burada isə artıq sürətli axtarış üçün həddən çox şey var. Tam axın söhbət tarixçəsində yaxşıdır, amma ayrıca jurnal tez onun əlverişsiz nüsxəsinə çevrilir. Belə etməyi sınamışam, sonra özüm sürüşdürməyə vaxt sərf etmişəm.

2026-09-08T14:32:11+03:00 | prompt_submitted | actor=user | ref=card-header | text="Kartın başlığını bir sətrə qısalt"
2026-09-08T14:41:06+03:00 | decision_recorded | actor=user | ref=card-header | text="Qısa başlıq qəbul edildi, ölçü 24 px"

Üçüncü variant mənə ən çox xoş gəlir: onda qısa fakt, saat qurşağı ilə vaxt, müəllif və sətirləri əlaqələndirən ref etiketi qalır. Sahələrin adları burada tədris layihəsi üçün uydurulub. Bu bizim faylımızın formatıdır, Claude Code-un məcburi sxemi deyil. Bu təhlildə ref etiketləri əlaqəli sətirlərə əl ilə əlavə olunub. Hook sorğunun hansı bloka aid olduğunu təxmin etmir: standart UserPromptSubmit hadisəsində belə məna etiketi yoxdur. Əlaqə sahəsi yoxdursa, jurnalınızda yenə də dəqiq ifadə üzrə axtarış aparmaq olar.

Qeyd anında nə məlum idi

prompt_submitted sətri yalnız bir şey bildirir: sessiyaya belə bir sorğu daxil olub, hook isə onu qeydə alıb. Adətən bu sizin mətninizdir, amma həmişə yox. UserPromptSubmit həm /loop-un növbəti dövrəsində, həm fon subagentinin hesabatında, həm də başqa sessiyadan gələn mesajda işə düşür, ona görə bizim formatdakı actor=user tədris nümunəsinin fərziyyəsidir. Bundan Claude Code-un səhifəni dəyişdiyi, yoxlamanın keçdiyi və ya nəticənin hamının xoşuna gəldiyi çıxmır.

Nəticəni yalnız məlum olduqdan sonra yazmağa dəyər. Bizim nümunəmizdə bu, səhifəyə baxıldıqdan sonra əlavə edilən ayrıca qeyddir. Formatınızda result və ya error sahələri varsa, onları tapşırığın gələcək nəticəsi barədə fərziyyə ilə yox, müşahidə olunan faktlarla doldurun.

Qəbul edilmiş qərarı harada qeyd etmək

Qərar yalnız kimsə onu açıq şəkildə qeyd etdikdə görünür. Yuxarıdakı nümunədə sətri istifadəçi səhifəyə baxdıqdan sonra əlavə edib. Müəllif actor-da göstərilib, sorğu ilə əlaqəni isə ref=card-header saxlayır.

Qeyd əl ilə ola bilər, bu normaldır. Avtomatik qeyd girişi saxlayır, insan isə nəticənin mənasını təsdiqləyir. Müəllifi və bağlantısı olmayan "hazırdır" sətrinə güvənmək lazım deyil.

Sorğu jurnalını oxuyuruq

Beş sətirlik kiçik jurnalı araşdıraq. Qərarın necə qəbul edildiyini bərpa etmək lazım olanda adətən məhz belə qısa parçalardan başlayıram.

2026-09-08T14:32:11+03:00 | prompt_submitted | actor=user | ref=card-header | text="Kartın başlığını bir sətrə qısalt"
2026-09-08T14:36:20+03:00 | prompt_submitted | actor=user | ref=card-header | text="İki variant göstər: 24 px və 28 px"
2026-09-08T14:41:06+03:00 | decision_recorded | actor=user | ref=card-header | text="Qısa başlıq qəbul edildi, ölçü 24 px"
2026-09-08T15:03:44+03:00 | prompt_submitted | actor=user | ref=card-shadow | text="Kartın kölgəsini yumşalt"
2026-09-08T15:08:17+03:00 | prompt_submitted | actor=user | ref=card-header | text="Başlıq üçün daha tünd rəng sına"

Təsəvvür edin ki, başlıq formatı haqqında sonuncu qəbul edilmiş qərarı tapmalısınız. Redaktorda card-header üzrə axtarışla başlayın. Dörd sətir alınacaq. Sonuncusu rəng haqqında yeni istəkdir, qərar deyil. Ona görə nəticə 14:41:06-dakı sətrə əsaslanır: 24 px ölçülü qısa başlıq qəbul edilib.

Jurnalı oxuyarkən iş qaydam sadədir:

  1. Əvvəlcə sualı formalaşdırıram: sorğu, qərar və ya müşahidə olunan xəta axtarıram.
  2. Ümumi etiketi, komponentin adını və ya dəqiq ifadəni tapıram.
  3. Yalnız lazımi tipdəki qeydləri saxlayıram və onları vaxt üzrə oxuyuram.
  4. Nəticəni təsdiqləyən sətirləri adlandırıram. Qalan hər şeyi dürüst şəkildə naməlum olaraq saxlayıram.

Belə təhlili Claude Code-u işə salmadan da etmək olar. Bu, faydalı vərdişdir: əvvəlcə nəticəni özünüz faylla tutuşdurun, yalnız sonra eyni işi agentə tapşırın.

Jurnalda qərar olmayanda

14:41:06-dakı sətri indi çıxaraq. İki ölçünü göstərmək xahişi və rəngi dəyişmək barədə sonrakı istək qalacaq. Hansı ölçü qəbul edilib? Jurnal cavab vermir.

Belə yerlərdə insanın 24 px-i seçməyə meyli çox olur, çünki bu, ilk təklif olunan variantdır. Buna dəyməz. Sorğu variantları yoxlamaq niyyətini göstərir, seçimin nəticəsini yox. Buradakı yeganə dürüst nəticə budur: ölçü haqqında qəbul edilmiş qərar jurnalda qeyd olunmayıb.

Əlaqəli qeydlər axtarıldıqdan sonra açıq qərar qeydinin olması təsdiqlənmiş nəticəyə aparır, yalnız sorğuların olması isə qərarı naməlum saxlayırƏlaqəli qeydlər tapıldıonları vaxt üzrə oxuyuruqAçıq qərarqeydi varmı?Bəli, nəticə təsdiqlənibqeydi və vaxtı göstərinXeyr, qərar naməlumdursorğunu fakta çevirməyin
Sonuncu sorğu sadəcə sonuncu olduğu üçün qərara çevrilmir

Hansı qola gedəcəyimiz istəklərin sırasından yox, tapılan qeydin tipindən asılıdır. Açıq qərar qeydi var - nəticəni təsdiqləmək olar. Yalnız sorğular qalıb - naməlumu qeyd edirik və boşluğu təxminlə doldurmuruq. Bu təmkin nəticədə çox vaxta qənaət edir.

Əsaslandırma istəyin

Jurnalı Claude Code araşdıranda ondan nəticənin dayandığı dəqiq qeydləri adlandırmasını istəyirəm. Təsdiqləyici sətir yoxdursa, bu, uğurlu nəticə barədə təxmin olmadan naməlumlar siyahısına düşməlidir.

Loqdan kənarda nə qalmalıdır

Faydalı jurnalı hər şeyin anbarına çevirməyə çalışmıram. Qeydin tərkibini sonra araşdırmalı olacağınız suala uyğun seçmək lazımdır. Qərarları tapmaq üçün adətən vaxt, hadisə tipi, müəllif, əlaqə etiketi və qısa mətn kifayət edir.

  • Açarları, tokenləri, .env məzmununu və şəxsi məlumatları kopyalamayın.
  • Yalnız status və ya əməliyyat identifikatoru lazım olanda xarici servislərin cavablarını tam köçürməyin.
  • Tam prompt-u yalnız həqiqətən lazım olan yerdə saxlayın. Bu məqalədə o, tam saxlanılıb, çünki nümunə uydurma və qısadır.
  • Faylın ölçüsünü və köhnə qeydlərin faydasını vaxtaşırı yoxlayın. Bütün layihələr üçün vahid saxlama müddəti yoxdur.

Sətri yüz simvola qədər kəsmək oxunaqlılığı yaxşılaşdırır, amma sirləri avtomatik silmir. Qısa token ilk yüz simvola da rahatlıqla sığır. Əvvəlcə hansı məlumatların ümumiyyətlə yazılmasına icazə verildiyinə qərar verin. Məhz bu qaydadan başlamaq lazımdır, sətrin uzunluğundan yox.

Jurnalı Claude Code ilə birlikdə necə araşdırmaq olar

Claude Code hadisələrin xronologiyasını yaxşı qurur və əlaqəli sətirləri tez tapır. Amma bunun üçün ona faylı açıq şəkildə oxumaq lazımdır: requests.log-un layihədə olması özü-özlüyündə onun məzmununun artıq kontekstdə olması demək deyil.

Agentə konkret tapşırıq verin:

requests.log-u oxu. Kartın başlığının ölçüsü (card-header) haqqında
sonuncu açıq şəkildə qəbul edilmiş qərarı tap. Söykəndiyin qeydləri göstər.
Jurnalda yalnız istək varsa, məhz bunu de.
Naməlum qalanları ayrıca sadala.

Yaxşı cavab faktları nəticədən ayırır: vaxtı, hadisə tipini və qərarın mətnini sitat gətirir, sonra isə təsdiqi olmayan sualları sadalayır. Bu istinadları mənbə sətirləri ilə tutuşdurun. Səhv xüsusilə agent sonuncu istəyi "qəbul edilmiş variant" adlandıranda nəzərə çarpır.

Bu tədris jurnalı üçün cavab belə olacaq: ölçü haqqında qərarı 2026-09-08T14:41:06+03:00 qeydi təsdiqləyir; sonra daha tünd rəng haqqında sorğu görünüb, amma rəng haqqında qəbul edilmiş qərar naməlumdur. Mən məhz belə cavabı etibarlı hesab edirəm: o, faylda olandan artığını vəd etmir.

  • Hook sorğunu emal olunmazdan əvvəl saxlayır, ona görə bu qeyd nəticəni təsdiqləmir.
  • Ayrıca qeyd qəbul edilmiş qərarı vaxta və ya etiketə görə sorğu ilə əlaqələndirir.
  • Axtarış konkret sualla başlayır və mənbə sətirlərinə istinadla bitir.
  • Təsdiq yoxdursa, jurnal boşluq saxlayır. Onu təxminlə doldurmaq lazım deyil.

Beləliklə requests.log kiçik iş izi olaraq qalır: müzakirənin lazımi dönüşünü tapmağa kömək edir, amma özünü nə layihənin ehtiyat nüsxəsi, nə də tapşırığın bitdiyinin sübutu kimi qələmə vermir. Jurnal dürüst qurulduqda, ona doğrudan da qayıtmaq istəyi yaranır.