Память проекта не должна принадлежать AI-сервису. Модель выполняет работу, но не владеет контекстом: тарифы и правила меняются, продукты закрываются, аккаунты блокируются. Если всё важное хранится отдельно, замена исполнителя остаётся технической задачей, а не потерей накопленного опыта.

Для меня это не теоретический риск. Долгое время личный контекст — предпочтительный стиль общения, раздражающие паттерны в ответах, цели — накапливался в истории одного сервиса. При первом переезде я вручную переносил системные промты в другой инструмент. Это заняло время, но данные сохранились. Позже аккаунт в новом сервисе заблокировали без объяснений. Доступ ко всему, что успело накопиться уже там, пропал за один день.

Вывод оказался неприятным и простым: информация внутри чужого аккаунта принадлежит мне лишь до тех пор, пока владелец сервиса разрешает её читать.

После этого я несколько раз менял устройство памяти. Сначала речь шла о личных настройках, затем тот же принцип распространился на проекты. Ниже — рабочая версия системы, которой я пользуюсь сейчас.

Память как обычные файлы

В основе — Markdown и Git. Здесь нет формата, принадлежащего конкретной модели или приложению. Папку может открыть Claude, GPT или другой агент, если у него есть доступ к файловой системе.

Контекст разделён на два слоя.

Личная память описывает устойчивые вещи: кто я, как со мной работать, какой стиль текста мне подходит и какие ответы раздражают. Агент читает её при первом входе в контур или когда нужен общий личный контекст; при продолжении уже известного проекта он сразу работает с проектными файлами. Этот слой меняется нечасто. Никакой специальной «настройки личности» для этого не требуется:

Это обычные текстовые документы. Агент обращается с ними так же, как с файлами проекта: открывает, читает и следует записанным ограничениям.

Проектная память создаётся отдельно для каждой работы. В ней зафиксированы назначение проекта, текущая точка, принятые решения и дальнейшие действия. Этот слой обновляется от сессии к сессии.

Переезд между провайдерами всё ещё требует один раз указать путь к папке. Но экспортировать чужую внутреннюю память или восстанавливать историю разговоров уже не приходится: новый инструмент получает тот же набор Markdown-файлов.

Эта схема уже работает у меня с разными агентами: каждый подключается к одной проектной памяти в Git-репозитории. При смене инструмента я передаю ему путь к файлам, а не расшифровку предыдущего разговора.

Почему встроенной памяти и базы заметок недостаточно

На первый взгляд ту же задачу решают память ChatGPT, проекты Claude, Notion или Wiki. Проблема у этих вариантов разная по форме, но одинаковая по результату: появляется зависимость от отдельной платформы.

Встроенный контекст AI-сервиса удобнее всего на старте. При этом он находится внутри аккаунта и подчиняется правилам провайдера. Пользователь не контролирует ни формат хранения, ни доступность данных после блокировки или закрытия продукта.

Notion и Wiki оставляют данные пользователю, но для прямой работы агента нужен коннектор. При смене AI-инструмента интеграцию приходится настраивать заново, а вместе с ней возникает ещё одна точка отказа.

У Markdown в Git нет такого посредника. Файл читается через файловую систему; отдельный API для каждого агента не нужен.

Векторный поиск и RAG-решения наподобие MemGPT выполняют другую функцию. Они находят подходящие фрагменты в большом объёме неструктурированного текста. Здесь задача иная: хранить актуальную правду о проекте в явном, переносимом виде. Если документов станет слишком много, поиск можно добавить поверх тех же файлов.

Структура растёт в три этапа

Полную схему не нужно разворачивать заранее. Новые элементы появляются тогда, когда простой вариант перестаёт справляться.

Начальный уровень — без агента

Для старта хватает трёх документов, даже если AI пока вообще не используется:

  • index.md объясняет назначение проекта, его связи и расположение материалов. Я ограничиваю его 60 строками.

  • state.md хранит текущий срез: активную задачу, следующий шаг и блокеры. Его потолок — 80 строк; в конце сессии файл переписывается.

  • backlog.md содержит незакрытые задачи и идеи, к которым нужно вернуться.

Это уже полезная проектная дисциплина. Если агент появится позже, он начнёт с тех же файлов — миграция структуры не потребуется.

Рабочий уровень с AI

При подключении агента добавляются документы, которые помогают ему действовать предсказуемо:

  • project.yaml — короткий машинно-читаемый паспорт со статусом и владельцем проекта. YAML остаётся понятным человеку и быстро разбирается программно.

  • instructions.md — локальные правила: например, не менять архитектурные решения незаметно или вести разработку только через ветку и ревью.

  • logs/ — журнал существенных сессий и сделанных шагов.

  • decisions/ — ADR с ответом на два вопроса: что выбрали и почему. Благодаря этому старые отвергнутые варианты не возвращаются как новые предложения.

  • prompts/implementation/ — постановки задач для агентов, которые должны пережить конкретный чат.

