Журнал запитів Claude Code

У мене таке траплялося не раз: увечері ми з командою перебрали кілька варіантів блоку, а вранці хтось запитує, чому заголовок став коротшим. У листуванні десятки повідомлень, у пам'яті лишається щось на кшталт "здається, фон був світлим", а точне рішення розчиняється між правками.

У такі моменти виручає requests.log. Це короткий зовнішній слід роботи, який можна відкрити в звичайному редакторі і прочитати згори донизу. Я ціную його, чесно кажучи, не за кількість рядків, а за можливість зв'язати запит з тим, що справді вирішили лишити.

Навіщо потрібен зовнішній слід

За роки роботи я звик розділяти чотири речі: запит, рішення, листування і збережену версію файлу. Вони відповідають на різні запитання, хоча під час однієї сесії легко зливаються в одну неясну історію.

Джерело	Що з нього можна дізнатися	Чого воно не доводить
`requests.log`	Що попросили і коли з'явився запис	Що зміну виконано і ухвалено
Позначка про рішення	Який варіант обрали і хто це позначив	Який вигляд має збережений файл зараз
Історія листування	Контекст обговорення і відповіді	Що потрапило в поточну версію проєкту
Система контролю версій	Які файли і рядки було збережено	Чому обрали саме цей варіант

Журнал працює як покажчик: повертає до потрібного моменту і точних слів. Сам код він не відновлює. І все. Якщо треба побачити збережену версію сторінки, дивіться файли й історію версій проєкту.

Що записує Claude Code

Тут є важлива межа, на якій я бачив чимало хибних висновків. Hook події UserPromptSubmit отримує текст у полі prompt ще до того, як Claude Code обробить запит. Такий рядок підтверджує лише відправлення тексту, а результат завдання в цей момент ще невідомий.

Запит і ухвалене рішення потрапляють у зовнішній слід у різні моменти

На схемі добре видно різницю, важливу під час розбору лога. Верхній ланцюжок показує хід роботи, нижній - те, що лишається в журналі. Автоматичний рядок виникає до результату; позначка про рішення з'являється лише після перевірки. Один не замінює інший.

З чого складається корисний запис

Покажу на трьох варіантах запису. У реальних проєктах мені траплявся кожен з них.

готово

Такий рядок майже марний: незрозуміло, хто що зробив, коли і до якого завдання належить це "готово".

Користувач: Зроби заголовок картки коротшим...
Claude: Добре, спочатку подивлюся компонент...
Користувач: І відступ зменш...
Claude: Виправив...

А тут уже забагато для швидкого пошуку. Повний потік хороший в історії розмови, але окремий журнал швидко перетворюється на її незручну копію. Пробував так робити, потім сам же витрачав час на прокрутку.

2026-09-08T14:32:11+03:00 | prompt_submitted | actor=user | ref=card-header | text="Скороти заголовок картки до одного рядка"
2026-09-08T14:41:06+03:00 | decision_recorded | actor=user | ref=card-header | text="Ухвалено короткий заголовок, розмір 24 px"

Третій варіант мені подобається найбільше: у ньому лишаються короткий факт, час з часовим поясом, автор і мітка ref, що зв'язує рядки. Назви полів тут вигадані для навчального проєкту. Це формат нашого файлу, а не обов'язкова схема Claude Code. У цьому розборі мітки ref додані вручну до пов'язаних рядків. Hook не вгадує, до якого блоку належить запит. Базова подія UserPromptSubmit просто не містить такої смислової мітки. Якщо поля зв'язку немає, у вашому журналі все одно можна шукати за точною фразою.

Що було відомо в момент запису

Рядок prompt_submitted каже тільки одне: у сесію надійшов такий запит, а hook його записав. Зазвичай це ваш текст, але не завжди. UserPromptSubmit спрацьовує і на черговий круг /loop, і на звіт фонового субагента, і на повідомлення з іншої сесії, тож actor=user у нашому форматі - припущення навчального прикладу. З нього не випливає, що Claude Code змінив сторінку, перевірка пройшла або результат усім сподобався.

Результат варто записувати після того, як він став відомим. У нашому прикладі це окрема позначка після перегляду сторінки. Якщо у вашому форматі є поля result або error, заповнюйте їх спостережуваними фактами, а не припущенням про майбутній результат завдання.

Де позначити ухвалене рішення

Рішення з'являється лише тоді, коли хтось явно його зафіксував. У прикладі вище рядок додав користувач після перегляду сторінки. Автор вказаний у actor, зв'язок із запитом зберігає ref=card-header.

Позначка може бути ручною, і це нормально. Автоматичний запис зберігає вхід, а людина підтверджує сенс результату. Рядку "готово" без автора і прив'язки довіряти не варто.

Читаємо журнал запитів

Розберемо невеликий журнал з п'яти рядків. Саме з таких коротких фрагментів я зазвичай і починаю, коли треба відновити хід рішення.

