Продвинутое разделение слоёв между данными и их обработчиками

Введение

Открываешь утром Claude Code. Видишь сообщение: аккаунт отключён.¹²

Вместе с доступом к модели пропадает привычный способ работы: память, скиллы, инструкции, локальные настройки, MCP-серверы и часть проектного контекста.

Проблема видна сразу: система хранилась внутри инструмента.

В прошлой статье я уже показывал, зачем выносить настройки AI-агентов в репозиторий. Но это только первый этаж. Следующий шаг — разделить данные и обработчики.

Claude, Codex, Cursor, Gemini и любой другой агент — не место, где должна жить твоя система. Это исполнитель.

Тезис статьи простой: данные должны жить отдельно, обработчики отдельно. Данные — память, правила, шаблоны, структура проекта, накопленные решения. Обработчик — агент, который эти данные читает и применяет. Меняешь обработчик, аккаунт или компьютер — данные остаются.

Это и отделяет рабочую систему от нестабильной схемы.

Главная ошибка: делать из агента хранилище

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

Это всего лишь одна точка входа.

Если твои правила живут в ~/.claude/CLAUDE.md, твои project settings лежат в .claude/settings.json, а часть памяти осталась только в истории конкретного тулла, то у тебя уже несколько слоёв смешаны в один.³⁴ Внутри одной и той же сущности у тебя одновременно:

• знания;
• способы их применения;
• временное состояние;
• пользовательский интерфейс;
• привязка к аккаунту и вендору.

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

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

Где это ломается на практике

Это не редкий аварийный режим. Хватает трёх обычных сценариев.

1. Аккаунт заблокировали

Это самый неприятный сценарий, потому что он приходит без подготовки. Ты не планировал миграцию и не собирался менять workflow. Ты просто хотел продолжить работу. А вместо этого разбираешься, почему инструмент больше тебя не пускает.¹²

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

Текущий chat context всё равно потеряешь. Но это уже потеря одного сеанса, а не потеря всей рабочей среды.

2. Ты поменял компьютер или переустановил систему

Это менее драматичный, но куда более частый сценарий. Новый ноутбук. Чистая система. Пустой home directory. В этот момент всё, что не было вынесено наружу, исчезает автоматически.

Anthropic прямо пишет, что при сбросе конфигурации Claude Code удаляются settings, MCP server configurations и session history.⁵ То есть даже официальный reset подтверждает мысль статьи: то, что лежит только внутри tool-local состояния, не является надёжным источником правды.

3. Ты работаешь не с одной моделью

Это уже обычный рабочий сценарий. Сегодня у тебя закончились лимиты у одного вендора — ты ушёл в другой. Завтра одна модель стала лучше писать код, а другая лучше ревьюить. Через месяц появился новый инструмент, и тебе надо быстро понять, можно ли в него переехать.

Если настройки, persona, skills и project memory жёстко привязаны к одному туллу, начинается ручная синхронизация: перенеси файл, обнови правило, не забудь поправить вторую копию, потом третью. В итоге конфигурация дрейфует. Claude отвечает так, Codex иначе, Cursor вообще живёт по старым правилам.

С этого момента ты уже не управляешь системой. Ты поддерживаешь набор слабо связанных конфигураций.

Какие слои реально надо разделить

Проще сразу разложить это по слоям.

Слой	Что в нём живёт	Где ему место
Глобальные данные	persona, стиль, coding standards, глобальные skills, общие субагенты	отдельный репозиторий настроек
Проектные данные	AGENTS.md, .claude/settings.json, .mcp.json, project memory, принятые решения	внутри конкретного проекта
Шаблоны и стартовые структуры	boilerplate для новых проектов, типовые README, CI, docker, базовые папки	отдельный репозиторий шаблонов
Инфраструктурные знания	сервера, DNS, деплой, домены, runbook'и	отдельный приватный репозиторий
Исполнители	Claude Code, Codex, Cursor, Gemini CLI	любой удобный агент
Эфемерное состояние	текущий чат, временные разрешения, локальный кэш, короткая история сессии	внутри конкретного инструмента

Вот этот последний пункт важен. Я не предлагаю тащить в git вообще всё подряд. Временное состояние может жить внутри агента. Это нормально. Ненормально, когда внутри него живёт единственная копия твоих правил, памяти и проектной структуры.

