# Робочий процес документації для LLM
SUMMARY: Як LLM-агент має документувати свою роботу: спогади, worklog, changelog та повідомлення комітів.

KEY CONTEXT:
Документуй ПІД ЧАС РОБОТИ, а не в кінці сесії. Три шари:
1) POST /memory для кожного сталого факту, рішення, помилки або облікових даних.
2) POST /worklog/:task_id для прогресу за задачею (start/progress/error/close).
3) Звичайний changelog + повідомлення комітів для змін коду.
Факт, який не збережено, не стався — наступна сесія про нього не знає.

Робочий процес документації для LLM
LLM-агенти за замовчуванням амнезики: кожна сесія починається з нуля. Єдине, що переживає межу сесії — те, що ви зберегли в зовнішній системі. Документація — це не бюрократія, це спосіб залишатися собою між сесіями.
Три шари
| Шар | Де | Що | Коли |
|---|---|---|---|
| Memory |  | сталі факти, рішення, помилки, облікові дані | у момент, коли ви це дізналися |
| Worklog |  | прогрес задачі, помилки, віхи | після кожного значного кроку |
| Changelog | репозиторний  + commit | видимі користувачу зміни | з кожною зміною коду |
Шар 1: Спогади
Зберігайте спогад коли факт новий, а не в кінці сесії. Сесії падають; вікна контексту переповнюються; «запишу потім» — це факт, який ніколи не стався.
Вибирайте правильну категорію:
-  — хто ви, ваша роль, ваші брати й сестри
-  — стан і рішення проєкту
-  — що пішло не так і урок (найцінніша категорія)
-  — як щось робиться (списки кроків, команди)
-  — токени, ендпоінти, шляхи (ніколи в чат чи код)
-  — стан сесії, який варто перенести далі
Використовуйте  чесно (1.0 = перевірено, 0.5 = припущення) і тегуйте послідовно — спогади знаходять за тегами й ключами, а не за прозою.
[CODE BLOCK]
Шар 2: Worklog
Worklog — це журнал прогресу однієї задачі. Він відповідає на питання «що саме відбувалося під час розв'язання?» для кожного майбутнього читача — включно з майбутнім «ви».
[CODE BLOCK]
Емпіричне правило: один запис на рішення чи відкриття, а не на годину. Помилки потрапляють у журнал негайно — пізніше це найцінніші записи.
Шар 3: Changelog і коміти
Зміни коду — теж документація:
- Повідомлення коміту: що змінилося і чому, з посиланням на задачу/користувача в дужках. Перший рядок до 72 символів, імператив.
- CHANGELOG.md: один запис на видиме користувачу зміну, згруповане як Added / Changed / Fixed / Removed, з версією та датою.
Фікс без запису в changelog невидимий для всіх, хто не читав диф.
Анти-патерни
- Дампи пам'яті в кінці сесії. Контекст тоді вже втрачено — зберігайте безперервно.
- Спогади прозою. «Може бути, база даних була десь у конфігу» — це незнаходимо. Використовуйте точні ключі, теги й структуру вмісту.
- Тихі ретраї. Кожна невдала спроба потрапляє в worklog; інакше наступний агент її повторить.
- Чат як сховище. Історія чату — не база знань; витягуйте сталі факти в спогади.
Повний цикл
1. Дізналися щось →  (зараз)
2. Почали задачу → 
3. Кожен крок/помилка → 
4. Змінили код → commit + запис у CHANGELOG
5. Завершили → 
6. Позначили задачу виконаною → 
Наступна сесія — або агент-сиблінг, який взяв вашу задачу, — зможе все відновити: список задач каже що, worklog каже як, спогади кажуть чому.