Jurnalul cererilor Claude Code

Mi s-a întâmplat de mai multe ori: seara, împreună cu echipa, am trecut prin câteva variante ale unui bloc, iar dimineața cineva întreabă de ce titlul a devenit mai scurt. În conversație sunt zeci de mesaje, în memorie rămâne ceva de genul "parcă fundalul era deschis la culoare", iar decizia exactă se pierde printre modificări.

În astfel de momente ajută requests.log. Este o urmă externă scurtă a lucrului, pe care o puteți deschide într-un editor obișnuit și citi de sus în jos. Nu îl apreciez pentru numărul de linii, ci pentru faptul că leagă cererea de ceea ce s-a decis efectiv să rămână.

De ce e nevoie de o urmă externă

De-a lungul anilor de lucru m-am obișnuit să separ patru lucruri: cererea, decizia, conversația și versiunea salvată a fișierului. Ele răspund la întrebări diferite, deși în timpul unei singure sesiuni se contopesc ușor într-o poveste neclară.

Jurnalul funcționează ca un indicator: vă întoarce la momentul potrivit și la cuvintele exacte. Codul în sine nu îl reface. Dacă trebuie să vedeți versiunea salvată a paginii, uitați-vă la fișiere și la istoricul versiunilor proiectului.

Pe schemă se vede bine diferența importantă la analiza jurnalului. Lanțul de sus arată desfășurarea lucrului, cel de jos - ce rămâne în jurnal. Linia automată apare înainte de rezultat; nota despre decizie apare doar după verificare. Una nu o înlocuiește pe cealaltă.

Din ce e formată o înregistrare utilă

Vă arăt pe trei variante de înregistrare. În proiecte reale le-am întâlnit pe toate.

gata

O astfel de linie e aproape inutilă: nu se știe cine a făcut ce, când și la ce sarcină se referă acest "gata".

Utilizator: Fă titlul cardului mai scurt...
Claude: Bine, mai întâi mă uit la componentă...
Utilizator: Și micșorează spațierea...
Claude: Am corectat...

Iar aici e deja prea mult pentru o căutare rapidă. Fluxul complet e bun în istoricul conversației, dar un jurnal separat se transformă repede într-o copie incomodă a acesteia. Am încercat așa, apoi am pierdut timp derulând.

2026-09-08T14:32:11+03:00 | prompt_submitted | actor=user | ref=card-header | text="Redu titlul cardului la o singură linie"
2026-09-08T14:41:06+03:00 | decision_recorded | actor=user | ref=card-header | text="Titlu scurt acceptat, dimensiune 24 px"

A treia variantă îmi place cel mai mult: în ea rămân un fapt scurt, ora cu fusul orar, autorul și eticheta ref, care leagă liniile. Numele câmpurilor de aici sunt inventate pentru proiectul didactic. Acesta este formatul fișierului nostru, nu o schemă obligatorie a Claude Code. În acest exemplu, etichetele ref au fost adăugate manual la liniile legate. Hook-ul nu ghicește la ce bloc se referă cererea: evenimentul de bază UserPromptSubmit nu conține o astfel de etichetă semantică. Dacă nu există câmpul de legătură, în jurnalul dumneavoastră tot se poate căuta după o frază exactă.

Ce se știa în momentul înregistrării

Linia prompt_submitted spune exact un lucru: în sesiune a sosit această cerere, iar hook-ul a înregistrat-o. De obicei e textul dumneavoastră, dar nu întotdeauna. UserPromptSubmit se declanșează și la o nouă tură a /loop, și la raportul unui subagent din fundal, și la un mesaj venit din altă sesiune, așa că actor=user în formatul nostru e o presupunere a exemplului didactic. Din ea nu rezultă că Claude Code a modificat pagina, că verificarea a trecut sau că rezultatul a plăcut tuturor.

Rezultatul merită înregistrat abia după ce a devenit cunoscut. În exemplul nostru aceasta este o notă separată, după ce pagina a fost verificată. Dacă în formatul dumneavoastră există câmpurile result sau error, completați-le cu fapte observate, nu cu o presupunere despre rezultatul viitor al sarcinii.

Unde notați decizia luată

Decizia apare doar atunci când cineva a consemnat-o explicit. În exemplul de mai sus, linia a fost adăugată de utilizator după ce a văzut pagina. Autorul este indicat în actor, legătura cu cererea o păstrează ref=card-header.

Nota poate fi manuală, și asta e normal. Înregistrarea automată salvează intrarea, iar omul confirmă sensul rezultatului. Linia "gata" fără autor și fără legătură nu merită încredere.

Citim jurnalul cererilor

Să analizăm un jurnal mic de cinci linii. Tocmai cu astfel de fragmente scurte încep de obicei când trebuie să reconstitui cursul unei decizii.

2026-09-08T14:32:11+03:00 | prompt_submitted | actor=user | ref=card-header | text="Redu titlul cardului la o singură linie"
2026-09-08T14:36:20+03:00 | prompt_submitted | actor=user | ref=card-header | text="Arată două variante: 24 px și 28 px"
2026-09-08T14:41:06+03:00 | decision_recorded | actor=user | ref=card-header | text="Titlu scurt acceptat, dimensiune 24 px"
2026-09-08T15:03:44+03:00 | prompt_submitted | actor=user | ref=card-shadow | text="Fă umbra cardului mai moale"
2026-09-08T15:08:17+03:00 | prompt_submitted | actor=user | ref=card-header | text="Încearcă o culoare mai închisă pentru titlu"

