# CRM: следующий шаг без потери данных

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

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

## 1. Первая попытка

Распакуйте `crm-04-student-base.zip` в новую учебную папку. В ней ровно четыре исходных файла: README, OUTPUT-CONTRACT и два файла в input. Откройте именно эту папку как проект. Используйте контрольный момент из правил, а не текущую дату компьютера.

```text
Работай только внутри этой учебной папки. Не используй Git, другие проекты,
сеть, CRM и файлы с ответами. Прочитай README.md, OUTPUT-CONTRACT.json,
input/crm.csv и input/crm-rules.json.
Собери output/base/crm-review.csv и output/base/update-plan.md по контракту.
Пустая сумма означает «неизвестно». Не подставляй ноль и не придумывай
ответственного, договорённость или срок. Все действия — предложения.
Сохрани первую попытку; исходные файлы не меняй. Перечитай оба результата
и сообщи, какие файлы созданы и какие вопросы остались открытыми.
```

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

## 2. Разбор и исправление

Сохраните первую попытку отдельно. Запишите конкретное расхождение с исходным полем или правилом и попросите исправить его в `output/review-base/`. Даже если ошибки не найдены, сохраните заметку о сверке; второй «независимой первой попыткой» это не становится.

```text
Сверь output/base/ с теми же двумя входами и OUTPUT-CONTRACT.json.
Каждую найденную ошибку объясни ссылкой на id и исходное правило.
Если требуется исправление, сохрани новые файлы в output/review-base/.
Не меняй output/base/ и входы. Не объявляй предложения согласованными.
Неизвестное нельзя заменить нулём; подтверждённая нулевая сумма допустима.
Не используй Git, сеть, CRM и файлы вне этого проекта.
```

## 3. Конфликт версии

Разберите `conflict_case` в исходных правилах. Это учебная проверка перед возможной записью: её нет в задании и в реальной CRM ничего не выполняется. Запись по устаревшей версии должна остановиться; новый снимок выдаётся на следующем шаге.

```text
Прочитай conflict_case из input/crm-rules.json. Сравни read_version
и version_before_write. Сохрани output/conflict/decision.json с полями:
deal_id, proposed_version, observed_version, decision, would_write,
requires_reread, reread_performed, unknown_data, next_allowed_step.
Укажи предложенную и обнаруженную версии из учебной проверки,
решение по правилам, неизвестное и следующий допустимый шаг.
Дополнительно сохрани output/conflict/handoff.md: что сравнил, почему
остановился, что неизвестно и что нужно следующему оператору.
Обозначь работу только с файлами и предложения без внешней записи.
Пока новый снимок не выдан, не заявляй, что уже перечитал его.
Не выполняй внешних действий и не меняй предыдущие результаты.
```

Отчёт модели подтверждает содержание сохранённого решения. Сам по себе он не доказывает отсутствие внешней записи. В этой практике подключение к CRM не требуется.

## 4. Новый снимок и повторный анализ

Только после первой попытки, разбора и решения по конфликту распакуйте `crm-04-changed-scenario.zip` в ту же учебную папку. Прочитайте input/CHANGE-NOTE.md: новый срок добавлен явно как синтетический факт задания. Сохраните исходный CSV и прежние результаты.

```text
Прочитай input/CHANGE-NOTE.md, input/crm-changed.csv и input/crm-rules.json.
Используй новый CSV как текущий снимок. Повтори анализ по тому же контракту
в output/changed/crm-review.csv и output/changed/update-plan.md;
в плане укажи SHA256 именно нового CSV и прежних правил.
Сохрани факты нового снимка, объясни отличия от первой попытки.
Не возвращай старые пустые поля и не переноси старую версию карточки.
Conflict_case в правилах описывает прошлую проверку; обозначь это,
не выдавая его за новую запись. Все изменения остаются предложениями.
Не меняй input/crm.csv, предыдущие output/, Git и внешние системы.
```

Сверьте изменённую карточку прямо с новым CSV и перечитайте созданные файлы. Актуальные значения и хеш подтверждают соответствие сохранённого результата новому источнику. Чтобы подтвердить само чтение источника помощником, отдельно сохраняют наблюдение интерфейса или вызовов инструментов. Хеш не доказывает изоляцию от других файлов. Решение по конфликту остаётся историей остановки до выдачи снимка.

## Что сохранить

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

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

[Вернуться к практике школы](/intensive/practice/) · [Подготовить Antigravity](/intensive/materials/antigravity-platform/20261012/)

## Разбор после собственной попытки

Когда сохранили свои файлы, откройте [выполненную попытку и разбор](crm-04-reviewed-example.zip). В ней видны первая версия, отдельное исправление после замечаний, остановка по конфликту и повторный анализ. Первая таблица верна, но первоначальный план ошибочно запрещал любые нулевые суммы; корректное правило запрещает только подмену неизвестного нулём. Исправленный пример прошёл отдельную смысловую сверку. Исходная попытка сохранена и не выдаётся за безошибочную.