# Рабочий процесс документации для 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 говорит как, воспоминания говорят почему.