Граница тут простая.

Если без этого куска ты завтра не сможешь продолжить работу в другом инструменте — это данные, и им не место только внутри одного агента.

Если без этого куска ты потеряешь только текущий удобный сеанс — это runtime, и его можно не спасать любой ценой.

Как это выглядит на уровне файлов

Чтобы эта схема не оставалась абстракцией, её полезно один раз разложить по папкам.

• ~/ai-settings/AGENTS.md, skills/, agents/, docs/ai/ — глобальный слой. Здесь лежит всё, что должно быть одинаковым между инструментами и проектами.
• project/AGENTS.md — проектный слой инструкций. Здесь договорённости именно про этот репозиторий.
• project/.claude/settings.json, project/.mcp.json — проектные настройки инструмента и подключений, которые должны ехать вместе с проектом.
• project/docs/adr/, project/memory.md, project/README.md — память проекта: решения, runbook'и, особые команды, принятые компромиссы.
• ~/boilerplate/ или отдельный шаблонный repo — стартовые структуры новых проектов.
• ~/.claude/settings.local.json, .env, локальные абсолютные пути, временные override — только локальный слой, без коммита.
• Chat history, кэш, временные разрешения, краткоживущая память сессии — внутреннее состояние инструмента, а не source of truth.

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

Что не хранить в git

Разделение слоёв не означает, что в репозиторий надо складывать всё подряд.

Не надо коммитить:

• API-ключи, токены, .env, credentials.json, *.pem, *.key;
• machine-specific пути и локальные override, которые работают только на одной машине;
• временные разрешения, локальные кэши, экспорт чатов и промежуточные артефакты;
• всё, что относится только к текущему сеансу и не нужно команде или будущему тебе.

Правило простое: если файл нужен только на этом ноутбуке или только в этой сессии, он не должен становиться частью общего слоя. Для этого и нужны .gitignore, локальные settings-файлы и разделение project/global/local scope.

Почему Git и GitHub здесь не просто «потому что все так делают»

Здесь важен не GitHub сам по себе, а принцип.

Git хорош не потому, что разработчики романтизируют терминал. Git хорош потому, что это нормальный механизм для хранения версии данных. В распределённой модели каждый clone содержит полную историю репозитория. То есть твои настройки и документы не просто где-то «синхронизированы», а реально существуют как восстанавливаемая копия.⁶

GitHub поверх этого удобен уже по другой причине: он снижает трение. Можно держать публичные и приватные репозитории, клонировать их на новую машину, публиковать изменения, а если не хочется жить в терминале — использовать GitHub Desktop, который нормально закрывает базовый workflow: clone, commit, push, sync между компьютерами.⁷

То есть логика такая:

• Git отвечает за версионность и восстановление;
• GitHub отвечает за доступность и синхронизацию;
• GitHub Desktop отвечает за то, чтобы эта схема не требовала любви к командной строке.

Спорить здесь стоит не про «GitHub или не GitHub», а про принцип. Если тебе ближе GitLab или self-hosted Gitea — пожалуйста. Единый источник правды всё равно должен жить в системе контроля версий, а не внутри настроек одного AI-клиента.

Что это даёт с точки зрения самих инструментов

Эта схема не спорит с инструментами. Она повторяет их внутреннюю логику.

Anthropic сам разделяет instructions и settings по уровням: user, project и local. Причём project instructions и project settings у них прямо рассчитаны на shared workflow через source control.³⁴ Это не хак. Это штатный сценарий.

AGENTS.md тоже уже живёт как переносимый слой: стандарт описывает один markdown-файл как общее место для инструкций агенту и отдельно оговаривает precedence — ближайший к файлу AGENTS.md важнее.⁸ Cursor умеет использовать AGENTS.md как простую альтернативу .cursor/rules.⁹ Gemini CLI позволяет объявить AGENTS.md в context.fileName, а не держаться только за GEMINI.md.¹⁰

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

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

С этого момента у тебя появляется не «любимый клиент», а архитектура.

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

Если доступ к инструменту пропал или ты переехал на новую машину, восстановление должно выглядеть не как отдельный проект, а как короткий сценарий.