Уровень для выросшего проекта

Когда двух первых слоёв становится мало, могут появиться:

  • constitution.md с принципами, которые нельзя менять по ходу работы;

  • links/ со связями на код и соседние проекты;

  • specs/ с формальными спецификациями.

Папка проекта с агентом в итоге выглядит так:

Верхний уровень остаётся коротким, а детали разложены по папкам с понятной ролью.

Несколько проектов я группирую по типу: личные, фриланс и рабочие. Рядом существует одна общая personal-memory/, которая не принадлежит ни одному из них. Агент открывает только папку текущего проекта, поэтому рост общего числа папок не увеличивает стартовый контекст.

Зачем ограничивать размер стартовых файлов

При входе в известный проект агент читает фиксированный набор:

Я считаю строки, а не токены. Такой предел легко увидеть в редакторе, он не зависит от токенизатора и одинаково понятен человеку и модели. Реальное число токенов меняется между инструментами, а грубая формула «четыре символа на токен» часто ошибается. Для архитектуры это несущественно: каждый стартовый файл отвечает за одну функцию и не растёт бесконечно.

Когда базового набора мало, index.md ведёт агента к конкретному исследованию, решению или журналу. Материалы не загружаются заранее только потому, что существуют.

Индексы нужны в тех местах, где количество файлов не имеет естественного потолка. Выбор проекта происходит снаружи — по папке, подключённой к сессии, — поэтому общий каталог всех проектов агенту перебирать не нужно. Иная ситуация с logs/: журнал пополняется постоянно. Для него создаётся собственный индекс «дата → файл → тема», а главный index.md ссылается на эту таблицу, а не перечисляет всю историю.

Без такого ограничения новый чат быстро начинался бы с чтения сотен строк, большая часть которых не относится к текущей задаче.

Как начинается и заканчивается сессия

Слово «продолжаем» у меня стало привычкой, но протокол к нему не привязан. Я могу открыть новый чат и написать + или любое другое короткое сообщение. Если к сессии уже подключена папка проекта, агент читает project.yaml, index.md, state.md и instructions.md. От меня требуется только начать диалог.

При одном очевидном следующем действии агент отвечает в одну строку: «Я в контексте. Остановились на X. Следующий шаг: Y.»

Если в state.md зафиксировано несколько возможных продолжений, вместо искусственного объединения появляется короткий нумерованный выбор.

На восстановление уходят секунды. Инструмент можно заменить, а смысл проекта останется тем же. Человек тоже способен открыть state.md и увидеть ту же текущую точку, которую получил агент.

Сохранение запускается двумя способами. Иногда агент замечает, что разговор стал длинным, и предлагает зафиксировать состояние; я либо соглашаюсь, либо прошу сначала завершить текущий участок. В другой ситуации я сам говорю «сохраняйся». Последующие действия одинаковы.

В конце работы обновляются:

  1. state.md — текущее положение и ближайшее действие.

  2. logs/log-YYYY-MM-DD-тема.md — если сессия была существенной.

  3. decisions/ADR-*.md — отдельная запись, если появилось значимое решение.

После сохранения агент заново читает изменённые файлы и проверяет Git diff. Одного сообщения об успехе для этого недостаточно.

backlog.md обновляется не по завершении сессии, а в момент появления задачи. Новая идея сразу отправляется в бэклог по моей команде или по предложению агента; ждать финального ритуала незачем.

Сокращённые фрагменты проекта

Ниже — сокращённые фрагменты одного из моих проектов. Полные рабочие файлы содержат дополнительные служебные поля и меняются по мере работы.

Так выглядит его project.yaml:

Его index.md:

И текущий срез в state.md:

Этого сокращённого набора достаточно, чтобы увидеть принцип: стартовый контекст занимает несколько коротких блоков и читается почти сразу.

Где всё это хранится

Источником истины у меня служит Git-репозиторий. Сейчас он находится в self-hosted GitLab, но сама схема от GitLab не зависит. Git — открытая система с переносимым форматом репозитория: его можно клонировать на другой сервер или отправить в приватный репозиторий на GitHub. Для минимальной версии достаточно Git на ноутбуке и удалённого приватного репозитория.

Self-host не защищает от потери сам по себе. Если собственный сервер содержит единственную копию, он превращается в такого же единственного провайдера. Поэтому GitLab остаётся основной точкой, внешний диск сохраняет резервную копию сервера, а приватные репозитории независимо зеркалируются в GitHub. Отказ одного узла не уничтожает остальные копии.

