Память AI между сессиями: append-only JSONL-журналы для решений, ошибок и идей

Claude в каждой новой сессии — чистый лист. Что бы вы ни обсудили в прошлый раз, какое бы решение ни приняли, какую бы ошибку ни разобрали — следующая сессия об этом не помнит. Каждый раз вы либо заново объясняете контекст, либо принимаете что часть знания теряется.

Я решил это просто: завёл три файла .jsonl в стандартизованной директории. В них хранятся решения, ошибки и идеи. Файлы автоматически подгружаются в начале сессии. AI помнит между сессиями.

Этот пост — про устройство этой памяти, почему именно append-only JSONL, и как она интегрируется в ежедневную работу.

Table of contents

Проблема: amnesia AI между сессиями

Без структурированной памяти AI работает в режиме “пятиминутки”. Каждая сессия — новый разговор с человеком, который не помнит:

• Что вы решили в прошлый раз и почему
• Какие подходы уже пробовали и отбросили
• Какие ошибки случались и как их теперь не повторять
• Какие идеи в работе и какой у них приоритет

В результате — три повторяющихся проблемы:

1. Регрессия багов. Вы решили проблему месяц назад. Сегодня она появилась снова, и AI решает её с нуля, не зная что прошлое решение существовало
2. Споры по уже принятым решениям. Вы выбрали стек / архитектуру / подход. Через месяц AI предлагает “лучше переделать на X” — потому что не знает контекст того решения
3. Идеи теряются. Вы накидываете 20 идей в течение года — половину забываете. Хорошие идеи смешиваются с мусором, потому что нет места их фиксировать структурно

Решение: три JSONL-журнала

В ~/.claude/data/ лежат три файла:

• decisions.jsonl — архитектурные и технические решения с обоснованием
• failures.jsonl — что сломалось, root cause, что починило (предотвращение регрессий)
• ideas.jsonl — портфель идей со scoring rubric и cross-stream synthesis

Все три — append-only. Первая строка каждого файла — schema. Дальше каждая строка — отдельная запись.

При старте сессии AI читает свежие записи (последние 10-20) и понимает текущее состояние. Не нужно ничего объяснять.

decisions.jsonl — что записывать

Записываю когда:

• Сделал архитектурный выбор с неочевидным обоснованием
• Зафиксировал tech stack или процесс на длинную дистанцию
• Сменил подход — нужно зафиксировать почему

Минимальная схема одной записи:

{"date":"2026-05-24","topic":"cache-strategy","decision":"...","why":"...","alternatives_considered":["...","..."]}

Ключевое поле — why. Решение без обоснования через год выглядит произвольным. С обоснованием его легко проверить на актуальность (“этот аргумент ещё действителен?”).

Пример из моего файла:

{"date":"2026-04-15","topic":"subagent-model","decision":"явно передавать модель Sonnet/Haiku подагентам, не наследовать","why":"при наследовании main session Opus → все агенты Opus → квота сгорает в 15× быстрее","alternatives_considered":["наследование от parent","автоопределение по типу задачи"]}

Через месяц, если возникнет вопрос “почему мы тут явно указываем модель?” — ответ есть в файле. Не нужно вспоминать.

failures.jsonl — связь со skills

Это самый ценный файл из трёх. В нём хранятся причины и решения реальных ошибок:

{"date":"2026-04-08","fail":"добавил секцию в blueprint без grep — оказалось уже была","root_cause":"забыл проверить существующее содержимое перед append","fix":"создан skill blueprint-grep-before-append с обязательным pre-step grep"}

Цикл такой:

1. Ошибка случилась — записал в failures.jsonl
2. Случилась повторно — задумался “почему я не предотвратил?”
3. На третий раз — создал skill с обязательным правилом

Этот цикл я описывал в посте про skills. failures.jsonl — это сырьё для skills. Skill — это формализованное правило, родившееся из конкретных fail-ов.

Через год работы у вас есть каталог собственных ошибок — самое ценное знание о вашей рабочей среде. Никакая статья в интернете этого не даст.

ideas.jsonl — портфель с scoring

В моём ideas.jsonl сейчас 13 проработанных идей продуктов и направлений. Каждая идея — отдельная запись со scoring (5 критериев × 5 уровней) и stream (категория применения).

{"id":"idea-009","title":"...","stream":"helping-pro","scores":{"alignment":4,"market":3,"feasibility":4,"capability":5,"momentum":3},"total":19,"status":"active"}

stream — категория идеи (личные инструменты, продукты для помогающих профессий, технологии, B2B-сервисы). Это позволяет видеть распределение портфеля между категориями и не пропускать перекосы.