1. Ставишь новый инструмент или заходишь в новый аккаунт.
2. Клонируешь репозиторий с глобальными настройками и раскатываешь его через установочный скрипт или ручную синхронизацию.
3. Клонируешь нужный проект.
4. Поднимаешь project layer: AGENTS.md, .claude/settings.json, .mcp.json, memory.md, docs/adr/ и другие файлы, которые лежат рядом с кодом.
5. Открываешь проект в любом доступном агенте и продолжаешь работу.

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

Как это раскладываю у себя

Расскажу на своём примере. Не как единственно верную истину, а как рабочую конструкцию.

У меня сейчас три основных репозитория.

1. ai-settings

Это открытый репозиторий, в котором лежит глобальный слой: persona, стиль общения, coding standards, writing voice, глобальные скиллы, субагенты и установочные скрипты.¹¹

Ключевая идея там простая: один source of truth для того, как агент должен работать. Не в каком приложении, а именно как. Как спорить, как не галлюцинировать, как писать код, как оформлять коммиты, как вести себя в ревью, как сокращать ответы и как экономить контекст.

Отдельно мне нравится, что этот слой не зависит от конкретной модели. Сегодня сверху Claude, завтра Codex, послезавтра ещё кто-то. Библиотека правил остаётся той же.

2. popovs-boilerplate

Это второй открытый репозиторий. В нём уже не persona и не memory, а шаблоны проектов.¹²

Это другой тип данных. Не правила поведения агента, а стартовая форма будущего проекта.

У меня там вынесены несколько типовых заготовок: полноценный fullstack, API-only, статический сайт и docs-репозиторий. Если смешать это с ai-settings, получится каша. Потому что persona агента и структура нового FastAPI-проекта — это разные сущности, даже если они часто используются вместе.

3. Приватный инфраструктурный репозиторий

Туда я складываю описание серверов, деплоя, DNS, доменов, runbook'и, то есть всё, что не должно жить в публичном repo, но при этом тоже не должно зависеть от памяти одного агента.

Это третий тип данных. Он не про стиль, не про шаблоны и не про текущий код проекта. Он про среду, куда всё это поедет жить.

И именно поэтому он тоже лежит отдельным слоем.

Минимальная версия этой схемы

Если у тебя пока нет своей инфраструктуры и ты не поддерживаешь несколько типов проектов, не надо начинать с трёх репозиториев.

Минимальная рабочая схема проще:

• один repo под глобальные настройки;
• один repo под сам проект вместе с его memory и локальными правилами.

Для старта большинству людей этого достаточно. Boilerplate можно сначала держать просто как шаблонную папку или как один стартовый repo. Отдельный шаблонный слой имеет смысл выносить тогда, когда у тебя действительно появилось несколько повторяющихся типов проектов. Приватный infra-repo нужен ещё позже — когда у тебя вообще появилась инфраструктура, которую надо описывать и переиспользовать.

Что делает агент в такой схеме

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

Например, у меня сверху есть skill, который разворачивает новый проект. Он не хранит у себя знания о моей persona. Не хранит единственную копию boilerplate. Не хранит инфраструктуру в промпте. Он просто соединяет слои.

Сценарий такой:

1. Я создаю папку проекта.
2. Открываю её в Claude Code или Codex.
3. Вызываю skill.
4. Skill спрашивает тип проекта, публичность репозитория и базовые параметры.
5. Потом подтягивает нужный boilerplate, накладывает сверху актуальный слой ai-settings, а если надо — добавляет инфраструктурный контекст.

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

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

Отдельно про память проекта

Самый недооценённый кусок во всей этой схеме — project memory.

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

Проектная память должна жить внутри проекта.

Это может быть AGENTS.md, memory.md, decision log, docs/adr/, changelog по архитектурным решениям — неважно. Важно, что эти данные хранятся рядом с кодом и едут вместе с проектом. Тогда, когда ты открываешь репозиторий в другом агенте, он поднимает не пустую папку, а рабочую среду с историей решений.

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

С чего начать, если всё сейчас смешано

Если сейчас всё смешано, не надо устраивать архитектурную реформу за один вечер. Так легко переусложнить себе задачу и бросить всё на полпути.