Imaginați-vă că trebuie să găsiți ultima decizie luată despre formatul titlului. Începeți cu o căutare după card-header în editor. Rezultă patru linii. Ultima conține o nouă dorință despre culoare, dar nu o decizie. Prin urmare, concluzia se bazează pe linia de la 14:41:06: a fost acceptat un titlu scurt, cu dimensiunea 24 px.

Ordinea mea de lucru la citire este simplă:

1. Mai întâi formulez întrebarea: caut o cerere, o decizie sau o eroare observată.
2. Găsesc eticheta comună, numele componentei sau fraza exactă.
3. Păstrez doar înregistrările de tipul potrivit și le citesc în ordine cronologică.
4. Numesc liniile care confirmă concluzia. Tot restul îl las cinstit necunoscut.

O astfel de analiză se poate face și fără a porni Claude Code. Este un obicei util: mai întâi confruntați singur concluzia cu fișierul, abia apoi încredințați aceeași muncă agentului.

Când decizia nu e în jurnal

Iar acum să scoatem linia de la 14:41:06. Rămân doar cererea de a arăta două dimensiuni și dorința ulterioară de a schimba culoarea. Ce dimensiune a fost acceptată? Jurnalul nu răspunde.

În astfel de situații e foarte tentant să alegeți 24 px, pentru că e prima variantă propusă. Nu merită. Cererea arată intenția de a verifica variante, nu rezultatul alegerii. Concluzia cinstită aici este una singură: decizia luată despre dimensiune nu este consemnată în jurnal.

Bifurcația nu depinde de ordinea dorințelor, ci de tipul înregistrării găsite. Există o notă explicită despre decizie - concluzia poate fi confirmată. Au rămas doar cereri - consemnăm necunoscutul și nu umplem golul cu o presupunere. Această reținere economisește până la urmă mult timp.

Ce lăsați în afara jurnalului

Nu încerc să transform un jurnal util într-un depozit pentru orice. Conținutul unei înregistrări merită ales în funcție de întrebarea pe care va trebui să o analizați mai târziu. Pentru găsirea deciziilor de obicei sunt suficiente ora, tipul evenimentului, autorul, eticheta de legătură și un text scurt.

• Nu copiați chei, token-uri, conținutul fișierului .env și date personale.
• Nu transferați integral răspunsurile serviciilor externe, dacă e nevoie doar de status sau de identificatorul operației.
• Lăsați promptul complet doar acolo unde chiar e nevoie. În acest articol e complet doar pentru că exemplul e fictiv și scurt.
• Verificați periodic dimensiunea fișierului și utilitatea înregistrărilor vechi. Nu există un termen unic de păstrare pentru toate proiectele.

Trunchierea liniei la o sută de caractere îmbunătățește lizibilitatea, dar nu elimină automat secretele. Un token scurt încape perfect și în primele o sută de caractere. Decideți mai întâi ce date sunt în general admise pentru înregistrare. Merită să începeți exact cu această regulă, nu cu lungimea liniei.

Cum analizăm jurnalul împreună cu Claude Code

Claude Code reconstituie bine succesiunea temporală și găsește rapid liniile legate. Dar pentru asta trebuie să citească explicit fișierul: prezența requests.log în proiect nu înseamnă de la sine că conținutul lui se află deja în context.

Dați agentului o sarcină concretă:

Citește requests.log. Găsește ultima decizie explicit acceptată
despre dimensiunea titlului cardului (card-header). Indică înregistrările pe care te bazezi.
Dacă în jurnal există doar o dorință, spune asta direct.
Enumeră separat ce a rămas necunoscut.

Un răspuns bun va separa faptele de concluzie: va cita ora, tipul evenimentului și textul deciziei, apoi va enumera întrebările fără confirmare. Confruntați aceste referințe cu liniile sursă. Eroarea se vede mai ales când agentul numește ultima cerere "varianta acceptată".

Pentru jurnalul didactic curent, răspunsul ar fi așa: decizia despre dimensiune este confirmată de înregistrarea 2026-09-08T14:41:06+03:00; mai târziu a apărut o cerere despre o culoare mai închisă, dar decizia despre culoare rămâne necunoscută. Tocmai acest tip de răspuns îl consider de încredere: nu promite mai mult decât este în fișier.

• Hook-ul salvează cererea înainte de procesarea ei, deci această înregistrare nu confirmă rezultatul.
• O notă separată leagă decizia acceptată de cerere prin oră sau etichetă.
• Căutarea începe de la o întrebare concretă și se termină cu o referință la liniile sursă.
• Dacă nu există confirmare, jurnalul lasă un gol. Nu trebuie completat prin presupuneri.

Astfel requests.log rămâne o urmă de lucru mică: ajută să găsiți momentul potrivit al discuției, dar nu se dă nici drept copie de siguranță a proiectului, nici drept dovadă a unei sarcini finalizate. Când jurnalul e ținut cinstit, chiar vă vine să reveniți la el.