Клиентские данные: изоляция

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

Одна папка на клиента

Всё, что относится к компании, лежит в clients/<имя>/ и нигде больше. Договор не в projects/, транскрипт не в Downloads/, реквизиты не в чате.

clients/Acme/
├── README.md         # кто это, чем занимаемся, статус, ключевые контакты
├── requisites.md     # реестр юрлиц и контактов
├── INBOX-LOG.md      # что пришло и куда разобрано
├── inbox/            # сырое входящее: письма, файлы, вложения
├── docs/             # договоры, счета, акты, КП - с датой в имени
└── calls/            # транскрипты созвонов, с датой в имени

Если работа с компанией выросла в отдельный проект с кодом, код живёт в projects/acme-bot/, а всё остальное остаётся в clients/Acme/. Проект ссылается на клиента в README, но не хранит его договоры и транскрипты внутри.

Реестр реквизитов

Реквизиты и контакты - в одном файле requisites.md. Агент берёт данные только оттуда. Не из старого счёта, не из переписки, не из памяти.

Отдельная ловушка: у одной компании может быть несколько юрлиц. Бренд «Acme», а договор с ООО «Акме Менеджмент», а следующий счёт - на ИП учредителя. Каждое юрлицо - отдельная запись со своим ИНН, банком и подписантом. Перед выпуском любого документа агент должен спросить или проверить, на какое именно юрлицо оформляем.

# Реквизиты: Acme

## Юрлица

### ООО «Акме Менеджмент» - актуальное
- ИНН / КПП / ОГРН: ...
- Адрес: ...
- Банк, р/с, БИК: ...
- Подписант: Иванова О.В., генеральный директор, на основании Устава
- Для чего: договоры на обучение, счета по ним

### ИП Иванова О.В. - архив, до 2025
- ...

## Контакты
- Ольга Иванова - CDTO, решает по бюджету, @username, почта
- ...

Статус «актуальное / архив» у каждого юрлица обязателен: иначе агент возьмёт первое попавшееся.

Правило в AGENTS.md / CLAUDE.md

Изоляция держится на записанном правиле, а не на здравом смысле агента. Блок в корневом файле правил:

## Клиентские данные

- Данные и материалы одного клиента не использовать в материалах другого:
  ни реквизиты, ни цифры, ни цитаты, ни «похожие примеры».
- Основа любого документа - шаблон из _templates/, не документ другого клиента.
- Реквизиты - только из clients/<имя>/requisites.md. У клиента может быть
  несколько юрлиц: перед документом уточнить, на какое.
- Демо и примеры для показа - только обезличенные: без названий компаний,
  имён, сумм и цитат.
- В clients/ не заходить без явной задачи по этому клиенту.

Последняя строка важнее, чем кажется. Без неё агент, ища «пример хорошего КП», обойдёт все клиентские папки и найдёт чужое.

Клиентские папки и git

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

1. clients/ вообще вне git. В .gitignore корня воркспейса - строка clients/. Резервная копия - обычная синхронизация диска.
2. clients/ в отдельном приватном репозитории с ограниченным доступом. Так у документов есть история, но она не пересекается с кодом.

Чего не делать: класть папку клиента внутрь проекта и надеяться на .gitignore внутри проекта. Одна неточная строка - и договор в репозитории.

Персональные данные и секреты

Транскрипты созвонов, списки сотрудников, ответы на интервью - это персональные данные, и на них есть свои правила: что можно хранить, что нужно обезличить перед тем, как отдать модели, что нельзя пересылать. Два соседних курса закрывают эту тему: Безопасность корпоративных данных и Обезличивание персональных данных.

Пароли, токены и ключи API - отдельная история. Один .env файл на весь воркспейс, в корне, не в git. Не по файлу на проект: с десятью .env вы забудете, где какой, и один из них уедет в репозиторий. Проекты читают корневой файл, на сервере - свой локальный. В клиентских папках секретов нет вообще: доступы к системам компании - в менеджере паролей, а в requisites.md только ссылка «доступы - в менеджере паролей, запись Acme».

Спорные случаи