Deník požadavků Claude Code

Mně se to už stalo víckrát: večer jsme s týmem prošli několik variant bloku a ráno se někdo ptá, proč se nadpis zkrátil. V konverzaci jsou desítky zpráv, v paměti zůstane něco jako "myslím, že pozadí bylo světlé", a přesné rozhodnutí se rozplyne mezi úpravami.

V takových chvílích pomůže requests.log. Je to krátká vnější stopa práce, kterou lze otevřít v obyčejném editoru a přečíst odshora dolů. Necením si ho za počet řádků, ale za to, že umí spojit požadavek s tím, co jsme se skutečně rozhodli ponechat.

K čemu je vnější stopa dobrá

Za ty roky jsem si zvykl oddělovat čtyři věci: požadavek, rozhodnutí, konverzaci a uloženou verzi souboru. Odpovídají na různé otázky, i když se během jedné relace snadno slijí do jednoho nejasného příběhu.

Zdroj	Co se z něj dá zjistit	Co nedokazuje
`requests.log`	Co se žádalo a kdy záznam vznikl	Že změna byla provedena a přijata
Poznámka o rozhodnutí	Jaká varianta byla vybrána a kdo to zaznamenal	Jak uložený soubor vypadá teď
Historie konverzace	Kontext diskuze a odpovědi	Co se dostalo do aktuální verze projektu
Systém pro správu verzí	Které soubory a řádky byly uloženy	Proč byla vybrána právě tato varianta

Deník funguje jako ukazatel: vrátí vás ke správnému okamžiku a přesným slovům. Samotný kód neobnoví. Pokud potřebujete vidět uloženou verzi stránky, podívejte se na soubory a historii verzí projektu.

Co zaznamenává Claude Code

Tady je důležitá hranice, u které jsem viděl řadu chybných závěrů. Hook události UserPromptSubmit dostane text v poli prompt ještě předtím, než Claude Code požadavek zpracuje. Takový řádek potvrzuje odeslání textu, ale výsledek úkolu je v tu chvíli stále neznámý.

Požadavek a přijaté rozhodnutí se dostávají do vnější stopy v různých okamžicích

Na schématu je dobře vidět rozdíl, který je důležitý při rozboru deníku. Horní řetězec ukazuje průběh práce, dolní to, co zůstává v deníku. Automatický řádek vzniká ještě před výsledkem; poznámka o rozhodnutí se objeví teprve po kontrole. Jedno nenahrazuje druhé.

Z čeho se skládá užitečný záznam

Ukážu to na třech variantách záznamu. V reálných projektech jsem se setkal s každou z nich.

hotovo

Takový řádek je skoro k ničemu: není jasné, kdo co udělal, kdy a k jakému úkolu se toto "hotovo" vztahuje.

Uživatel: Udělej nadpis karty kratší...
Claude: Dobře, nejdřív se podívám na komponentu...
Uživatel: A zmenši odsazení...
Claude: Opraveno...

A tady už je toho zase moc na rychlé vyhledávání. Celý proud se hodí do historie konverzace, ale samostatný deník se rychle stane její nepohodlnou kopií. Zkoušel jsem to takhle a pak sám ztrácel čas scrollováním.

2026-09-08T14:32:11+03:00 | prompt_submitted | actor=user | ref=card-header | text="Zkrať nadpis karty na jeden řádek"
2026-09-08T14:41:06+03:00 | decision_recorded | actor=user | ref=card-header | text="Přijat krátký nadpis, velikost 24 px"

Třetí varianta se mi líbí nejvíc: zůstává v ní krátký fakt, čas s časovým pásmem, autor a značka ref, která propojuje řádky. Názvy polí jsou tady vymyšlené pro tento výukový projekt. Je to formát našeho souboru, ne povinné schéma Claude Code. V tomto rozboru byly značky ref přidány ručně k souvisejícím řádkům. Hook neuhádne, ke kterému bloku požadavek patří: základní událost UserPromptSubmit takovou sémantickou značku neobsahuje. Pokud propojovací pole chybí, ve vašem deníku se přesto dá hledat podle přesné fráze.

Co bylo v okamžiku záznamu známé

Řádek prompt_submitted říká přesně jednu věc: do relace přišel takový požadavek a hook ho zaznamenal. Obvykle je to váš text, ale ne vždy. UserPromptSubmit se spouští i při dalším kole /loop, při hlášení subagenta na pozadí i při zprávě z jiné relace, takže actor=user je v našem formátu předpoklad cvičného příkladu. Z toho neplyne, že Claude Code stránku změnil, kontrola dopadla úspěšně nebo se výsledek všem líbil.

Výsledek stojí za to zaznamenat až poté, co je skutečně známý. V našem příkladu je to samostatná poznámka po prohlédnutí stránky. Pokud má váš formát pole result nebo error, vyplňujte je pozorovanými fakty, ne domněnkou o budoucím výsledku úkolu.

Kam zaznamenat přijaté rozhodnutí

Rozhodnutí se objeví teprve tehdy, když ho někdo výslovně zaznamená. V příkladu výše přidal řádek uživatel po prohlédnutí stránky. Autor je uveden v actor, spojení s požadavkem drží ref=card-header.

Poznámka může být ruční, a to je v pořádku. Automatický záznam ukládá vstup a člověk potvrzuje smysl výsledku. Řádku "hotovo" bez autora a bez vazby se nevyplatí důvěřovat.

Čtení deníku požadavků

Rozebereme malý deník z pěti řádků. Právě od takových krátkých úryvků obvykle začínám, když potřebuji zrekonstruovat průběh rozhodnutí.