Начни с четырёх шагов.

Шаг 1. Вынеси глобальные настройки в отдельный репозиторий

Собери туда persona, общие правила, свои любимые скиллы, шаблоны команд и всё, что должно быть одинаковым между проектами.

Шаг 2. Вынеси boilerplate отдельно

Не смешивай стартовые шаблоны проектов с personality-файлами агента. Это другой класс данных.

Шаг 3. Храни память внутри каждого проекта

Архитектурные решения, проектные соглашения, локальные runbook'и, особые команды, принятые компромиссы — всё это должно жить рядом с кодом.

Шаг 4. Коммить и пушь изменения по ходу работы

Именно на этом всё и ломается. Если ты день что-то настраивал, а потом не закоммитил, значит, у тебя не было бэкапа. У тебя была только локальная версия без защиты от потери.

Как итог

• Агент — это исполнитель. Хранилище правил, памяти и шаблонов должно жить отдельно от него.
• Если данные лежат внутри одного инструмента или одного аккаунта, ты получаешь vendor lock-in даже там, где можно было его не получать.
• Разделение по слоям не усложняет систему, а делает её переносимой: новый аккаунт, новый компьютер и новый агент перестают быть катастрофой.
• Отдельный repo под настройки, отдельный repo под boilerplate, отдельная project memory внутри проекта и отдельный приватный слой под инфраструктуру — уже достаточно взрослая схема.
• Временный chat context можно потерять. Единственную копию рабочей системы — нет.

Словарь терминов из этой статьи

Термин	Что это
Обработчик	Исполнитель, который читает данные и применяет их. В этой статье это Claude Code, Codex, Cursor, Gemini CLI и другие агенты.
Единый источник правды	Место, где лежит актуальная версия данных. Не копия, не временная настройка, а основная версия, на которую все ориентируются.
AGENTS.md	Markdown-файл с инструкциями для coding-агентов. Может быть общим слоем правил для нескольких инструментов.
CLAUDE.md	Файл инструкций Claude Code. Может быть как глобальным, так и проектным слоем памяти и правил.
Project memory	Память конкретного проекта: решения, соглашения, runbook'и, локальные правила и исторический контекст.
Boilerplate	Готовый шаблон проекта: структура папок, базовые файлы, CI, docker, настройки фреймворков.
Vendor lock-in	Ситуация, когда данные или workflow так завязаны на одного вендора, что перейти на другой инструмент становится дорого и больно.
MCP	Model Context Protocol — способ подключать к агенту внешние инструменты и сервисы вроде GitHub, базы данных или браузера.
Git	Система контроля версий, которая хранит историю изменений файлов и позволяет восстановить состояние репозитория.
GitHub Desktop	Графическое приложение для работы с GitHub без командной строки: clone, commit, push, sync.
Runtime	Временное рабочее состояние конкретного запуска: текущий чат, локальный кэш, временные разрешения, промежуточный контекст.
Субагент	Специализированный агент под конкретную роль: ревьюер, разработчик, продакт, дизайнер.

Источники

1. Claude Account Disabled After Payment for Claude Code Max 5x Plan — публичный кейс с отключением аккаунта после оплаты.
2. Claude Pro account disabled without warning — ещё один публичный репорт про внезапную деактивацию аккаунта.
3. How Claude remembers your project — уровни project/user instructions и работа через source control.
4. Claude Code settings — раздельные settings, subagents, MCP и project-local файлы.
5. Claude Code troubleshooting — сброс удаляет settings, MCP-конфигурации и session history.
6. Git Book: About Version Control — почему каждый clone в distributed VCS является полным бэкапом.
7. Creating your first repository using GitHub Desktop — publish, private repo и sync между компьютерами через GUI.
8. AGENTS.md — открытый стандарт общего слоя инструкций для coding-агентов.
9. Cursor Rules — AGENTS.md как простой project-level слой в Cursor.
10. Gemini CLI: Provide context with GEMINI.md files — возможность указать AGENTS.md через context.fileName.
11. tsergeytovarov/ai-settings — пример репозитория, где глобальные настройки вынесены в отдельный слой.
12. tsergeytovarov/popovs-boilerplate — пример отдельного слоя для шаблонов и стартовых структур проектов.