Технологический набор короткий: Git, Markdown и YAML. Документ, который нельзя открыть обычным текстовым редактором, в эту систему не попадает.

Для просмотра я использую Obsidian с Git-синхронизацией. Это интерфейс для человека, а не часть протокола: агенты обращаются к файлам напрямую и без Obsidian.

Самый короткий старт

Скрипты и терминал для первого шага не нужны. Достаточно создать папку проекта и положить в неё один state.md:

Такой файл полезен и без AI: он сохраняет точку продолжения. Когда одного состояния станет недостаточно, рядом появятся index.md, backlog.md и остальные части структуры.

Подключение нового агента

Новому инструменту передаётся короткий адрес, а не копия всех правил:

Если вставить полное содержание правил в System Prompt или Project Instructions, появится вторая версия тех же данных. Её придётся синхронизировать вручную, и со временем копии разойдутся. Короткий указатель решает проблему: инструмент каждый раз читает актуальные файлы. При конфликте между собственной памятью агента и содержимым репозитория приоритет всегда у файла.

Способ передачи указателя зависит от среды:

  • Инструменты с автообнаружением читают файл с конвенционным именем в рабочей папке: CLAUDE.md в Claude Code, AGENTS.md — в совместимых coding agents.

  • Среды с полем инструкций проекта получают тот же указатель один раз. Изменение правил внутри репозитория не требует заново редактировать это поле.

  • Обычный веб-чат без доступа к диску не может выполнить контракт. Файлы придётся прикладывать вручную, и трение останется.

Ограничения, которые уже проявились

Параллельная запись. Два агента или два разных инструмента способны одновременно изменить один проект и создать Git-конфликт. Я сталкивался с ситуацией, когда одна сессия успела закоммитить изменения, а вторая остановилась на блокировке, хотя сообщила об успехе. Поле owner в project.yaml помогает договориться, кто сейчас работает, но не создаёт технической гарантии.

Актуальность состояния. Если завершить работу и не переписать state.md, следующий вход восстановит устаревшую картину. Есть и противоположная проблема: агенты любят читать историю «на всякий случай», даже когда короткого состояния достаточно. Оба поведения приходится ограничивать правилами; автоматического принуждения пока нет.

Доступ к файловой системе. Чат, которому нельзя подключить папку, знает только содержимое вручную загруженных документов. Один стартовый промт не может обойти физическое ограничение среды.

Почему структура менялась несколько раз

Первая рабочая версия появилась быстро, но не осталась окончательной. С ростом числа проектов и сменой инструментов стали видны ограничения, которых не было на старте. Некоторые решения следующей итерации позже пришлось отменить.

Я не считаю текущую схему универсальным стандартом для всех. Она доказала пригодность в моих условиях: одновременно держит личные проекты, фриланс и рабочие задачи с разным ритмом. Файлы, которые позже перестали использоваться, и накопленные промты тоже были — это издержки последовательной доработки, а не свидетельство того, что первая версия не работала.

Что ещё предстоит решить

Базовая структура остаётся прежней, но вокруг неё есть незакрытые задачи.

Полезный след всей сессии. Короткий лог не сохраняет каждый ценный фрагмент разговора. Нужен дешёвый способ оставить больше контекста и при этом не получить архив, к которому никто не возвращается.

Предсказуемая параллельная работа. Одновременная запись уже приводила к Git-конфликту. Нужен явный протокол поведения двух агентов, а не одна мягкая отметка владельца.

Основание при этом не меняется: Git и Markdown остаются постоянным слоем, всё остальное добавляется только при реальной необходимости.

Короткие ответы

Система полезна без AI? Да. На базовом уровне это способ записывать актуальное состояние проекта; агент не обязателен.

Можно хранить в репозитории пароли и токены? Нет. Секреты находятся отдельно от этих файлов.

Нужно ли сразу переносить все старые заметки и чаты? Я переношу только то, что действительно используется, причём по мере необходимости. Остальное остаётся архивом и не конкурирует с актуальным источником истины.

Минимум, с которого стоит начать

Не копируйте всю схему. Сначала создайте один state.md с тремя ответами: что происходит сейчас, какой следующий шаг и что мешает. В конце сессии переписывайте его целиком, а не добавляйте очередной слой истории. Короткий текущий срез защищён от захламления самой формой документа; прошлое при необходимости уходит в отдельный журнал. Остальные элементы появятся тогда, когда одного файла станет недостаточно.

Telegram-канал Mind & Mesh: @takeshi_ku