2026-09-08T14:32:11+03:00 | prompt_submitted | actor=user | ref=card-header | text="Zkrať nadpis karty na jeden řádek"
2026-09-08T14:36:20+03:00 | prompt_submitted | actor=user | ref=card-header | text="Ukaž dvě varianty: 24 px a 28 px"
2026-09-08T14:41:06+03:00 | decision_recorded | actor=user | ref=card-header | text="Přijat krátký nadpis, velikost 24 px"
2026-09-08T15:03:44+03:00 | prompt_submitted | actor=user | ref=card-shadow | text="Udělej stín karty měkčí"
2026-09-08T15:08:17+03:00 | prompt_submitted | actor=user | ref=card-header | text="Vyzkoušej tmavší barvu nadpisu"

Představte si, že potřebujete najít poslední přijaté rozhodnutí o formátu nadpisu. Začněte hledáním podle card-header v editoru. Vyjdou čtyři řádky. Poslední obsahuje nové přání ohledně barvy, ne rozhodnutí. Závěr se proto opírá o řádek z 14:41:06: byl přijat krátký nadpis o velikosti 24 px.

Můj pracovní postup čtení je jednoduchý:

Nejdřív si zformuluji otázku: hledám požadavek, rozhodnutí, nebo pozorovanou chybu.
Najdu společnou značku, název komponenty nebo přesnou frázi.
Ponechám záznamy potřebného typu a čtu je chronologicky.
Uvedu řádky, které závěr potvrzují. Všechno ostatní poctivě nechávám jako neznámé.

Takový rozbor jde udělat i bez spuštění Claude Code. Je to užitečný návyk: nejdřív si sám ověřit závěr proti souboru a teprve pak svěřit stejnou práci agentovi.

Když v deníku rozhodnutí chybí

Teď odstraníme řádek z 14:41:06. Zůstane žádost ukázat dvě velikosti a pozdější přání změnit barvu. Jaká velikost byla přijata? Deník neodpovídá.

V takových místech je velké pokušení vybrat 24 px, protože to je první nabízená varianta. Nedělejte to. Požadavek ukazuje záměr prověřit varianty, ne výsledek volby. Jediný poctivý závěr je: přijaté rozhodnutí o velikosti není v deníku zaznamenáno.

Poslední požadavek se nestává rozhodnutím jen proto, že je poslední

Větvení nezávisí na pořadí přání, ale na typu nalezeného záznamu. Existuje výslovná poznámka o rozhodnutí - závěr lze potvrdit. Zůstaly jen požadavky - zaznamenáme neznámé a mezeru nevyplňujeme domněnkou. Tato zdrženlivost nakonec ušetří hodně času.

Žádejte podklad

Když deník rozebírá Claude Code, žádám ho, aby uvedl přesné záznamy, o které se závěr opírá. Pokud chybí potvrzující řádek, patří to do seznamu neznámých věcí, bez domněnky o úspěšném výsledku.

Co ponechat mimo log

Nesnažím se z užitečného deníku udělat úložiště úplně všeho. Obsah záznamu je dobré volit podle otázky, kterou pak bude třeba řešit. Pro hledání rozhodnutí obvykle stačí čas, typ události, autor, propojovací značka a krátký text.

Nekopírujte klíče, tokeny, obsah .env ani osobní údaje.
Nepřenášejte celé odpovědi externích služeb, pokud potřebujete jen stav nebo identifikátor operace.
Celý prompt nechávejte jen tam, kde je to skutečně potřeba. V tomto článku je celý jen proto, že příklad je vymyšlený a krátký.
Občas zkontrolujte velikost souboru a přínos starých záznamů. Jednotná doba uchovávání pro všechny projekty neexistuje.

Zkrácení řádku na sto znaků zlepší čitelnost, ale automaticky neodstraní tajemství. Krátký token se do prvních sto znaků bez problémů vejde. Nejdřív rozhodněte, jaká data je vůbec dovoleno zaznamenávat. Začít je třeba právě tímto pravidlem, ne délkou řádku.

Jak rozebírat deník společně s Claude Code

Claude Code dobře skládá časovou posloupnost a rychle nachází související řádky. Musí ale nejdřív soubor výslovně přečíst: přítomnost requests.log v projektu sama o sobě neznamená, že je jeho obsah už v kontextu.

Zadejte agentovi konkrétní úkol:

Přečti requests.log. Najdi poslední výslovně přijaté rozhodnutí
o velikosti nadpisu karty (card-header). Uveď záznamy, o které se opíráš.
Pokud je v deníku jen přání, řekni to přímo.
Zvlášť vypiš, co zůstalo neznámé.

Dobrá odpověď oddělí fakta od závěru: ocituje čas, typ události a text rozhodnutí, a pak vyjmenuje otázky bez potvrzení. Tyto odkazy porovnejte s původními řádky. Chyba je obzvlášť patrná, když agent označí poslední žádost za "přijatou variantu".

Pro tento výukový deník bude odpověď taková: rozhodnutí o velikosti potvrzuje záznam 2026-09-08T14:41:06+03:00; později se objevil požadavek na tmavší barvu, ale přijaté rozhodnutí o barvě je neznámé. Právě takovou odpověď považuji za spolehlivou: neslibuje víc, než je v souboru.

Hook uloží požadavek ještě před jeho zpracováním, takže tento záznam výsledek nepotvrzuje.
Samostatná poznámka spojuje přijaté rozhodnutí s požadavkem podle času nebo značky.
Hledání začíná konkrétní otázkou a končí odkazem na původní řádky.
Pokud potvrzení chybí, deník ponechává mezeru. Domýšlet ji netřeba.

Tak zůstává requests.log malou pracovní stopou: pomáhá najít místo, kde diskuze změnila směr, ale nepředstírá, že je zálohou projektu nebo důkazem hotového úkolu. Když je deník vedený poctivě, člověk se k němu opravdu rád vrací.