total — сумма scores. Минимальный порог для “взять в работу” — например, 15/25. Ниже — отправляется в “наблюдение”.

Что это даёт: новый материал (статья, разговор, наблюдение) проверяется на резонанс со всеми активными идеями. Если 3+ источника складываются в новую идею — это сильный сигнал.

Append-only: почему нельзя редактировать прошлое

Главное правило всех трёх файлов: никаких правок прошлых записей. Только новые строки.

Зачем:

• История важна для AI. Если решение от 2025 года было такое, а потом я передумал — AI должен видеть оба решения и эволюцию. Перезапись скрывает контекст
• Регрессии. Если я удалю запись о ошибке “после исправления” — через год при повторной ошибке AI не найдёт прошлый fix. Будет решать заново
• Не врать себе. Append-only делает невозможным “тихо переписать прошлую идею под новые обстоятельства”. Если идея провалилась — это останется в файле, и я буду помнить об этом при следующей оценке

Если запись устарела или неверна — добавляется новая запись с пометкой corrects или supersedes:

{"date":"2026-05-01","corrects":"2026-03-15-decision-X","new_decision":"...","why_changed":"..."}

Схема в первой строке

Первая строка каждого .jsonl-файла — schema. Это документация и контракт для AI:

# decisions.jsonl
# Schema: {date: ISO date, topic: string, decision: string, why: string, alternatives_considered?: string[]}
# Append-only. Не редактировать прошлые записи. Корректировки — новой записью с полем `corrects`.

AI при чтении файла видит схему первой и понимает структуру. Если я добавляю новое поле в записях — обновляю схему в первой строке.

Интеграция в workflow

В AGENTS.md (или эквивалентном файле) у меня есть правила:

## Data layers (cumulative knowledge)

Persistent project-spanning data lives in `~/.claude/data/*.jsonl`.

Read recent entries (last 10-20 lines) when starting work on a related project,
to understand current state without re-explaining.

Write a new entry when:
- making a meaningful decision (decisions.jsonl)
- fixing a non-trivial bug (failures.jsonl)
- capturing an idea worth remembering (ideas.jsonl)

Never overwrite — only append.

Это означает что:

• При старте сессии AI читает свежие записи
• При значимом событии AI предлагает добавить запись (я подтверждаю)
• При повторной проблеме AI проверяет failures.jsonl на наличие прошлого решения

Workflow становится самоподдерживающимся: каждая решённая проблема превращается в защиту от регрессии.

Альтернативы (vector DB, MCP servers) и почему JSONL

Естественный вопрос: почему .jsonl файлы, а не vector database или MCP server?

Vector DB (Pinecone, Weaviate, ChromaDB):

• Преимущество: семантический поиск по большому корпусу
• Недостатки: инфраструктура, цена, latency, абстракция между мной и данными
• Не нужно для моего объёма (сотни записей, не миллионы)

MCP servers для памяти:

• Преимущество: декларативная интеграция с Claude
• Недостатки: ещё один слой абстракции, сложнее дебажить
• Подходит для большой команды, у меня — overkill

JSONL-файлы:

• Текстовые, читаемые глазом, версионируемые в git
• Никакой инфраструктуры
• Полный контроль над структурой
• AI читает их нативно, без специальных интеграций
• Можно делать grep, jq, скрипты на стороне

Для personal stack (один человек, до 10-100 записей в каждом файле) JSONL — простейший рабочий вариант. Когда упрусь в лимиты — рассмотрю vector DB. Сейчас — нет повода.

Чек-лист: запустить data layers у себя

• Создайте директорию ~/.claude/data/ (или .claude/data/ в проекте)
• Создайте три файла: decisions.jsonl, failures.jsonl, ideas.jsonl
• В первой строке каждого — schema-комментарий
• В AGENTS.md (или эквивалентном) — добавьте раздел “Data layers” с правилами что/когда записывать
• Не пишите записи “впрок” — только когда действительно есть решение / fail / идея
• Никогда не редактируйте старые записи — только append с пометкой supersedes/corrects

Заключение

Память AI между сессиями — это архитектурная задача, не “магия модели”. Решается просто: три текстовых файла с правилом append-only.

Через 3-6 месяцев работы у вас есть журналы накопленного знания — то, что у AI-инженеров отсутствует by design. Это превращает работу с AI из “разовых задач” в систему, которая накапливает интеллект со временем.

Главное правило: никаких правок прошлых записей. Append-only — это не ограничение, это фича. Она делает память честной и полезной для будущего вас.

Если у вас сейчас нет journal-файлов и AI каждую сессию начинает “с нуля” — заведите хотя бы failures.jsonl. Через месяц у вас будет личный каталог типичных ошибок, который сам по себе стоит времени на ведение.