2026-09-08T14:32:11+03:00 | prompt_submitted | actor=user | ref=card-header | text="Скороти заголовок картки до одного рядка"
2026-09-08T14:36:20+03:00 | prompt_submitted | actor=user | ref=card-header | text="Покажи два варіанти: 24 px і 28 px"
2026-09-08T14:41:06+03:00 | decision_recorded | actor=user | ref=card-header | text="Ухвалено короткий заголовок, розмір 24 px"
2026-09-08T15:03:44+03:00 | prompt_submitted | actor=user | ref=card-shadow | text="Зроби тінь картки м'якшою"
2026-09-08T15:08:17+03:00 | prompt_submitted | actor=user | ref=card-header | text="Спробуй темніший колір заголовка"

Уявіть, що вам треба знайти останнє ухвалене рішення про формат заголовка. Почніть з пошуку за card-header у редакторі. Вийде чотири рядки. Останній містить нове побажання про колір, але не рішення. Тому висновок спирається на рядок о 14:41:06: ухвалено короткий заголовок розміром 24 px.

Мій робочий порядок читання простий:

Спочатку формулюю запитання: шукаю запит, рішення або спостережувану помилку.
Знаходжу спільну мітку, ім'я компонента або точну фразу.
Лишаю записи потрібного типу і читаю їх за часом.
Називаю рядки, які підтверджують висновок. Усе інше чесно лишаю невідомим.

Такий розбір можна зробити і без запуску Claude Code. Це корисна звичка: спочатку самому звірити висновок з файлом, а вже потім доручати ту саму роботу агенту.

Коли рішення в журналі немає

А тепер приберемо рядок з 14:41:06. Лишаться прохання показати два розміри і пізніше побажання змінити колір. Який розмір ухвалили? Журнал не відповідає.

У таких місцях дуже хочеться обрати 24 px, бо це перший запропонований варіант. Не варто. Запит показує намір перевірити варіанти, але не підсумок вибору. Чесний висновок тут один: ухвалене рішення про розмір у журналі не зафіксовано.

Останній запит не стає рішенням тільки тому, що він останній

Розвилка залежить не від порядку побажань, а від типу знайденого запису. Є явна позначка про рішення - висновок можна підтвердити. Лишилися тільки запити - фіксуємо невідоме і не заповнюємо прогалину здогадкою. Ця стриманість зрештою економить багато часу.

Просіть підставу

Коли журнал розбирає Claude Code, я прошу назвати точні записи, на яких тримається висновок. Якщо підтверджувального рядка немає, це має потрапити в список невідомого, без здогадки про успішний результат.

Що лишати за межами лога

Я не намагаюся перетворити корисний журнал на сховище всього підряд. Склад запису варто обирати з огляду на питання, яке потім усе одно доведеться розбирати. Для пошуку рішень зазвичай достатньо часу, типу події, автора, мітки зв'язку і короткого тексту.

Не копіюйте ключі, токени, вміст .env і особисті дані.
Не переносьте цілком відповіді зовнішніх сервісів, якщо потрібен лише статус або ідентифікатор операції.
Повний prompt лишайте тільки там, де це справді потрібно. У цій статті він повний лише тому, що приклад вигаданий і короткий.
Періодично перевіряйте розмір файлу і користь старих записів. Єдиного терміну зберігання для всіх проєктів немає.

Обрізання рядка до ста символів покращує читабельність, але не видаляє секрети автоматично. Короткий токен чудово вміщається і в перші сто символів. Спочатку вирішіть, які дані взагалі допустимо записувати. Починати варто якраз із цього правила, а не з довжини рядка.

Як розбирати журнал разом з Claude Code

Claude Code добре збирає часову послідовність і швидко знаходить пов'язані рядки. Але для цього йому потрібно явно прочитати файл: наявність requests.log у проєкті сама по собі не означає, що його вміст уже перебуває в контексті.

Тут просто дайте агенту конкретне завдання:

Прочитайте requests.log. Знайдіть останнє явно ухвалене рішення
про розмір заголовка картки (card-header). Вкажіть записи, на які спираєтеся.
Якщо в журналі є лише побажання, так і скажіть.
Окремо перелічіть, що лишилося невідомим.

Гарна відповідь відокремить факти від висновку: процитує час, тип події і текст рішення, а потім перелічить питання без підтвердження. Звірте ці посилання з вихідними рядками. Помилка особливо помітна, коли агент називає останнє прохання "ухваленим варіантом".

Для поточного навчального журналу відповідь буде такою: рішення про розмір підтверджує запис 2026-09-08T14:41:06+03:00; пізніше з'явився запит про темніший колір, але ухвалене рішення про колір невідоме. Саме таку відповідь я вважаю надійною: вона не обіцяє більше, ніж є у файлі.

Hook зберігає запит до його обробки, тому цей запис не підтверджує результат.
Окрема позначка зв'язує ухвалене рішення із запитом за часом або міткою.
Пошук починається з конкретного запитання і закінчується посиланням на вихідні рядки.
Якщо підтвердження немає, журнал лишає прогалину. Додумувати її не треба.

Так requests.log лишається невеликим робочим слідом: допомагає знайти потрібний поворот обговорення, але не вдає з себе ні резервної копії проєкту, ні доказу виконаного завдання. Коли лог влаштований чесно, до нього справді хочеться повертатися.