# Объединённый конспект — SaaS-аналог crm.bp-gr.ru (Лидерра)

## Хроника работы: от анализа v7.0 до v8.5 + ребрендинга (03–08.05.2026)

**Период:** 03.05.2026 – 08.05.2026.
**Назначение:** единый документ с историей создания и эволюции документации SaaS-платформы — от анализа исходной версии v7.0 до архива v8.5 + ребрендинга «Лидпоток» → «Лидерра.» с интеграцией handoff'а Платона v8 Forest.

---

# ЧАСТЬ I. СОЗДАНИЕ ДОКУМЕНТАЦИИ v8.0 (03.05.2026)

**Длительность:** ~2 часа.
**Цель:** Анализ документации v7.0 → разрешение всех противоречий → создание полного ТЗ v8.0 для разработки SaaS-платформы.
**Результат:** 4 файла-артефакта в `/mnt/user-data/outputs/` (полная документация v8.0 — Markdown + DOCX, executive summary — Markdown + DOCX).

## 1. Стартовая точка

### Исходные материалы

| Файл | Описание |
|---|---|
| `CRM_bp-gr_Инструкция__6_.md` | Документация v7.0, ~67 КБ, 2134 строки. Заявленная готовность 98–99%. |
| `session_summary.md` | Конспект разработки документации — что обсуждалось ранее. |
| `session_summary_design.md` | Конспект дизайн-сессии. |
| `leadflow-dashboard.html` | HTML-прототип дашборда, 942 строки. |
| `webhook_payload.md` | Реальный формат Webhook от crm.bp-gr.ru. |
| `csv_export_notes.md` | Структура CSV-экспорта с примером 50 строк. |

### Запрос заказчика
>
> Проанализируй документацию на предмет недочётов и ошибок. Ответь на вопрос что тебе ещё нужно для реализации проекта. Сформулируй предложения по доработке.

## 2. Анализ v7.0 — критические находки

### 2.1. Противоречия

**Противоречие №1 — ролевая модель:**

- Раздел 10 v7.0: «role_id=3 — менеджер, role_id=5 — администратор»
- Раздел 18.1 v7.0: «реализуется одна роль, все = полный доступ»
- Возврат денег, глобальные шаблоны, ручное подтверждение оплаты юрлица предполагают права администратора.

**Противоречие №2 — поля Webhook:**

- Раздел 4 v7.0: 6 полей (vid, project, tag, phone, phones, time), `tag` — обязательный
- Раздел 17.5: валидируются только `vid, project, phone`, `tag` пропал
- Раздел 20.1: `tag` снова обязательный
- Поведение приёмника не детерминировано

**Противоречие №3 — Webhook не передаёт name/comment/reminder:**

- В CSV-экспорте эти поля есть; в Webhook — нет; не описано как ограничение

**Противоречие №4 — диаграмма жизненного цикла сделки vs таблица переходов** не сходятся между собой.

### 2.2. Архитектурные пробелы

| Пробел | Описание |
|---|---|
| **SaaS-формат не описан** | Нет мультитенантности, нет регистрации, нет подписок, нет изоляции данных |
| **Биллинг не структурирован** | Нет тарифов, нет юр. лиц-получателей платежей, нет шлюзов |
| **152-ФЗ не покрыт** | Нет согласий, нет журналов, нет права на удаление |
| **Нет инфраструктуры** | Не указано где, как, на чём разворачиваем |
| **Нет SLA, бэкапов, мониторинга** | Полный пробел в эксплуатации |
| **Нет тестов** | Стратегия тестирования отсутствует |
| **Нет дизайн-системы** | Только HTML-прототип |

### 2.3. Технологические замечания

| Тезис v7.0 | Замечание |
|---|---|
| Vue 2 + Vuex | Vue 2 — EOL декабрь 2023. Нужно Vue 3 + Pinia. |
| MySQL для 10М+ строк | PostgreSQL предпочтительнее: партиционирование, JSONB, FTS. |
| Webhook → синхронно в БД | При пиковой нагрузке потеря данных. Нужна очередь Redis. |
| Telegram-бот для уведомлений | Дешевле и стабильнее — Web Push (VAPID). |

## 3. Раунды Q&A с заказчиком

### Раунд 1 — 15 стартовых вопросов

**Ответы заказчика:**

1. **Тарифы не разработаны** — предусмотреть расширяемую схему
2. **Реквизитов пока нет** — несколько юр. лиц / ИП, справочник `legal_entities`
3. **Шлюзы не определены** — Driver pattern, расширяемо
4. **Только администратор** — одна роль на MVP
5. **SaaS** — многотенантная платформа
6. **10 млн+ строк** — партиционирование обязательно
9–10. Файлы Webhook и CSV приложены
11–14. **«Предусмотри возможность или пропустим»**
7. **«Разработай сам на основе прототипа и диалога»**

### Раунд 2 — углубление

**Ответы заказчика:**

- **B1/B2/B3 → один источник** (объединить, обрезать префиксы B2_/B3_)
- **Регистрация — самостоятельная** (открытая)
- **Один пользователь = один тенант**
- **Авансом, разовым пополнением, отдельной транзакцией** (кошельковая модель)
- **Сгорает** (остаток не возвращается при отмене)
- **И физлица, и юрлица** — поддерживать оба документооборота
- **Одно подключение к crm.bp-gr.ru на тенант**
- **Только Webhook**, CSV убрать

### Раунд 3 — финальные уточнения

**C3 (Trial и неактивные) и C4 (SLA):**

1. **CSV-импорт — оставить** в документе как опциональный раздел
2. **(подтверждено) Объединение B1/B2/B3 в один источник**
3. **Webhook = Очередь Redis + асинхронная обработка**
4. **C3.1.** Стартовый бонус (50 лидов, без ограничения по времени)
5. **C3.2.** Полный функционал, лимит только на лиды (100)
6. **C3.3.** Платформа работает, новые лиды отвергаются с логом
7. **C3.4.** Через 12 месяцев — полное удаление + email-предупреждение за месяц
8. **C4.1.** Целевой SLA 99.9%, фактический на MVP 99.0–99.5%
9. **C4.2.** PITR + геораспределённый бэкап
10. **C4.3.** Очередь Redis (синхронная обработка не нужна)
11. **C4.4.** Email + чат в интерфейсе + телефон

## 4. Финальная фиксация всех решений

| Параметр | Решение |
|---|---|
| **Тип системы** | Многотенантная SaaS-платформа |
| **Тарифы** | Расширяемая схема (per_lead, monthly, hybrid, custom). Цены в БД, не в коде |
| **Юр. лица** | Справочник `legal_entities`, поддержка нескольких ООО/ИП |
| **Платёжные шлюзы** | Driver pattern: ЮKassa (основной), Robokassa, Tinkoff, CloudPayments, СБП |
| **Роли** | Только admin на MVP (один пользователь на тенант) |
| **User↔Tenant** | 1:1 на MVP |
| **Регистрация** | Открытая (самостоятельная) |
| **Объём** | 10 млн+ строк → PostgreSQL с партиционированием `deals` помесячно |
| **Источники B1/B2/B3** | Объединены, префиксы B2_/B3_ обрезаются на приёме |
| **CSV-импорт** | Опциональный раздел в документе, не реализуется в MVP |
| **Webhook-приёмник** | Redis Queue + асинхронная обработка (ProcessWebhookJob) |
| **Идемпотентность** | UNIQUE `(tenant_id, source_crm_id)` для UPSERT |
| **Защита Webhook** | Уникальный токен в URL, rate limit 100 RPS на токен |
| **Оплата SaaS** | Кошельковая модель: разовое пополнение, без подписок |
| **Возврат при отмене** | Сгорает; полные возвраты только админом SaaS |
| **Документооборот** | И физлица (чек 54-ФЗ), и юрлица (счёт + УПД) |
| **Подключение crm.bp-gr.ru** | Одно на тенант |
| **Trial** | Стартовый бонус (50 лидов в `system_settings.trial_bonus_leads`) |
| **Баланс=0** | Лиды отвергаются в `rejected_deals_log`, платформа продолжает работать |
| **Неактивность 12 мес** | Soft delete + анонимизация → 30 дней → полное удаление |
| **SLA** | Целевой 99.9%, MVP 99.0–99.5% |
| **Бэкапы** | PITR через WAL-G + ежедневный полный + гео-копия |
| **Поддержка** | Email + чат в интерфейсе + телефон |
| **Стек** | PHP 8.3 + Laravel 11 + Vue 3 + Vuetify 3 + PostgreSQL 16 + Redis 7 |

## 5. Структура документа v8.0

**28 разделов, ~225 КБ Markdown / 125 КБ DOCX:**

| № | Раздел | Объём |
|---|---|---|
| 0 | Глоссарий (B1/B2/B3, ГЦК, КЦ, тенант, УПД, СЧФ/ДОП, ОКПД2, 152-ФЗ, 2FA/TOTP, PITR, MRR, CAC и др.) | 30+ терминов |
| 1 | Обзор системы | Что делает / для кого / бизнес-модель |
| 2 | Архитектура и стек | Полная таблица технологий + C4 container view + поток данных |
| 3 | Мультитенантность | 4 уровня защиты от утечки + DDL `tenants` + `system_settings` |
| 4 | Жизненный цикл клиента SaaS | Регистрация → trial → активная работа → удаление |
| 5 | Webhook от crm.bp-gr.ru | Формат, защита, ProcessWebhookJob (полный PHP-код), edge cases |
| 6 | CSV-импорт (опционально) | Маппинг русских статусов в slug |
| 7 | Сущности и схема БД | Все DDL: tenants, users, projects, deals (partitioned), lead_statuses, balance_transactions, document_sequences |
| 8 | Воронка продаж | 14 статусов, slug, свободные переходы, кастомизация 8 настраиваемых |
| 9 | Мои Проекты | UI, фильтры, действия |
| 10 | Мои Сделки (таблица) | Структура, фильтры с persistence в URL, экспорт CSV/XLSX в очередь при >5000 строк |
| 11 | Kanban-доска | Drag-and-drop с optimistic UI, vue-virtual-scroller |
| 12 | Дашборд + расширенная аналитика | 5 KPI, 2 графика, funnel/heatmap/compare/top-projects, ApexCharts, кеш 5 мин |
| 13 | Отчёты | Асинхронная генерация, S3, TTL 7 дней |
| 14 | Activity Log | События, схема, Eloquent Observers, retention 3 года |
| 15 | Шаблоны комментариев | Личные/глобальные, 5 default |
| 16 | Теги и метки | deal_tags + deal_tag_pivot |
| 17 | Напоминания + Web Push | VAPID-ключи, cron каждую минуту, `minishlink/web-push` |
| 18 | Профиль и аккаунт | 2FA через `pragmarx/google2fa-laravel` + 8 recovery codes, активные сессии, удаление по 152-ФЗ |
| 19 | REST API | Sanctum Bearer, `api_keys` с key_hash и scopes, OpenAPI 3.1, версионирование `/api/v1/` |
| 20 | SaaS-биллинг | Кошельковая модель, тарифы, юр. лица, шлюзы (Driver pattern), счета и УПД, DomPDF, расчёт НДС (vat20/10/7/5/0/no_vat/usn_6/usn_15) |
| 21 | Лид-биллинг | Атомарное списание через `lockForUpdate` или `UPDATE...WHERE balance>0 RETURNING`, low_balance_notified_at, rejected_deals_log |
| 22 | Безопасность | Rate limiting, шифрование (`Crypt::encrypt`), zxcvbn, 152-ФЗ согласия, изоляция тенантов |
| 23 | Инфраструктура и деплой | Docker dev, K8s/VPS prod, Supervisor для воркеров, cron tasks, WAL-G бэкапы |
| 24 | Тестирование | 100% покрытие биллинга и Webhook, изоляция тенантов, маппинг CSV |
| 25 | Мониторинг и SLA | Sentry, Prometheus+Grafana, healthcheck, алерты |
| 26 | Дизайн-система | Токены, компоненты Vuetify, адаптивность |
| 27 | Чек-лист готовности | 16 спринтов = 7,5 месяцев, что нужно от заказчика, риски |

## 6. Ключевые технические детали

### Webhook

- **URL:** `https://crm-аналог.ru/webhook/{tenant_webhook_token}`
- **Формат:** POST JSON, поля `vid` (int), `project` (string, может содержать B2_/B3_), `tag`, `phone` (regex `^7\d{10}$`), `phones` (array), `time` (Unix timestamp)
- **Без подписи, без авторизации** — защита только секретным URL
- **Rate limit:** 100 RPS на токен
- **Очередь:** Redis, имя `webhooks`, retry=3, backoff=60с, timeout=30с
- **Регулярка обрезки префикса:** `^B[123]_`

### CSV-экспорт

- UTF-8 с BOM, разделитель — запятая
- Формат даты: `YYYY/MM/DD HH:MM:SS`
- 9 колонок: id, Проект, Тег проекта, Телефон, Создано, Напоминание, Комментарий, Состояние, Имя
- 14 статусов воронки русским текстом

### БД

- **Партиционирование:** `deals PARTITION BY RANGE (received_at)` помесячно
- **Композитный unique key:** `(tenant_id, source_crm_id)` для идемпотентности
- **Изоляция:** Eloquent global scope + middleware + тесты + опционально RLS

### Биллинг

- **Уровень 1 (SaaS):** `saas_transactions` с UUID `idempotence_key`, `tariff_plans` с `billing_model`, `legal_entities` с `vat_modes`
- **Уровень 2 (лиды):** `balance_transactions` с типами `trial_bonus`, `topup`, `lead_charge`, `refund`, `manual_adjustment`
- **Документы:** `document_sequences` с `FOR UPDATE` для непрерывной нумерации
- **PDF:** `barryvdh/laravel-dompdf`, шаблоны Blade, S3 + signed URL TTL 1 час

### Стек библиотек

| Назначение | Библиотека |
|---|---|
| Web Push | `minishlink/web-push` |
| 2FA TOTP | `pragmarx/google2fa-laravel` + `BaconQrCode` |
| PDF | `barryvdh/laravel-dompdf` |
| Email | Laravel Notifications + SMTP/Mailgun |
| Очереди | Laravel Horizon (Redis) |
| Мониторинг | Sentry + Prometheus + Grafana |
| Бэкапы | WAL-G |
| Поиск | PostgreSQL FTS (на старте), Meilisearch на росте |
| Шифрование | `Crypt::encryptString` (AES-256-CBC + HMAC) |
| Валидация пароля | `bjeavons/zxcvbn-php` |

### Чувствительные поля (шифруются)

- `users.totp_secret`
- `payment_gateways.config` (API-ключи шлюзов)
- `system_settings.value` для VAPID-private-key, SMTP password

### Ключевые `system_settings`

| Ключ | Значение | Описание |
|---|---|---|
| `trial_bonus_leads` | 50 | Стартовый бонус новому тенанту |
| `low_balance_threshold_leads` | 10 | Порог email о низком балансе |
| `inactive_warn_months` | 11 | Когда слать предупреждение |
| `inactive_delete_months` | 12 | Когда удалять |
| `webhook_rate_limit_rps` | 100 | RPS на токен |
| `api_rate_limit_per_minute` | 60 | Запросов API/мин на ключ |
| `password_min_length` | 10 | Минимум пароля |
| `webhook_log_retention_days` | 90 | Хранение raw payload |

### 14 статусов воронки (slug → русское название)

```
new             → Новые                       (системный, синий)
viewed          → Просмотрено                 (системный, фиолетовый)
worked          → Проработан                  (системный, голубой)
base            → База                        (настр., серый)
missed          → Недозвон                    (настр., амбер)
negotiations    → Переговоры                  (настр., жёлтый)
waiting_payment → Ожидаем оплаты              (настр., сиреневый)
partnership     → Партнерка                   (настр., розовый)
paid            → Оплачено                    (системный, зелёный)
closed          → Закрыто и не реализовано    (системный, серый)
test_drive      → Тест драйв                  (настр., бирюзовый)
hot             → Горячий                     (настр., красный)
replacement     → На замену                   (настр., оранжевый)
final_missed    → Конечный недозвон           (системный, тёмно-серый)
```

Системные (6 шт) — нельзя переименовывать. Настраиваемые (8 шт) — клиент задаёт своё название через `tenant_status_overrides`.

## 7. Финальные артефакты v8.0

| Файл | Размер | Назначение |
|---|---|---|
| `CRM_bp-gr_Инструкция_v8.0.docx` | 125 КБ | Word-версия для отправки и распечатки |
| `CRM_bp-gr_Инструкция_v8.0.md` | 225 КБ | Markdown-исходник для git и поиска |
| `CRM_bp-gr_Executive_Summary_v8.0.docx` | 16 КБ | Краткое резюме для бизнес-обсуждения (2 страницы) |
| `CRM_bp-gr_Executive_Summary_v8.0.md` | 11 КБ | Markdown-версия резюме |

## 8. Что нужно от заказчика для старта разработки

| № | Элемент | Срок |
|---|---|---|
| 1 | Реквизиты юр. лиц (ИНН, КПП, ОГРН, банк. реквизиты, печать, подпись PNG, система налогообложения) | До спринта 1 |
| 2 | Тарифные планы (минимум 2-3) | До спринта 7 |
| 3 | Платёжные шлюзы (ЮKassa shop_id+secret_key) | До спринта 8 |
| 4 | Контакты для подвала | До спринта 14 |
| 5 | Юридические документы (оферта, политика) | До спринта 14 |
| 6 | Уведомление в Роскомнадзор | До прода |
| 7 | Домен + wildcard SSL `*.crm-аналог.ru` | До спринта 1 |
| 8 | Облачный аккаунт | До спринта 1 |
| 9 | Брендинг (логотип, favicon) | До спринта 14 |

### Оценка по спринтам

- **16 двухнедельных спринтов = 7,5 месяцев** при команде: 1 backend + 1 frontend + 0.5 DevOps + 0.5 QA + 0.5 PM
- При удвоении команды → ~5 месяцев

---

# ЧАСТЬ II. АНАЛИЗ ПРОБЕЛОВ v8.0 И ПОДГОТОВКА К ИССЛЕДОВАНИЮ ОРИГИНАЛА

## 1. Пробелы документации v8.0 (по приоритетам)

### 🔴 Критические (блокируют старт)

1. **Нет реального доступа к crm.bp-gr.ru** — формат Webhook задокументирован по одному payload, нужны реальные данные за 1–2 недели наблюдения.
2. **Юридическая позиция по копированию crm.bp-gr.ru не определена** — есть ли лицензия/соглашение с владельцами оригинала, как защититься от изменения формата Webhook без уведомления, кто оператор ПДн лидов.
3. **Нет графических артефактов проектирования:** ER-диаграмма (текстовая в 7.2 неполная — упущены failed_webhook_jobs, pd_processing_log, tenant_consents, tenant_custom_domains, import_log, report_jobs, email_verifications, password_resets, user_recovery_codes, user_sessions, tenant_status_overrides), C4-диаграммы графически, sequence-диаграммы, state-machine для финансовых таблиц. Нет единого `schema.sql`.
4. **Нет UI-макетов** — есть только дизайн-токены и компоненты Vuetify. Для разработки нужны Figma-макеты ~8 ключевых экранов: регистрация, онбординг, таблица сделок, карточка сделки, Kanban, дашборд, биллинг, профиль, экраны ошибок.

### 🟠 Серьёзные

1. **Админка SaaS** упомянута вскользь, но это отдельный продукт без проработанной структуры.
2. **Возвраты, чарджбэки, спорные ситуации** не покрыты.
3. **152-ФЗ детали** недостаточны для прохождения проверки Роскомнадзора.
4. **Неактивные аккаунты — операционные детали** UI восстановления, что с balance_rub при удалении.
5. **Производительность:** партиционирование описано только для `deals`. Нет PgBouncer.

### 🟡 Существенные

1. Тестирование, 11. Эксплуатация (runbook), 12. Биллинг — мелкие детали, 13. Технические мелочи.

### 🟢 Желательные

1. Бизнес-метрики, 15. Help-центр, 16. Process docs команды.

### Приоритизированный список для заказчика до спринта 0

**P0:** доступ к crm.bp-gr.ru + сбор payload-ов 1-2 недели; юридическая позиция; реквизиты юр.лица; Figma-макеты (8 экранов); ER-диаграмма + единый schema.sql.
**P1:** структура и макеты админки SaaS; email-шаблоны (5 базовых); шаблоны счёта/УПД; драфт оферты и политики.
**P2:** sequence-диаграммы; runbook; процедура чарджбэка.

## 2. Получение доступа к crm.bp-gr.ru через Claude в Chrome

Идёт получение доступа к crm.bp-gr.ru через **Claude в Chrome** (расширение для браузера). Подключение технически работает: Browser 1 (Windows) на связи, вкладка с crm.bp-gr.ru в группе Claude. Но скриншоты блокируются на уровне расширения по permission_required, несмотря на правильно настроенный `chrome://extensions/` (в Site access добавлен `https://crm.bp-gr.ru/*`). Перешли на план Б — пользователь делает скриншоты вручную.

### 9 партий исследования crm.bp-gr.ru

1. **Главные экраны:** меню навигации, дашборд, таблица сделок, проекты, шапка приложения.
2. **Сделка изнутри:** карточка одной сделки, выпадающий список статусов (все 14), история действий, все фильтры таблицы.
3. **Webhook (КРИТИЧНО):** `/admin/user/api`, документация API. Маскировать токен Webhook на скриншотах.
4. **Воронка:** `/admin/site/states`, просмотр статуса, есть ли Kanban в оригинале.
5. **Биллинг:** баланс, история транзакций, тарифы, форма пополнения, счета/закрывающие.
6. **Профиль:** ЛК, безопасность (2FA?), уведомления (Telegram?), пользователи (множественные на тенант?).
7. **Отчёты:** аналитика, типы отчётов, список звонков, конверсия источников, рекомендации источников.
8. **Прочее:** база знаний, задачи.
9. **DevTools:** XHR на «Мои сделки», структура JSON-ответов, console errors, технологии оригинала.

### Меню оригинала crm.bp-gr.ru (известное по скриншотам)

Левое меню: Статистика, Мои Проекты, Рекомендации Источников, Конверсия Проектов, База Знаний, Мои Сделки, Пользователи, Аналитика, Список Звонков. Шапка: «18:46» (часы), Тех. поддержка в Telegram, Предложить идею, API, Баланс. Текущий URL после логина: `/admin/visit/index-visit` («Мои сделки»).

---

# ЧАСТЬ III. ПЕРЕХОД v8.0 → v8.1 (03–04.05.2026)

**Контекст:** на этом этапе закрываются пробелы v8.0 и принимается блок P0-решений с заказчиком, после чего документация объединяется в единый главный файл.

## 1. Артефакты сессии

| Файл | Размер | Назначение |
|------|--------|------------|
| **`CRM_bp-gr_Инструкция_v8_1.md`** | **290 КБ, 4787 строк** | **Главный narrative** — единое ТЗ v8.1, 28 разделов с обновлениями + новый раздел 28 «Приложения» |
| `schema.sql` | 90 КБ, 1523 строки | **Приложение А** — единая БД-схема: 47 таблиц + 12 партиций, 81 FK, 67 индексов, 33 CHECK, 29 RLS-политик, 3 роли БД, 4 заглушечных тарифа |
| `ER_диаграмма_v8_1.md` | 33 КБ, 963 строки | **Приложение Б** — 6 доменных Mermaid-подграфов + flowchart-карта + текстовый справочник 81 FK |
| `State_machines_v8_1.md` | 23 КБ, 349 строк | **Приложение В** — 4 машины состояний: `saas_transactions`, `tariff_subscriptions`, `report_jobs`, `refund_requests` |
| `Админка_SaaS_v8_1_драфт.md` | 48 КБ, 453 строки | **Приложение Г** — спецификация админки SaaS: ролевая модель, экраны, workflow impersonation, поставщики, chargeback |
| `Открытые_вопросы_v8_1.md` | 28 КБ, 238 строк | **Приложение Е** — сводный workplan: 41 вопрос + 13 предложенных дефолтов |

> **Шифр Д** оставлен как резерв (например, runbook эксплуатации — будет добавлен в v8.2).

## 2. Архитектурная модель (зафиксирована в Ю-2)

**КЛЮЧЕВОЕ ОТКРЫТИЕ СЕССИИ:** проект — **реселлер**, не самостоятельная CRM.

**Поток данных:**

1. Клиент-тенант создаёт **проект** на нашем портале.
2. Мы передаём проект в crm.bp-gr.ru (исходящий API).
3. crm.bp-gr.ru собирает по проекту лиды (своими источниками).
4. crm.bp-gr.ru шлёт нам **webhook** с лидом.
5. Мы передаём лид клиенту через интерфейс / push / email.

**Юридическая модель:**

- Договор с crm.bp-gr.ru **подписан**, мы — официальный корпоративный клиент.
- Мы — **самостоятельный оператор ПДн** (не обработчик по поручению).
- Цепочка ПДн: физлицо → crm.bp-gr.ru → мы → тенант. Каждый — самостоятельный оператор.
- Источник заявок физлиц **не контролируется нами** (зависит от тенанта/crm.bp-gr.ru).

**Биллинг с себестоимостью:**

- Закупочная цена лида у crm.bp-gr.ru — **единая константа** в `system_settings.supplier_default_cost_rub` (заглушка = 1.00 ₽).
- В payload webhook от crm.bp-gr.ru цены нет.
- На каждый лид записывается snapshot цены в `supplier_lead_costs` (партиционированная синхронно с `deals`).
- Счета от поставщика — `supplier_invoices`, ручная сверка с автоподсчётом расхождения через generated column `discrepancy_rub`.

## 3. Принятые P0-решения (11 штук)

### CTO-1. Жизненный цикл `tariff_subscriptions`

**Решение:** вариант А с расширением. Enum 5 состояний:
`scheduled` → `active` → `superseded` (при смене) / `expired` (при истечении) / `cancelled` (при блокировке админом)

- При смене тарифа: новая запись `scheduled`, `started_at = ближайшие 00:00 МСК` (фиксированно МСК).
- Cron `tariffs:apply-scheduled` (каждые 5–10 мин): `scheduled → active`, старая `active → superseded`.
- Уникальные частичные индексы: одна `active` и одна `scheduled` на тенанта.
- **Все записи хранятся бессрочно** (история тарифов).

### CTO-2. Поведение при `expired`

**Решение:** вариант Б — **жёсткая блокировка**.

- `tenants.status = 'suspended'`, webhook возвращает 402, **лиды теряются безвозвратно**.
- `/billing` остаётся доступным для возобновления.
- Email-уведомления: за 7 дней / 1 день / в момент.
- **Намеренная асимметрия с per_lead+нулевым балансом** (там лиды складываются в `rejected_deals_log`, статус остаётся `active`).

### CTO-3. Таймаут `pending` транзакций

**Решение:** 30 минут soft + 24 часа hard. **`failed → success` запрещён**.

- Cron `payments:cancel-stale` каждые 5–10 мин: polling `gateway.getPaymentStatus()`.
- Поздний webhook на `failed` транзакции → `failure_reason='late_webhook_ignored'`, **алерт `finance`**.
- Enum `failure_reason`: `gateway_canceled`, `gateway_declined`, `gateway_create_timeout`, `hard_timeout_24h`, `cron_polling_failed`, `gateway_unknown`, `late_webhook_ignored`.

### CTO-4. `users.notification_preferences`

**Решение:** вариант А — JSONB матрица 8 типов × 3 канала.

- 4 раздельных BOOLEAN из v8.0 удалены.
- Звук — отдельный `sound_enabled BOOLEAN`.
- CHECK на `jsonb_typeof(...) = 'object'`.

### CTO-5. PostgreSQL Row-Level Security

**Решение:** вариант А — **включён сразу на MVP**.

- 29 политик на 30 tenant-таблиц.
- 3 роли БД: `crm_app_user` (политики действуют), `crm_admin_user` (BYPASSRLS, для админки), `crm_migrator` (BYPASSRLS, для миграций).
- Перед каждым запросом приложение делает `SET LOCAL app.current_tenant_id = X`.
- Базовый класс `TenantAwareJob` для очередей.

### Биз-1. Тарифные планы

**Решение:** вариант Б — структура зафиксирована, цены = заглушки 1.00 ₽.

- 4 тарифа: `start` (per_lead), `basic` (hybrid), `pro` (hybrid), `enterprise` (custom).
- `enterprise.is_public = FALSE`.
- Логика стартового бонуса: `tariff_plans.trial_bonus_leads` если задан, иначе fallback на `system_settings.trial_bonus_leads`.

### Биз-2. Отмена подписки клиентом

**Решение:** вариант А — **кнопки нет**.

- Уход из системы: переход на `start` (per_lead, без абонплаты), удаление аккаунта (152-ФЗ §18.6), естественное истечение `expires_at`.
- `cancelled` используется **только** при блокировке тенанта админом SaaS.

### Ю-1. Impersonation «Войти как клиент»

**Решение:** вариант Б — одноразовый код по email клиенту.

- 6-значный код, **15 минут** TTL, **5 попыток** ввода, сессия **1 час**.
- Принудительный красный баннер сверху всех экранов.
- **Запрещены write-действия:** смена пароля, смена email, удаление аккаунта, exports, 2FA toggle, изменение `tenant.contact_email`.
- Email клиенту по завершении сессии со списком действий админа.
- Новая таблица `impersonation_tokens`. В `saas_admin_sessions` — два поля + CHECK constraint.
- В `pd_processing_log` — `purpose='support_impersonation'`.

### Ю-2. Архитектурная модель копирования

**Решение:** **реселлерская модель, самостоятельный оператор ПДн.**
Подвопросы: (а) поток правильный; (б) договор подписан, роль — самостоятельный оператор; (в) источник заявок — зависит от тенанта; (г) биллинг с себестоимостью — гибрид (константа + snapshot).

### Ю-3. Chargeback / внешний возврат

**Решение:** вариант А с защитой от минусового баланса.

- Webhook `refund.succeeded` без `refund_requests` → автоматическое создание `refund_requests(source='external_chargeback', admin_user_id=NULL, status='processed')`.
- Если `balance_rub < refund_amount`: баланс выставляется в 0, разница записывается в новое поле `tenants.chargeback_unrecovered_rub`, `tenants.status = 'suspended'`.
- Алерт `finance` в админке.
- Клиент гасит долг через специальный экран `/billing` (тип транзакции `chargeback_repayment`).
- Альтернатива для `finance`: списать как убыток через `manual_adjustment` (с four-eyes если > порога ДЕФ-4).
- В schema.sql: `tenants.chargeback_unrecovered_rub DECIMAL(12,2) DEFAULT 0 CHECK >= 0`; `balance_transactions.type` расширен; `refund_requests.source` enum; `chk_refund_admin_decision` constraint.

## 4. Новые / обновлённые элементы schema.sql

### Новые таблицы (3)

- `impersonation_tokens` — Ю-1
- `supplier_lead_costs` (партиционированная синхронно с `deals`, 6 партиций) — Ю-2
- `supplier_invoices` — Ю-2

### Расширения существующих

- `tenants` + `chargeback_unrecovered_rub`
- `users` — 4 BOOLEAN удалены, добавлены `notification_preferences JSONB` + `sound_enabled BOOLEAN`
- `tariff_subscriptions` — enum 5 значений, добавлен `superseded_at`, два уникальных частичных индекса
- `saas_admin_sessions` — добавлены `impersonating_tenant_id`, `impersonating_token_id` + CHECK
- `balance_transactions.type` — два новых значения для chargeback
- `refund_requests` — поле `source`, CHECK `chk_refund_admin_decision`

### Новые ключи `system_settings`

- `payments_pending_soft_timeout_min = 30` (CTO-3)
- `payments_pending_hard_timeout_hours = 24` (CTO-3)
- `supplier_default_cost_rub = 1.00` (Ю-2, заглушка)
- `supplier_code = 'crm_bp_gr'` (Ю-2)

### Раздел 12 RLS — 29 политик

`CREATE POLICY tenant_isolation ON ... USING (tenant_id = current_setting('app.current_tenant_id')::bigint)`. Особые случаи: `user_*`-таблицы через JOIN на `users`, `saas_invoice_items` через `invoice_id`, `auth_log` только для строк `actor_type='tenant_user'`.

### Раздел 13 — роли БД

SQL для создания `crm_app_user`, `crm_admin_user` (BYPASSRLS), `crm_migrator` (BYPASSRLS+CREATEDB).

## 5. Открытые вопросы (статус после P0-блока)

### Закрыто (11 архитектурных решений)

CTO-1..5, Биз-1, Биз-2, Ю-1, Ю-2, Ю-3 + закрытые ранее в state-machines.

### Осталось открытым P0 — артефакты от заказчика

- **Б-1** реквизиты юр.лица (до спринта 1)
- **Б-2** формат выгрузки в 1С (до спринта 8)
- **Ю-4** уведомление в Роскомнадзор (до запуска prod)
- **Диз-1** Figma-макеты 8 экранов (до спринта 4)
- **DO-1** выбор облачного провайдера (до спринта 0)

### Новые P0 — производные от P0-блока

- **Ю-2-доп** — формулировка согласия физлица в трёхзвенной цепочке
- **Ю-3-юр** — юридический текст для оферты по chargeback workflow
- **Ю-8** — зеркальные гарантии в обоих договорах

### Открытые SM-вопросы (не P0)

- SM-3 — отмена pending клиентом (P2)
- SM-10 — retry failed report (P2)
- SM-11 — флаг `file_deleted` для report_jobs (P2)
- SM-12 — лимит concurrent отчётов (P1)

**Итого:** 33 открытых вопроса (7 P0 + 17 P1 + 9 P2), плюс 3 новых производных = 36, из них 9 P0.

## 6. Дефолты (13 штук)

- ДЕФ-1: сессия админа 4ч idle / 12ч абсолют
- ДЕФ-2: ротация пароля админа 90 дней
- ДЕФ-3: лимит ручного начисления для `support` 1000 ₽ или 10 лидов / 24ч
- ДЕФ-4: порог four-eyes 50 000 ₽
- ДЕФ-5: ✅ таймаут pending платежа soft 30 минут (CTO-3)
- ДЕФ-6: TTL отчёта в S3 7 дней
- ДЕФ-7: минимальная сумма пополнения 100 ₽
- ДЕФ-8: кастомные роли админов через UI — только enum на MVP
- ДЕФ-9: принудительная смена пароля клиента — НЕ требуется (NIST 2017+)
- ДЕФ-10: ✅ hard timeout pending платежа 24 часа (CTO-3)
- ДЕФ-11: ✅ длина основания impersonation мин. 30 символов (Ю-1)
- ДЕФ-12: ✅ TTL кода impersonation 15 минут, 5 попыток (Ю-1)
- ДЕФ-13: ✅ длина impersonation-сессии 1 час (Ю-1)

## 7. Объединение в единый файл (вариант А)

После P0-блока выбран **вариант А:** главный narrative-файл `CRM_bp-gr_Инструкция_v8_1.md` с правками в ~26 разделах + 5 приложений-файлов остаются как есть.

**Реализованные правки:** 22 точечные + 2 совершенно новых раздела:

| Раздел v8.1 | Тип правки | Источник |
|-------------|------------|----------|
| Шапка + Содержание | Версия 8.1, новый блок «Что нового в v8.1» | все P0 |
| 1.5, 1.6 | Реселлерская модель + биллинг с себестоимостью + workflow возвратов | Ю-2, Биз-2 |
| 3.2 | RLS активный + 3 роли БД + `TenantAwareJob` | CTO-5 |
| 5.5 | `ProcessWebhookJob` записывает `supplier_lead_costs` в той же транзакции | Ю-2 |
| 7.1 | Карта таблиц с новыми блоками v8.1 | Ю-1, Ю-2, 152-ФЗ |
| 7.2 | ASCII-диаграмма заменена краткой версией + ссылка на Приложение Б | пробел №3 |
| 7.3 DDL `users` | JSONB вместо 4 BOOLEAN + sound_enabled + CHECK | CTO-4 |
| 7.3 DDL `tenants` | +`chargeback_unrecovered_rub` | Ю-3 |
| 18.5 | Подтверждено JSONB как финал | CTO-4 |
| 20.2.2 | 4 заглушечных тарифа | Биз-1 |
| 20.2.3 | Полностью переписан с 5 состояниями enum | CTO-1, CTO-2, Биз-2 |
| 20.5 | Жизненный цикл pending, cron, enum `failure_reason` | CTO-3 |
| 20.6 + 20.6.1 | `refund_requests.source` + chargeback workflow | Ю-3 |
| **Новый 20.12** | «Себестоимость лидов» — 5 подразделов | Ю-2 |
| 22.6 | Линтер моделей + утилита `assertTenantIsolation` + RLS-тест | CTO-5 |
| 22.9 | Самостоятельный оператор, 3 типа согласий, новый 22.9.6 impersonation | Ю-1, Ю-2 |
| 23.5 | 3 новых cron'а v8.1 | CTO-1, CTO-2, CTO-3 |
| **Новый 23.10** | «Админка SaaS» — 5 подразделов | пробел №5 |
| 27.1 | Дополнен таблицей из 11 решений P0-блока | все P0 |
| 27.2 | Заменён ссылкой на Приложение Е | — |
| 27.3 | Спринты пересмотрены с 16 на 16+2 (~8.5 мес) | CTO-1, CTO-5, Ю-2, Ю-1, Ю-3 |
| Новый раздел 28 | «Приложения» со списком 5 файлов | организация |

**Шифры приложений:** А = `schema.sql`, Б = `ER_диаграмма`, В = `State_machines`, Г = `Админка_SaaS`, **Д = резерв**, Е = `Открытые_вопросы`.

## 8. Самопроверки артефактов

- **`schema.sql`**: 47 таблиц, 81 FK (0 висящих), 67 индексов, 33 CHECK, 29 RLS политик, 0 дубликатов CREATE TABLE.
- **`ER_диаграмма_v8_1.md`**: 6 erDiagram-блоков + 1 flowchart, все таблицы в связях объявлены.
- **`State_machines_v8_1.md`**: 4 stateDiagram-блока, балансы корректны.
- **`Админка_SaaS_v8_1_драфт.md`**: 9 разделов, обновлены §2.2 (RLS), §4.2 (impersonation), §4.3 (chargeback), новый §4.9 (поставщики).
- **`Открытые_вопросы_v8_1.md`**: 41 вопрос, 8 закрытых ✅, цифры (41/8/33/7/17/9) сошлись.
- **`CRM_bp-gr_Инструкция_v8_1.md`**: 290 КБ, 4787 строк (исходник v8.0 — 225 КБ, 4279 строк, прирост ~+30%). 75 упоминаний v8.1 vs 6 v8.0. Все 11 P0-решений упоминаются. 0 остатков старого RLS «опционально». 0 остатков старых `notify_*` BOOLEAN.

---

# ЧАСТЬ IV. ВЫПУСК ПРИЛОЖЕНИЙ Д/Ж/З/И И ПЕРЕХОД v8.1 → v8.2 (04.05.2026)

**Контекст:** работа в фоне к сбору скриншотов оригинала через Claude в Chrome — закрытие оставшихся пробелов архитектурной документации.

**Что сделано:**

1. Выпущены 4 новых приложения (Д, Ж, З, И) — 276 КБ / ~2550 строк документации.
2. Закрыты последние 2 пробела из конспекта анализа v8.0 (🟠 №7 — pd_subject_requests, 🟡 №11 — runbook).
3. Структурно закрыты 4 юридических P0 (Ю-2-доп, Ю-3-юр, Ю-4, Ю-5, Ю-8) — ждут юр. редактуры.
4. Слияние документации v8.1 → v8.2: точечные правки главного narrative и расширение Открытых вопросов.

## 1. Артефакты сессии

| Шифр | Файл | Размер | Закрывает |
|---|---|---|---|
| **Д** | `Workflow_pd_subject_requests_v8_1.md` | 63 КБ, 655 строк, 11 разделов | 🟠 №7 целиком |
| **Ж** | `Oferta_i_Politika_v8_1.md` | 107 КБ, 834 строки, 26 + 5 разделов | Ю-5, Ю-2-доп, Ю-3-юр, Ю-8 (структурно) |
| **З** | `Uvedomlenie_RKN_v8_1.md` | 60 КБ, 462 строки, 11 + 3 + 3 разделов | Ю-4 (структурно) |
| **И** | `Runbook_ekspluatatsii_v8_1.md` | 46 КБ, 605 строк, 13 + 3 разделов | 🟡 №11 |

Дополнительно:

- `CRM_bp-gr_Инструкция_v8_2.md` — обновлённый главный narrative.
- `Открытые_вопросы_v8_2.md` — 4 юр. P0 переведены в статус 🟦 (структурно решено).

## 2. Подробно по приложениям

### Приложение Д — Workflow обращений субъектов ПДн

**Назначение:** развёртка раздела 22.9.5 v8.1 (таблица определена, но workflow помечен «готовится при необходимости»).

**Содержание (11 разделов):**

1. **Зачем отдельный документ.** Таблица отличий от запроса самого тенанта — 8 параметров.
2. **Кто такие субъекты ПДн в трёхзвенной модели.** Перечень таблиц с ПДн физлица + матрица «что мы можем сделать по каждому из 4 типов запроса» (`access`/`deletion`/`correction`/`restriction`).
3. **State machine из 6 статусов** (`received → identity_verification → identity_verified → processing → completed`/`rejected`) + enum `rejection_reason` (5 значений).
4. **Временна́я раскадровка внутри 30 дней** — отдельно для `deletion`, `access`, `correction`. Цветовая индикация в админке.
5. **Процедура проверки личности** — 4 способа (SMS, нотариальное заявление, личная явка, ЕСИА). Антифрод-блок.
6. **Уведомление вторичных операторов** — уведомление crm.bp-gr.ru вверх (письмо №6) + уведомление тенантов-получателей вниз (письмо №7).
7. **7 шаблонов писем** с переменными `{{...}}`.
8. **UI / экраны в админке** для роли `compliance` — 4 экрана.
9. **20 открытых вопросов** (OPEN-Д-1..20) с приоритетами P0–P3.
10. **Миграция в schema v8.2** — `ALTER TABLE pd_subject_requests` с 9 новыми полями, 4 индексами, 3 CHECK.
11. **Что обновить в смежных документах** при выпуске v8.2.

**Блокирующие вопросы:** OPEN-Д-6 (SMS-провайдер), OPEN-Д-15 (`system_settings.privacy_contact_email`), OPEN-Д-16 (где публиковать `privacy_email`).

### Приложение Ж — Оферта + Политика конфиденциальности

**Содержание (3 части, 26 + 5 разделов):**

**Часть А. Публичная оферта (14 разделов):**

- А.1 — термины с понятием «Поставщик» и реселлерской позицией
- А.2 — предмет с «не контролируем источники лидов» (Ю-2)
- А.4–А.5 — тарифы, переход в 00:00 МСК (CTO-1), pending 30/24 (CTO-3), жёсткий expired (CTO-2)
- **А.6.4 — Импersonation** с одноразовым кодом (Ю-1)
- **А.8 — Обработка ПДн** в реселлерской модели: трёхзвенная цепочка, 3 типа согласий с формулировкой `pd_processing_as_data_provider` (А.8.3.в)
- **А.9.4 — Chargeback workflow** юридически (Ю-3-юр)
- **А.9.6 — Зеркальные гарантии** (Ю-8)
- А.10–А.14 — удаление аккаунта, ответственность, изменения, споры, реквизиты
- Приложение №1 — структура таблицы тарифов (Биз-1)

**Часть Б. Политика конфиденциальности (12 разделов):**

- Б.1 — категории субъектов ПДн (4 группы)
- Б.2 — состав данных по каждой группе
- Б.3 — цели и правовые основания
- Б.4 — кому передаём (хранение в РФ)
- Б.6 — доступ сотрудников по ролям
- **Б.7.3 — рекомендуемая формулировка согласия физлица для согласования с юристом Поставщика (Ю-2-доп)**
- Б.8 — сроки хранения по 9 категориям
- Б.9 — права субъектов со ссылкой на Приложение Д
- Б.10 — четырёхуровневая изоляция включая RLS (CTO-5)

**Часть В. Рабочие материалы:**

- В.1 — таблица соответствия 17 архитектурных решений v8.1 пунктам Оферты/Политики
- **В.2 — 20 открытых вопросов** (OPEN-Ж-1..20)
- В.3 — что обновить в 7 смежных документах
- В.4 — чек-лист публикации (12 пунктов)
- В.5 — журнал версий

**Блокирующие вопросы:** OPEN-Ж-1 (юр. редактура), Ж-3 (согласование с юристом Поставщика), Ж-4 (зеркальная гарантия в договоре), Ж-19 (название платформы), Ж-20 (адрес `privacy_email`).

### Приложение З — Уведомление в Роскомнадзор

**Назначение:** структурный шаблон по форме Приказа РКН №180 от 28.10.2022 (действует с 26.12.2022).

**Само уведомление (11 разделов по структуре ч. 3 + ч. 3.1 ст. 22 ФЗ-152):**

1. Сведения об операторе (реквизиты Б-1 как переменные).
2. Цели обработки — **7 целей**: регистрация, биллинг, **приём лидов от агрегатора (Цель 3 — ключевая)**, обработка обращений субъектов, ИБ, маркетинг, работники.
3. Меры защиты — 4 уровня изоляции; пункт 3.4 — TLS, bcrypt, AES-256, заявление о ненужности сертифицированных СКЗИ под УЗ-4.
4. Ответственное лицо.
5. **Матрица по 7 целям** — 5 параметров на каждую (категории субъектов / категории ПДн / правовое основание / перечень действий / способы).
6–10. Дата начала, срок прекращения, **трансграничная передача — НЕТ**, местонахождение БД в РФ, ИС не государственная.
6. Уровень защищённости — обоснование УЗ-4 по постановлению №1119.

**Приложения к шаблону:**

- З.А — чек-лист подачи (14 шагов)
- З.Б — таблица сценариев изменения сведений (Приложение №2 к Приказу №180)
- З.В — связи с другими открытыми вопросами

**Часть В. Рабочие материалы:** 14 открытых вопросов (OPEN-З-1..14).

**Блокирующие вопросы:** OPEN-З-1 (подтвердить УЗ-4), З-2 (назначить ответственного), З-3 (получить КЭП), З-4 (закрыть DO-1 для адреса ЦОД), З-5 (опубликовать Политику до подачи).

**Источники для верификации формы:**

- Приказ Роскомнадзора от 28.10.2022 №180
- ст. 22 ч. 3 + ч. 3.1 ФЗ-152
- Сайт РКН: pd.rkn.gov.ru/operators-registry/notification/form/

### Приложение И — Runbook эксплуатации

**Содержание (13 разделов + 3 рабочих):**

1. **Подготовка дежурного** — 10 ресурсов с проверочными командами.
2. **Общий алгоритм** при срабатывании любого алерта — 5 шагов за 60 секунд + жёсткий список «никогда не делать».

**9 типовых инцидентов:**

| # | Инцидент | Уровень | Привязка |
|---|---|---|---|
| 3 | Webhook от crm.bp-gr.ru пропал | CRITICAL | Реселлерская модель Ю-2 |
| 4 | Backlog очередей | WARNING→CRITICAL | Supervisor 23.6, Horizon |
| 5 | Платежи: late_webhook_ignored / pending зависли | WARNING→CRITICAL | CTO-3, ДЕФ-4 |
| 6 | tariffs:apply-scheduled не отработал | WARNING | CTO-1 |
| 7 | **RLS leak подозрение** | **CRITICAL ВСЕГДА** | CTO-5 — отдельный жёсткий протокол: уведомление РКН за 24/72 часа |
| 8 | Chargeback unrecovered | WARNING | Ю-3 |
| 9 | БД: lag/master/full disk | WARNING/CRITICAL | WAL-G, протокол failover |
| 10 | Бэкап test-restore упал | WARNING→CRITICAL | 23.7.2 |
| 11 | TLS / DNS | CRITICAL | — |

1. **Эскалация** — таблица из 6 цепочек (дежурный → ТД → бизнес-владелец, → DevOps, → finance, → compliance, → юрист).
2. **Журнал прецедентов** — пустой шаблон + 1 пример (HMAC-секрет crm.bp-gr.ru).

**Часть В. Рабочие материалы:** 10 открытых вопросов (OPEN-И-1..10).

**Блокирующие вопросы:** OPEN-И-1 (таблица `incidents_log` для compliance), OPEN-И-2 (где хранить контакты эскалации), OPEN-И-5 (шаблон уведомления РКН об инциденте 24/72 часа).

> **⚠ Историческая запись (срез v8.1).** В v8.3.1 (05.05.2026) ID `OPEN-И-2` переиспользован: текущий смысл — «стратегия CRM-интеграций» (✅ закрыт 04.05). Прежний смысл «контакты эскалации» переименован в `OPEN-И-12` (⏸ P1). `OPEN-И-1` тоже закрыт (создана таблица `incidents_log` в schema.sql v8.2). Текущая трактовка — в `Открытые_вопросы_v8_3.md` v1.7+ и `Runbook_ekspluatatsii_v8_2.md` Часть В.

## 3. Обновления narrative и Открытых вопросов (v8.1 → v8.2)

### Главный файл `CRM_bp-gr_Инструкция_v8_2.md`

| Где | Что изменилось |
|---|---|
| Шапка | Версия 8.1 → 8.2; готовность дополнена «юридические документы — структурно готовы»; «5 приложений» → «9 приложений» |
| Шапка | Добавлен новый блок «Что нового в v8.2 относительно v8.1» |
| 22.9.4 | Ссылка на **Приложение З** с конкретикой про форму Приказа №180 |
| 22.9.5 | Ссылка на **Приложение Д** |
| 25.6 | Ссылка на **Приложение И** с перечислением 9 типовых сценариев |
| 28 | Таблица приложений расширена с 5 до **9 строк** (добавлены Д, Ж, З, И); сводка «по адресатам» (10 строк по ролям) |
| Финальная строка | `*Конец документа CRM_bp-gr_Инструкция_v8_2.md*` |

**Размер:** 4787 строк (v8.1) → **4823 строки** (v8.2). **0 остатков** «готовится при необходимости» в файле.

### `Открытые_вопросы_v8_2.md`

| Где | Что изменилось |
|---|---|
| Шапка | v8.1/1.1 → v8.2/1.2; добавлен символ 🟦 в легенду («структурно решено в одном из приложений») |
| 0.1 Сводная статистика | Юрист: 6 открытых → 2 (4 переведены в 🟦). Открытых P0 в таблицах: 7 → **0**. Новые P0: только Б-1, Б-2, Диз-1, DO-1 — **итого 4** |
| Новый раздел 0.3 | «Что закрыто структурно» — таблица 5 строк (Ю-4, Ю-5, Ю-2-доп, Ю-3-юр, Ю-8) |
| 1. Юристу | Все 5 юридических P0 переведены в 🟦 со ссылками на пункты приложений |
| 9. | Полностью переписан: «Что сделано в сессии 04.05.2026 и что осталось» |

**Размер:** 238 строк (v8.1) → **272 строки** (v8.2).

## 4. Состояние v8.2

**Архитектурные изменения:** НЕТ. Все изменения — выпуск структурной документации, отражающей решения v8.1; точечные ссылки в narrative; переклассификация юридических P0 как «структурно готово, ждёт редактуры».

**Закрыто пробелов:** 🟠 №7 ✅ (приложение Д); 🟡 №11 ✅ (приложение И).
**Закрыто структурно (требует юр. редактуры):** Ю-2-доп, Ю-3-юр, Ю-4, Ю-5, Ю-8 — все через приложения Ж, З.
**Архитектурно открыто:** 0 P0. Полный список P0-блокеров — 4 артефакта от заказчика (Б-1, Б-2, Диз-1, DO-1) + параллельный трек (скриншоты Биз-6 + юр. редактура Ж/З).

**Состояние v8.2:** 100% готовность по архитектуре и структуре документации.

---

# ЧАСТЬ V. v8.3+ → v8.3++ optimized (05.05.2026)

**Стартовое состояние:** архив v8.3+ (16 файлов после изучения архива и интеграции аудита партий 1–11).
**Финальное состояние:** архив v8.3++ optimized (16 файлов после оптимизации).

## 1. Хронология сессии (4 фазы)

### Фаза 1 — Изучение архива

**Запрос:** «изучи файлы».
**Результат:** карта архива v8.3+ (16 файлов), 30 продуктовых решений из интервью 04.05 в шапке narrative, 4 главных открытия аудита партий 1–11 в Прил. М v1.0, главный P0-блокер от заказчика — Б-1 (реквизиты ООО). Предложены 4 направления продолжения.

### Фаза 2 — Обработка партий аудита 12–15

**Триггер:** загрузка 4 файлов аудита (`audit-batch-12..15-2026-05-05.md`).
**План:** Прил. М → v1.1 → Открытые_вопросы → v1.6 → schema.sql → v8.3 → README + CHANGELOG + конспект.

#### Шаг 1 — Прил. М v1.0 → v1.1 ✅

Файл: `Analiz_originala_v8_3.md` (957 → 1503 строки, 132 КБ).

| Раздел | Что сделано |
|---|---|
| Шапка | v1.0 → v1.1, источники + 4 файла аудита |
| §0 TL;DR | 3-е расхождение (модель напоминаний), 2-е подтверждение (security превосходство) |
| §2.5 | Полностью переписан (Биз-10 переоткрыт) |
| §3.5 НОВЫЙ | DDL для schema.sql v8.3: 5 подразделов |
| §5 | Добавлены Биз-14/15/16 |
| §6.6 НОВЫЙ | Security-антипаттерны оригинала + повторные подтверждения prompt injection |
| §7.1 | Расширена таблица миграции v8.1 → v8.2 → v8.3 |
| §9 НОВЫЙ | Детальная развёртка партий 12–15 (6 подразделов) |

#### Шаг 2 — Открытые_вопросы v1.5 → v1.6 ✅

Файл: `Открытые_вопросы_v8_3.md` (273 → 421 строка).

| Что | Деталь |
|---|---|
| §0 Сводка | 47 → 50 продуктовых, 10 → 13 открытых, 7 → 10 P2 |
| §12 НОВЫЙ | 8 подразделов: сводка, Биз-10 переоткрыт, Биз-14, Биз-15, Биз-16, изменения schema.sql v8.3, дополнения в narrative v8.4, security-антипаттерны |

#### Шаг 3 — schema.sql v8.2 → v8.3 ✅ (с компакцией посередине)

Файл: `schema.sql` (1854 → 1982 строки, +128, +7%).

**Применённые патчи (7 групп):**

1. **Шапка** — версия v8.2 → v8.3 + 5 новых пунктов.
2. **`suppliers`** — 5 полей capabilities: `channel CHECK IN ('sites','calls','sms')`, `supports_sender_name BOOL`, `supports_keyword BOOL`, `supports_csv_upload BOOL DEFAULT TRUE`, `supports_domains_list BOOL DEFAULT TRUE`.
3. **`tenants.desired_daily_numbers INT NULL`** — с CHECK > 0 (Биз-16).
4. **`deals`** — удалены поля `reminder_text`, `reminder_at` и индекс `idx_deals_reminder`.
5. **`reminders`** — переписана: `user_id` → `created_by`, добавлены `assignee_id` (NULL), `completed_at` (заменяет `is_done`), сохранены `is_sent + sent_at` для cron.
6. **Seed `INSERT INTO suppliers`** — обновлён значениями capabilities для B1/B2/B3.
7. **`system_settings`** — `schema_version` → '8.3', добавлены 3 ключа cron purge-deleted.

**Self-review пройден:** 0 orphan-ссылок, RLS на reminders сохранён, 51 логическая таблица, 81 индекс, 31 RLS-политика.

### Фаза 3 — Финальная сборка после компакции

**Точка компакции:** середина Шага 3 (схема.sql). После compaction Claude получил summary с состоянием задачи. Команда: `Continue`.

**Создано:**

1. **CHANGELOG-v8_3.md** (306 строк) — спутник для backend.
2. **README → v8.3++** — обновлены упоминания файлов, добавлены 4 файла аудита + CHANGELOG + конспект.
3. **Konspekt_sessii_05_05_2026_obrabotka_partiy_12_15.md** (311 строк).

**Архив v8.3+ → v8.3++:** 16 → 21 файл.

### Фаза 4 — Структурная оптимизация

**Триггер:** «оптимизируй документацию в части количества файлов, но без потери информации».
**Дополнительно:** 5 SVG-логотипов (`liderra-favicon.svg`, `liderra-icon.svg`, `liderra-logo-dark.svg`, `liderra-logo-full.svg`, `liderra-logo-mono.svg`).

**Стратегия:** 3 варианта (A — агрессивное 27→12, B — умеренное 27→21, C — минимальное 27→23). Через `ask_user_input_v0` запрошен выбор.

**Ответ:** Q1: «B — умеренное». Q2: «Встроить в brandbook.md inline».

**Итог:** Вариант B + SVG inline = 27 → 16 файлов (-41%).

#### Объединения

| Что | В файл | Δ файлов |
|---|---|---|
| `CHANGELOG-v8_2.md` + `CHANGELOG-v8_3.md` | `CHANGELOG_schema.md` | -1 |
| `ER_диаграмма_v8_1.md` + `State_machines_v8_1.md` | `Приложение_Б_В_БД_диаграммы_v8_3.md` | -1 |
| 5 SVG-файлов лого | inline в `brandbook.md` v1.1 § 9.1–9.5 | -5 |
| `audit-batch-12..15-2026-05-05.md` (4 файла) | `Аудит_partii_12_15_originala_v8_3.md` | -3 |
| 2 конспекта 05.05 | `Konspekt_sessii_05_05_2026.md` | -1 |

#### Технические решения

**Иерархия заголовков:** Python-скрипт сдвига заголовков на 1 уровень глубже. Mermaid-блоки внутри ` ``` ` не тронуты.
**Кросс-ссылки:** в `CRM_bp-gr_Инструкция_v8_3.md` — 4 inline-ссылки на ER/State machines заменены, добавлено `⚠ Важно для читателя` с актуальным маппингом. Финальный sanity-check: все ссылки на старые имена остались только в семантически правильных контекстах.

## 2. Главные продуктовые/архитектурные результаты дня

- **Биз-10 переоткрыт** — модель напоминаний переписана с `deals.reminder_text/reminder_at` на отдельную таблицу `reminders` с минимальным паритетом (`text + remind_at + created_by + created_at` + наше расширение `completed_at`).
- **B1/B2/B3 capabilities жёстко формализованы** — 5 новых полей в `suppliers` с обновлённым seed по цитате UI оригинала.
- **Outbound webhooks** — окончательный вердикт «нет» с 7 независимыми линиями доказательств.
- **3 новых вопроса** — Биз-14 (TTL soft-delete = 180 дней + cron disabled), Биз-15 (OSINT-wizard не делаем), Биз-16 (`tenants.desired_daily_numbers`).
- **Security как differentiator** — оригинал не имеет 2FA / journal / sessions; антипаттерны (пароль plaintext, API-ключи в `<input type="text">`); у нас всё это решено правильно.

## 3. Принятые продуктовые решения

### Биз-10 (переоткрыт)

**Старая (v1.5):** одно напоминание на сделку — поля `deals.reminder_text` + `deals.reminder_at`.
**Новая (v1.6):** какую модель напоминаний делаем — отдельную таблицу с минимальным паритетом или сохранить простую?
**Дефолт:** отдельная таблица `reminders` с полями `text + remind_at + created_by + created_at` + `completed_at` для бесплатного дашборда задач.

### Биз-14 (новый, P2)

**Контекст:** в оригинале экран «Удалённые проекты ГЦК» показывает проекты, удалённые ≥3 месяца назад. У нас retention policy не определена.
**Дефолт:** 180 дней (6 месяцев) + cron `projects:purge-deleted` отключён по умолчанию до Б-1.

### Биз-15 (новый, P2)

**Контекст:** в оригинале есть OSINT-wizard «Рекомендации источников».
**Дефолт:** не делаем на MVP, ставим в backlog (P3).

### Биз-16 (новый, P2)

**Контекст:** в оригинале есть аккаунтное поле «Желаемое кол-во номеров в день».
**Дефолт:** да, добавляем как `tenants.desired_daily_numbers INT NULL`. Затраты ~0.1 спринта.

### Структура архива (Вариант B + SVG inline)

**Решение:** объединить тесно связанные технические артефакты, оставить роле-ориентированные документы раздельно. SVG логотипа — inline в brandbook.

## 4. Финальный состав архива (16 файлов)

```
1.  README_АРХИВ_v8_3.md                          (v8.3++ optimized)
2.  CRM_bp-gr_Инструкция_v8_3.md                  (главный narrative + примечание)
3.  schema.sql                                     (v8.3)
4.  CHANGELOG_schema.md                            ← объединён
5.  Приложение_Б_В_БД_диаграммы_v8_3.md           ← объединён
6.  Админка_SaaS_v8_2.md                           (Прил. Г)
7.  Workflow_pd_subject_requests_v8_2.md           (Прил. Д)
8.  Открытые_вопросы_v8_3.md                       (Прил. Е, v1.6)
9.  Oferta_i_Politika_v8_2.md                      (Прил. Ж)
10. Uvedomlenie_RKN_v8_2.md                        (Прил. З)
11. Runbook_ekspluatatsii_v8_2.md                  (Прил. И)
12. Vybor_oblaka_v8_3.md                           (Прил. К)
13. Analiz_originala_v8_3.md                       (Прил. М, v1.1)
14. brandbook.md                                   (v1.1, +5 SVG inline)
15. Аудит_partii_12_15_originala_v8_3.md          ← объединён
16. Konspekt_sessii_05_05_2026.md                  ← объединён
```

Размер архива: **1.3 МБ**, **15 050 строк** во всех .md/.sql.

## 5. Метрики сессии 05.05

| Параметр | Значение |
|---|---|
| Длительность | одна расширенная сессия (несколько часов) |
| Компакций контекста | 1 (посередине Шага 3) |
| Партий аудита проанализировано | 4 (12, 13, 14, 15) |
| Продуктовых решений принято | 5 (Биз-10 переоткрыт + Биз-14/15/16 + структура архива) |
| Файлов обновлено | 6 (Прил. М, Открытые_вопросы, schema.sql, brandbook, главный narrative, README) |
| Файлов создано | 4 (CHANGELOG_schema, Прил. Б+В, Аудит_partii_12_15, Konspekt_sessii_05_05_2026) |
| Файлов в финальном архиве | 16 (было 27 на пике) |
| Линий доказательств отсутствия outbound webhooks | 5 → 7 |

## 6. Уроки сессии

1. **Компакция контекста — реальное явление.** При длинных сессиях вести явный план в начале и отмечать `✅`/`⏸` по ходу, чтобы summary мог его сериализовать.
2. **Согласование стратегии до выполнения.** Перед оптимизацией архива представлены 3 варианта с явным анализом, выбор через `ask_user_input_v0`.
3. **Self-review после массивных изменений в schema.sql** обязателен. После применения 7 групп патчей выполнена проверка на orphan-ссылки и контроль метрик.
4. **Иерархия заголовков при объединении** — нетривиальная задача. Использован Python-скрипт со сдвигом и трекингом fenced code blocks.
5. **Кросс-ссылки при оптимизации** — главный риск потери целостности. Стратегия: inline-ссылки заменить, исторические оставить с `⚠`-примечаниями.

---

# ЧАСТЬ VI. СОГЛАШЕНИЯ О РАБОТЕ И БЭКЛОГ

## 1. Соглашения о работе с пользователем

- Пользователь — **заказчик/архитектор проекта**, отвечает за бизнес-решения и принимает архитектурные.
- **Документацию v8.0 целиком в контекст не загружать** — обращаться по разделам по запросу.
- Скриншоты от Claude в Chrome — **партиями по 3–5 штук**, не вся пачка сразу.
- **JPEG 80% / ширина ≤1500px** для экономии токенов.
- ПДн на скриншотах закрашены пользователем.
- Архитектурные изменения — **только с обсуждением, по одному вопросу за раз**.
- Файлы выкладываются в `/mnt/user-data/outputs/`, доступны через `present_files`.
- Тег `[?]` для маркировки решений «по умолчанию», требующих подтверждения.
- При коротких сообщениях типа «делай» / «б» / «а» — действовать без переспрашивания, но если ответ может быть истолкован двояко — фиксировать явно.

## 2. Что важно при возобновлении работы

1. **Главный файл — `CRM_bp-gr_Инструкция_v8_3.md`** (актуальная версия после v8.3++ optimized).
2. **`schema.sql` v8.3** — текущая ревизия. Если потребуются изменения схемы, оформляются как новая ревизия.
3. **Шифры приложений исчерпаны** (А, Б, В, Г, Д, Е, Ж, З, И, К, М). Дальнейшие — Л, Н, О...
4. **Юр. документы (Ж, З) — драфты v0.1** до юр. редактуры. После — версионируются как «оферта v1.0», «политика v1.0», «уведомление v1.0», фиксируются в `tenant_consents.document_version`.
5. **Текущий фокус для команды:** ждём ответы заказчика по Б-1, Б-2, Биз-10/14/15/16, Биз-11/12/13, Диз-1, DO-1.
6. **Параллельно:** сбор скриншотов crm.bp-gr.ru через Claude в Chrome. Юристу — шаблоны Ж и З уже на руках.

## 3. Бэклог задач

### Что не сделано (для следующей сессии)

| Что | Приоритет | Оценка | Когда |
|---|---|---|---|
| Прил. Л — HTML/CSS/JS прототипы 8 экранов | P1 | ~5–6 спринтов | Отдельная серия сессий |
| v8.4 narrative — раскрытие 30 решений + интеграция выводов аудита | P1 | ~3–4 сессии | После Прил. Л / параллельно |
| Получить ответы заказчика на Биз-10/14/15/16 | P2 | внешний срок | До спринта 5 (Биз-10) и спринта 1 (Биз-16) |
| Получить ответы по Биз-11/12/13 | P2 | внешний срок | Спринты 7, 11, Post-MVP |
| Получить ответ по Б-1 (реквизиты ООО) | P0 | внешний срок | До спринта 0 (блокер) |
| Обновить ER-диаграмму до v8.3 | P2 | ~1 сессия | Перед v8.4 narrative |

### Когда придут ответы на оставшиеся P0-артефакты от заказчика

- Б-1, Б-2 → обновить `legal_entities` сидом, реализовать формат 1С.
- Ю-2-доп, Ю-3-юр, Ю-4, Ю-8 → доработать оферту, политику, уведомление в РКН.
- Диз-1 → разработка фронтенда по макетам.
- DO-1 → инфраструктурный код под выбранное облако.

## 4. Идеи на post-MVP (v2)

- Множественные пользователи на тенант + ролевая модель
- CSV-импорт исторических данных
- Outbound webhook (наш аналог → AmoCRM/Битрикс24)
- Интеграции с телефонией (Mango, UIS)
- Email/SMS-кампании по сделкам
- Автоматизации (правила «если X — то Y»)
- Кастомные домены клиентов
- Тёмная тема, английская локализация
- Мобильные приложения
- AI-ассистент

---

# ЧАСТЬ VII. АУДИТ СВЯЗНОСТИ АРХИВА И ПАТЧ v8.3.1 (05.05.2026, поздний вечер)

**Стартовое состояние:** архив v8.3++ optimized + правила Claude (17 файлов).
**Финальное состояние:** архив v8.3.1 (17 файлов, без изменений в составе; 6 файлов содержательно обновлено).
**Назначение сессии:** гигиенический аудит после серии оптимизаций v8.3++ optimized + добавления `Pravila_raboty_Claude_v1_1.md` и `Объединённый_конспект.md`. Ни одного архитектурного изменения.

## 1. Что обсуждалось

### 1.1. Стартовая оценка состояния

Запрос заказчика: «Давай начнем работу. Предложи варианты». Claude представил 6 вариантов работы (Прил. Л, юр. редактура Ж, пакетная закрытие не-P0, OPEN-И-1 incidents_log, аудит связности, подготовка v8.4) с рекомендацией «вариант 5 → потом вариант 1». Заказчик выбрал **вариант 5 — аудит связности**.

### 1.2. Аудит — методология

Через `bash_tool` + `grep` + Python проведено 7 проверок по 17 файлам архива (~1.3 МБ, ~15 050 строк):

1. Версионные метки в шапках файлов.
2. Кросс-ссылки на удалённые/переименованные файлы.
3. Шифры приложений vs §4.8 правил.
4. Остатки `TBD` / `готовится` / `на согласование` в финальных версиях.
5. ID открытых вопросов — сквозная нумерация.
6. `schema.sql` vs narrative — упомянутые сущности.
7. Метрики `schema.sql` (self-review §4.6 правил) — orphan-FK, RLS-покрытие.

### 1.3. Основные находки аудита

**Сводка:** 4 🔴 ошибки, 11 🟡 расхождений, 3 ✅ чистых блока.

**🔴 ошибки** — все про навигацию между файлами, **ни одной про DDL или содержательную целостность архитектуры**:

- 🔴-1, 🔴-2, 🔴-3: 4 ссылки на удалённый `Konspekt_sessii_05_05_2026.md` без замены на актуальный `Объединённый_конспект.md` (в `Открытые_вопросы`, `CRM_bp-gr_Инструкция`, `Аудит_partii_12_15_originala`).
- 🔴-4: таблица приложений в §28 narrative содержит устаревшие имена файлов и счётчики (срез на 04.05) без явной пометки об историчности.

**🟡 расхождения** — гигиена: устаревшие пометки про «запланирован», расхождения в OPEN-И-2 (см. §1.4 ниже), счётчик OPEN-* в шапке Прил. Е (было «64», фактически 65), и т.п.

**✅ чистые блоки:** шифры приложений, ID открытых вопросов (с одной оговоркой), метрики `schema.sql` (51 таблица + 12 партиций, 81 индекс, 31 RLS, 0 orphan-FK, 0 дубликатов CREATE TABLE).

### 1.4. Коллизия OPEN-И-2 — отдельный разбор

При планировании патча обнаружилось, что один и тот же ID `OPEN-И-2` означает разные вопросы в разных местах архива:

| Источник | Смысл | Статус |
|---|---|---|
| Шапка Runbook v8.2 + Прил. Е v1.6 + narrative §28 + README | Стратегия CRM-интеграций | ✅ Закрыт 04.05 |
| `Runbook_ekspluatatsii_v8_2.md` Часть В (стр. 564, 588) | Где хранить контакты эскалации | ⏸ P0 (по v8.1) |
| `Объединённый_конспект.md` (стр. 683) | Контакты эскалации | (исторический срез v8.1) |

Восстановленная история: в v8.1 при создании Прил. И был заведён OPEN-И-2 = «контакты эскалации» (P0). 04.05 заказчик закрыл новый вопрос про CRM-интеграции, ему **переиспользовали** ID `OPEN-И-2` без переноса старого смысла на новый ID. В Часть В Runbook'а и в исторический конспект v8.1 → v8.2 правка не дошла.

**Дополнительная находка** (всплыла в момент планирования правки): ID `OPEN-И-11` уже занят — в narrative §28 строки 4883, 4891, 4913 он используется для «миграции `crm_connections`/`crm_field_mappings`» (✅ закрыт в v8.2 в составе OPEN-И-2). То есть план «отдать `OPEN-И-11` контактам эскалации» (вариант B первоначального плана) — невозможен.

Также обнаружен внутренний рассинхрон в самом `Runbook_ekspluatatsii_v8_2.md`: шапка (стр. 7–8) объявила OPEN-И-1 и OPEN-И-2 закрытыми, но Часть В (стр. 587–588) держит их обоих как ⏸ открытые. Зафиксировано как 🟡-6.

## 2. Принятые решения

### 2.1. Решение: вариант плана аудита

**Выбор заказчика:** «Сначала разобрём 🟡-1 (OPEN-И-2 коллизия)» — раньше, чем выпускать патч с 4 🔴.

**Обоснование:** коллизия ID — потенциальный источник ошибок интерпретации в любых будущих чтениях архива; решить её до выпуска патча — правильный порядок.

### 2.2. Решение: вариант разрешения коллизии OPEN-И-2

**Из 3 вариантов первого подхода (A / B / C) выбран B.** После обнаружения занятости `OPEN-И-11` Claude предложил 3 уточнённых варианта (B′ / B″ / B‴).

**Выбор заказчика — B′:** новый ID **`OPEN-И-12`** для «контактов эскалации». Существующие `OPEN-И-2` (CRM-интеграции, ✅) и `OPEN-И-11` (миграции `crm_connections`, ✅) сохраняются.

**Обоснование:**

1. Минимум правок (~5 точечных вместо переписывания нумерации).
2. Не трогает уже принятые заказчиком закрытия `OPEN-И-2` ✅ (CRM) и `OPEN-И-11` ✅ (миграции).
3. «Прыжок» в локальной нумерации Прил. И (10 → 12) — допустимая косметика.

### 2.3. Решение: приоритет нового OPEN-И-12

**Дефолт Claude:** P1.
**Решение заказчика:** P1 (= дефолт принят).

**Обоснование P1 (не P0):** контакты эскалации — блокер запуска runbook'а в действии, но не блокер старта спринта 0. Временно их можно держать в любом приватном Notion / 1Password DevOps до закрытия Б-1 + DO-4. Истинно-P0 в проекте остаётся один — Б-1.

### 2.4. Решение: финальный объём патча v8.3.1

Заказчик утвердил «да» на план патча. По решению Claude в патч вошло **15 точечных правок** (вместо изначально планировавшихся 13):

| Часть | Правок | Что |
|---|---|---|
| Часть 1 — коллизия OPEN-И-2 | 5 | переименование в Runbook (3 места), Объединённый_конспект (1), Прил. Е (1 блок) |
| Часть 2 — 4 🔴 ошибки | 4 | замены `Konspekt_sessii_05_05_2026.md` → `Объединённый_конспект.md` (3 файла) + пометка 📜 в §28 narrative |
| Часть 3 — версионные метки | 3 | Прил. Е v1.6 → **v1.7**, Runbook доп. шапка изменений 05.05, README → **v8.3.1** |
| Дополнительно (всплыло в процессе) | 3 | синхронизация Runbook Часть В с шапкой (OPEN-И-1, OPEN-И-2 ✅ статус), уточнение счётчика OPEN-* в шапке Прил. Е (64 → 66), добавление `OPEN-И-11` ✅ в Прил. Е секцию 8.4 (раньше его там не было — он жил только в narrative §28) |

## 3. Что внесено в архив

### 3.1. Файлы, обновлённые в патче v8.3.1 (6 шт.)

| # | Файл | Дельта (байт) | Дельта (строк) | Что добавлено |
|---|---|---|---|---|
| 1 | `Runbook_ekspluatatsii_v8_2.md` | +1 352 | +3 | пометка изменений 05.05 в шапке; обновление пометки про OPEN-И-3..10/12; ⚠-историческая справка к строке 566; синхронизация таблицы Часть В (OPEN-И-1 ✅, OPEN-И-2 → OPEN-И-12 P1) |
| 2 | `Объединённый_конспект.md` | +598 | +2 | ⚠-историческая запись после стр. 683 про переиспользование ID OPEN-И-2 |
| 3 | `Открытые_вопросы_v8_3.md` | +4 032 | +10 | новая шапка v1.7 (блок «Что изменилось в v1.7»); новые строки `OPEN-И-11` ✅ и `OPEN-И-12` ⏸ P1 в секции 8.4; обновление футера-истории; уточнение счётчика 64 → 66 |
| 4 | `CRM_bp-gr_Инструкция_v8_3.md` | +1 113 | +1 | пометка 📜 ИСТОРИЧЕСКАЯ ЗАПИСЬ перед таблицей §28; замена `Konspekt_sessii_05_05_2026.md` в врезке после таблицы |
| 5 | `Аудит_partii_12_15_originala_v8_3.md` | +277 | 0 | замена ссылки в секции «Связано» с расширенной пометкой |
| 6 | `README_АРХИВ_v8_3.md` | +2 010 | +3 | обновление заголовка → v8.3.1; добавление строки v8.3.1 в эволюцию версий и в таблицу истории |

**Архитектурных изменений:** 0. Все правки — кросс-ссылки, ID, версионные метки, исторические пометки.

### 3.2. Состояние ID OPEN-И-* после патча

```
OPEN-И-1   ✅ Создание таблицы incidents_log (закрыт 04.05 в schema.sql v8.2, OPEN-Д-5/И-1)
OPEN-И-2   ✅ Стратегия CRM-интеграций (Уровень 1 webhook + amoCRM в спринте 14–15) (закрыт 04.05)
OPEN-И-3   ⏸ Периодичность перевыпуска Runbook'а (P2)
OPEN-И-4   ⏸ Учения on-call / game days (P2)
OPEN-И-5   ⏸ Шаблон уведомления РКН об инциденте 24/72 часа (P1, ждёт юриста)
OPEN-И-6   ⏸ Резервный платёжный шлюз (P2)
OPEN-И-7   ⏸ Procedure для массового compensating credit (P2)
OPEN-И-8   ⏸ Регламент Status page (P1)
OPEN-И-9   ⏸ Алерт HighSignatureFailureRate (P2)
OPEN-И-10  ⏸ Регламент пост-мортема (P1)
OPEN-И-11  ✅ Миграции crm_connections / crm_field_mappings (DDL-часть OPEN-И-2, закрыт 04.05)
OPEN-И-12  ⏸ Где хранить контакты эскалации (P1, ждёт DO-4) — НОВЫЙ в v8.3.1
```

### 3.3. Итог сводки Прил. Е v1.7

**Истинно-открытых P0 в проекте:** 1 (Б-1, реквизиты юр. лица). **Без изменений** относительно v1.6.

**Продуктовых вопросов:** 50 (✅ 30 / 🟦 5 / ⏸ 13). **Без изменений** относительно v1.6 — `OPEN-И-12` относится к группе «OPEN-* в приложениях», не к продуктовым.

**OPEN-* в приложениях:** **66** (раньше шапка говорила 64, фактически было 65 + новый OPEN-И-12).

## 4. Метрики сессии

| Параметр | Значение |
|---|---|
| Длительность | 1 расширенная сессия (~поздний вечер 05.05) |
| Компакций контекста | 0 |
| Файлов прочитано/проанализировано | 17 (весь архив) |
| Найдено 🔴 ошибок | 4 |
| Найдено 🟡 расхождений | 11 (3 закрыты в этом же патче, 8 — в бэклог v8.4) |
| Архитектурных решений принято | 0 |
| Процедурных решений принято | 4 (вариант аудита 5; вариант коллизии B → B′; приоритет OPEN-И-12 = P1; объём патча 15 правок) |
| Файлов обновлено | 6 |
| Файлов создано | 0 |
| Файлов в финальном архиве | **17** (без изменений в составе) |
| Версия архива | v8.3++ optimized + правила Claude → **v8.3.1** |

## 5. Что осталось на следующий раз

### 5.1. 🟡 расхождения в бэклоге v8.4 (не критичные)

- 🟡-1 «запланирован schema.sql v8.3 + CHANGELOG-v8_3.md» в `Открытые_вопросы` стр. 207, 421 — устаревшая историческая пометка момента v1.5/v1.6 (фактически уже выпущено).
- 🟡-2 имена `audit-batch-12..15-2026-05-05.md` — оставлены с уже имеющимся ⚠-маркером.
- 🟡 (в schema.sql v8.4) — добавить явные комментарии `-- RLS не применяется: <причина>` для `impersonation_tokens` и `pd_subject_requests` (false-positive в self-review, дизайн намеренный).

### 5.2. Истинно-открытые задачи проекта (без изменений)

| Задача | Приоритет | Зависимость | Срок |
|---|---|---|---|
| **Б-1** реквизиты юр. лица | P0 | Регистрация ООО | спринт 0 |
| Диз-1 — HTML-прототипы 8 экранов → Прил. Л | P1 | — | отдельная серия сессий |
| Юридическая редактура Ю-2-доп / Ю-3-юр / Ю-4 / Ю-5 / Ю-8 | P1 | Юрист + Б-1 | до запуска prod |
| Б-2 формат выгрузки в 1С — финализация | — (✅ структурно) | Б-1 + бухгалтер | до спринта 8 |
| Уведомление РКН (Прил. З) | P0 | Б-1 → юрист → подача | до запуска prod |
| DO-2/DO-4, Диз-3 | P1 | Зависят от Б-1 | по мере поступления |

### 5.3. Кандидаты на следующую сессию Claude

Из исходного списка 6 вариантов:

- **Вариант 1 (Прил. Л — HTML-прототипы)** — единственная Claude-задача, не упирающаяся ни в кого.
- Вариант 2 (внутренний самоаудит Прил. Ж под юриста) — тоже не упирается во внешние факторы.
- Вариант 3 (пакетный разбор Биз-10..16, SM-3/10/11/12) — закрытие не-P0 с дефолтами.
- Вариант 4 (раскрытие OPEN-И-1 incidents_log в narrative и runbook'е сверх текущей DDL) — частично сделано в v8.2, можно расширить.

Вариант 6 (релиз v8.4) — рано, нет нового материала, оправдывающего мажорный апдейт.

## 6. Уроки сессии

1. **Аудит после серии «оптимизаций» обязателен.** Когда подряд идут шаги «v8.3 → v8.3+ → v8.3++ → v8.3++ optimized → +правила Claude», накапливаются устаревшие кросс-ссылки и нумерационные коллизии. Один аудит-проход в конце дешевле, чем 10 точечных правок в течение недели по обнаружению.
2. **Переиспользование ID — антипаттерн.** Когда `OPEN-И-2` сменил смысл с «контактов эскалации» на «CRM-интеграции» 04.05 без переноса старого смысла на новый ID, проблема притаилась на сутки и проявилась только в аудите 05.05. Правильный паттерн (зафиксировать в правилах Claude v1.2): **ID не переиспользуются**; закрытый/устаревший ID остаётся занятым; новый вопрос → следующий свободный.
3. **Третья коллизия (OPEN-И-11) всплыла при планировании правки**, а не при первом проходе аудита. Это значит, что в первом проходе grep не покрыл все интерпретации одного и того же ID. Урок: при разборе коллизии ID **сначала grep по всему архиву на предмет занятости соседних ID**, потом план правки.
4. **Self-review (§4.6 правил) поймал false-positive RLS-«дыр».** `impersonation_tokens` и `pd_subject_requests` без RLS — намеренный дизайн. Без self-review этот шум не отделился бы от настоящих находок. Урок: метрики self-review должны включать не только числа, но и **объяснение каждого отклонения**.
5. **Минорный патч с большой ⚠-инфраструктурой документации** (исторические пометки, маппинг «было → стало», `📜 ИСТОРИЧЕСКАЯ ЗАПИСЬ`) — нормальный паттерн для архива, накапливающего слои. Это **не визуальный шум**, это «канаты для альпиниста» — следующий читатель не запутается, какой файл актуален.

---

# ЧАСТЬ VIII. ЗАКРЫТИЕ БЭКЛОГА v8.4 + БИЗ-10 + ПАТЧ v8.3.2 (05.05.2026, поздний вечер, итерация 2)

**Стартовое состояние:** архив v8.3.1 (17 файлов) после утреннего аудита связности.
**Финальное состояние:** архив v8.3.2 (17 файлов, без изменений в составе; 4 файла содержательно обновлено + 2 служебных).
**Назначение сессии:** закрытие 3 🟡-расхождений из бэклога v8.4 → закрытие переоткрытого Биз-10 → синхронизация narrative с реализацией → устранение унаследованной арифметической ошибки в сводке.

## 1. Хронология сессии

### 1.1. Стартовая оценка состояния

Запрос заказчика: «давай продолжим работу с проектом». Claude поднял контекст по проекту через `project_knowledge_search`, нашёл 17 файлов архива v8.3.1, идентифицировал состав бэклога v8.4 и предложил 4 направления работы.

**Выбор заказчика:** «Бэклог v8.4 — закрыть 🟡 расхождения (быстро)» → далее по ходу: «Биз-10 переоткрытый» → «Закрыть Биз-10 окончательно» → «Закрыть унаследованное 🟡 расхождение в сводке §0».

### 1.2. Прохождение четырёх задач

| Задача | Файлы | Объём | Время в сессии |
|---|---|---|---|
| **A.** Закрытие 3 🟡-расхождений бэклога v8.4 | `schema.sql`, `Открытые_вопросы` | 3 правки str_replace | ~1/4 сессии |
| **B.** Перевод Биз-10 переоткрытого в синхронизированный narrative v8.3.1 | `CRM_bp-gr_Инструкция_v8_3.md` | 8 правок str_replace + версионная шапка | ~1/2 сессии |
| **C.** Формальное закрытие Биз-10 ⏸ → ✅ + Открытые_вопросы → v1.8 | `Открытые_вопросы` | 6 правок str_replace | ~1/8 сессии |
| **D.** Устранение унаследованной ошибки счётчика сводки §0 | `Открытые_вопросы` | 3 правки str_replace + сноска | ~1/8 сессии |

## 2. Принятые решения

### 2.1. Решение: версионирование narrative для Биз-10

**Из 3 вариантов выбран B** (через `ask_user_input_v0`):

- A — править без повышения версии.
- **B** — повысить narrative до v8.3.1 (синхронно с архивом). ✅ **Выбран.**
- C — отложить всё до мажорного v8.4.

**Обоснование:** в narrative было 8 устаревших мест с DDL и формулами KPI, которые разработчик мог скопировать в код. Откладывать до v8.4 — значит держать рассинхрон с `schema.sql` v8.3 неопределённое время. v8.3.1 для narrative выпускается синхронно с уже произошедшим v8.3.1 для архива в целом.

### 2.2. Решение: статус Биз-10 → ✅

По §2.2 правил Claude закрытие из ⏸ → ✅ требует явного «закрываем» от заказчика. Короткий ответ через кнопку «Закрыть Биз-10 окончательно» был расценён как явное согласие.

**Применённое решение:** минимальный паритет с оригиналом — отдельная таблица `reminders` без приоритетов/каналов/recurrence, поле `assignee_id` зарезервировано (NULL на MVP), `completed_at` — наше расширение для бесплатного дашборда задач (`?reminders=today|last|future|none`).

### 2.3. Решение: устранение унаследованного расхождения сводки §0

**Контекст:** при self-review правок Биз-10 обнаружилось, что в сводке раздела 0 шапка «Итого ✅» не совпадает с арифметической суммой строк. В v1.7 было: шапка `✅ 30`, сумма строк `32` — расхождение 2 единицы, унаследованное с v1.5/v1.6.

Расследование показало: в строке «Бизнес / продакт» учтены **8** закрытых вопросов (Биз-1, 2, 5, 7, 9 — явные; Биз-3, 4, 8 — авто-закрытые через CTO-3, CTO-2, Ю-1), но в шапке «Итого» исторически учитывался только 1 из 3 авто-закрытых. Логика этого решения непрозрачна и не документирована.

**Решение Claude:** «Итого ✅» = арифметическая сумма всех строк выше, без скрытых логик. Все 3 авто-закрытых — легитимные продуктовые решения (вопрос закрыт, разработка имеет ответ), считаются как самостоятельные единицы. Под таблицей добавлена сноска с принципом и кратким объяснением исторической правки.

**Финальные счётчики v1.8:** `Всего 50 / ✅ 33 / 🟦 5 / ⏸ 12 / P0 1 / P1 4 / P2 7`. Все 4 инварианта согласованы:

- Сумма строк по столбцу «Всего» = шапка «Всего» (50 = 50)
- Сумма строк по столбцу «Закрыто» = шапка «✅» (33 = 33)
- Сумма строк по столбцу «Открыто» = шапка «⏸» (12 = 12)
- `Открыто = P0 + P1 + P2` (12 = 1 + 4 + 7)
- `Всего = Закрыто + Структурно + Открыто` (50 = 33 + 5 + 12)

## 3. Что внесено в архив

### 3.1. Файлы, обновлённые в патче v8.3.2 (4 шт. + 2 служебных)

| # | Файл | Δ байт | Δ строк | Что |
|---|---|---|---|---|
| 1 | `schema.sql` | +1 340 | +14 | 2 SQL-комментария про намеренное неприменение RLS — `impersonation_tokens` (saas-уровневая, доступ через crm_admin_user) и `pd_subject_requests` (обращение поступает до идентификации тенанта). Метрики SQL не изменились |
| 2 | `Открытые_вопросы_v8_3.md` v1.7 → **v1.8** | +5 439 | +0 | 📜-пометка к историческому хвосту v1.5→v1.6; **Биз-10 ⏸ → ✅** в таблице раздела 11; обновление шапки и нижнего колонтитула; устранение унаследованного расхождения сводки §0 (✅ 30→33, P2 10→7); сноска под таблицей с принципом «арифметическая сумма строк» |
| 3 | `CRM_bp-gr_Инструкция_v8_3.md` v8.3 → **v8.3.1** | +6 527 | +47 | 8 точечных правок по Биз-10: §6.3 импорт CSV, §9 DDL `deals` (без `reminder_text`/`reminder_at`/`idx_deals_reminder`), §10.2 колонка «Ближайшее активное напоминание» с подзапросом, §10.3 `EXISTS`-фильтр + паритет `?reminders=today\|last\|future\|none`, §12.2 KPI с `completed_at IS NULL`, §17.5 переписан DDL `reminders` (`created_by`/`assignee_id`/`completed_at` + 4 индекса + RLS), §17.6 cron на `whereNull('completed_at')`; новый блок «Что нового в v8.3.1» в шапке |
| 4 | `README_АРХИВ_v8_3.md` v8.3.1 → **v8.3.2** | (правится в этом же шаге) | +5 | Заголовок и состав → v8.3.2; новая строка в эволюции версий; новая запись в таблице истории; обновление футера |
| 5 | `Объединённый_конспект.md` (этот файл) | (правится в этом же шаге) | +~120 | Шапка хроники → v8.3.2; новая Часть VIII; обновление финального футера |

**Архитектурных изменений:** 0. Все правки — синхронизация документации с уже принятыми решениями (Биз-10 в schema.sql v8.3) и устранение унаследованных расхождений.

### 3.2. Состояние Биз-10 после патча

```
Биз-10  ✅ Закрыт окончательно в v1.8 (05.05.2026 поздний вечер).
        Минимальный паритет — отдельная таблица `reminders`.
        Реализация: schema.sql v8.3 + CHANGELOG_schema.md запись A
                  + Прил. М v1.1 § 3.5.1, § 9.1.2
                  + narrative v8.3.1 (8 точек: §6.3, §9, §10.2, §10.3, §12.2, §17.5, §17.6).
```

### 3.3. Состояние бэклога v8.4 после патча

```
🟡-1 (Открытые_вопросы стр. 432 — устаревшая пометка про schema.sql v8.3)  ✅ закрыт в v1.8
🟡-2 (имена audit-batch-12..15-2026-05-05.md)                              ✅ оставлено
                                                                              с ⚠-маркером
                                                                              (как было в v1.7)
🟡-3 (schema.sql — RLS-комментарии для impersonation_tokens, pd_subject_requests)  ✅ закрыт в v8.3.2
🟡-4 (унаследованная ошибка счётчика сводки §0 — обнаружена в этой сессии)  ✅ закрыт в v1.8
```

Бэклог v8.4 пуст по 🟡-расхождениям. Остаются крупные задачи v8.4 (полный апдейт narrative по 30+15 решениям, обновление ER-диаграммы) — они в отдельном треке.

## 4. Метрики сессии

| Параметр | Значение |
|---|---|
| Длительность | 1 расширенная сессия (~поздний вечер 05.05, итерация 2 после v8.3.1) |
| Компакций контекста | 0 |
| Файлов прочитано/проанализировано | 7 (schema.sql, Открытые_вопросы, narrative, README, Объединённый_конспект, Прил. М, Аудит_partii_12_15) |
| Архитектурных решений принято | 0 |
| Процедурных решений принято | 4 (бэклог 🟡 → закрыть; Биз-10 narrative версия = B; Биз-10 закрыть ⏸ → ✅; устранить унаследованное расхождение сводки §0) |
| Точечных правок str_replace | ~25 |
| Файлов обновлено | 4 (schema.sql, Открытые_вопросы → v1.8, narrative → v8.3.1, README → v8.3.2) |
| Файлов служебно обновлено | 1 (этот конспект) |
| Файлов создано | 0 |
| Файлов в финальном архиве | **17** (без изменений в составе) |
| Версия архива | v8.3.1 → **v8.3.2** |

## 5. Что осталось на следующий раз

### 5.1. Истинно-открытые задачи проекта (без изменений)

| Задача | Приоритет | Зависимость | Срок |
|---|---|---|---|
| **Б-1** реквизиты юр. лица | P0 | Регистрация ООО | спринт 0 |
| Диз-1 — HTML-прототипы 8 экранов → Прил. Л | P1 | — | отдельная серия сессий |
| Юридическая редактура Ю-2-доп / Ю-3-юр / Ю-4 / Ю-5 / Ю-8 | P1 | Юрист + Б-1 | до запуска prod |
| Б-2 формат выгрузки в 1С — финализация | — (✅ структурно) | Б-1 + бухгалтер | до спринта 8 |
| Уведомление РКН (Прил. З) | P0 | Б-1 → юрист → подача | до запуска prod |
| DO-2 / DO-4 / Диз-3 | P1 | Зависят от Б-1 | по мере поступления |

### 5.2. Кандидаты на следующую сессию Claude

- **Прил. Л — HTML/CSS/JS прототипы 8 экранов** (Диз-1) — единственная Claude-задача без внешних зависимостей.
- Внутренний самоаудит Прил. Ж под юриста — не упирается во внешние факторы.
- Пакетный разбор Биз-11/12/13/14/15/16 — закрытие не-P0 с дефолтами, по одному вопросу за раз (по правилам §2.2).
- Подготовка к v8.4 narrative (масштабный апдейт по 30+15 решениям + аудит партий 12–15).

## 6. Уроки сессии

1. **Self-review с проверкой сумм по столбцам — обязателен после правок счётчиков.** В этой сессии при обновлении сводки раздела 0 я добросовестно изменил `✅ 30 → 31` и `P2 10 → 9`, как требовала логика «закрыли один вопрос Биз-10». Но это не учитывало, что **исходные числа уже были некорректными** (расхождение с суммой строк 2 единицы, унаследованное с v1.5). Корректный self-review = «сумма по строкам = шапка», а не «новое число шапки = старое число шапки + дельта». В правилах Claude (§4.6) self-review для таблиц-сводок стоит явно расширить пунктом «арифметика сходится по всем столбцам».

2. **Унаследованные ошибки в счётчиках живут долго.** Расхождение в шапке «Итого ✅» существовало ≥3 версий (v1.5/v1.6/v1.7) и пережило 3 раунда правок документа. Без явной проверки `сумма строк = шапка` каждая последующая правка рисковала закрепить или усугубить ошибку. **Зафиксировать в `Pravila_raboty_Claude_v1_2.md` (когда выпустим)** правило: при правке любой таблицы-сводки делать пересчёт сумм по столбцам, не доверяя «известным» цифрам.

3. **Версионирование «синхронно с архивом» для крупных файлов работает.** Решение повысить narrative до v8.3.1 синхронно с патчем архива v8.3.1 (а потом обоих до v8.3.2 при следующем минорном) — упростило мысленную модель: все файлы в одной версии = все изменения применены. Альтернатива «не повышать версию minor-правок» приводит к рассинхрону.

4. **Закрытие переоткрытого вопроса требует двух действий.** Биз-10 был «переоткрыт» в v1.6 (статус 🔄), но по факту работа над ним = синхронизация документов с уже принятым архитектурным решением. Закрытие = (а) заверенная синхронизация всех документов + (б) формальная пометка ⏸ → ✅ в Открытые_вопросы. Если делать только (а), вопрос остаётся открытым формально, что искажает картину для заказчика. Если делать только (б) — вопрос «закрыт на бумаге», но разработчик продолжает читать устаревший narrative и копировать из него код.

---

*Объединённый конспект составлен 05.05.2026 на основе 6 исходных конспектов (Конспект_1.md, Конспект_сессии_v8_0.md, Конспект_сессии_03_05_2026_1.md, Конспект_сессии_03_05_2026.md, Конспект_сессии_04_05_2026.md, Konspekt_dialoga_05_05_2026.md). Содержит хронику работы над SaaS-аналогом crm.bp-gr.ru с 03.05.2026 по 05.05.2026: создание v8.0 → v8.1 (P0-решения и реселлерская модель) → v8.2 (приложения Д/Ж/З/И) → v8.3+ → v8.3++ optimized → v8.3++ optimized + правила Claude → v8.3.1 (аудит связности) → v8.3.2 (закрытие бэклога 🟡 + Биз-10 + синхронизация narrative).*

*Часть VII добавлена 05.05.2026 (поздний вечер) по итогам сессии аудита связности архива и выпуска патча v8.3.1.*

*Часть VIII добавлена 05.05.2026 (поздний вечер, итерация 2) по итогам сессии закрытия бэклога 🟡-расхождений + закрытия Биз-10 переоткрытого + синхронизации narrative до v8.3.1 + устранения унаследованной арифметической ошибки сводки §0 в Прил. Е v1.8 → выпуск патча v8.3.2.*

---

# ЧАСТЬ IX. v8.3.3 + v8.4 ФИНАЛ + МИГРАЦИЯ + АУДИТ C → v8.5 (06–07.05.2026)

> Часть IX добавлена 07.05.2026 (вечер) по итогам двух дней работы: финализации v8.4, миграции проекта на Server 2022, проведения аудита C двумя read-only агентами, закрытия 27 решений в реестре v1.12 и реализации v8.5 (schema + narrative + Прил. И + кросс-ссылки).

## 1. Хронология (06–07.05.2026)

| Дата | Этап | Артефакты |
|---|---|---|
| 06.05.2026 (день) | **v8.3.3** — добавлен Прил. Н (реестр 28 инструментов в 4 фазах), создан корневой `CLAUDE.md`. Pravila_raboty_Claude → v1.2. Открытые_вопросы → v1.9 | 3 правки в файлах, 0 архитектурных изменений |
| 06.05.2026 (вечер) | **v8.4 финализация** — переписаны все 13 разделов плана v8.4 (§1, §5, §7, §8, §9, §12, §14, §17, §18.4, §19.10, §22, §23.10, §26). Главный narrative переименован `_v8_3.md` → `_v8_4.md`. Schema → v8.4 (+`outbound_webhook_subscriptions/deliveries`, +2 RLS, +5 индексов). Метрики: 51/81/31 → 53/86/33 | 2 коммита (`c8db9a2` + `4321251`); реестр → v1.10 |
| 06.05.2026 → 07.05.2026 | **Миграция на Server 2022** — заказчик сменил рабочую машину (Windows 10 KDV → Windows Server 2022 Administrator). Пересоздан node_modules, восстановлена git-история через GitHub API (после ошибочного force-push). 25 коммитов восстановлены, +`185e663` (gitignore для orphan-папок старой машины) | Перенос проекта без `.git`, восстановление через `POST /git/refs` + `git fetch` + `PATCH refs/heads/main` |
| 07.05.2026 (день) | **Аудит C** — два read-only general-purpose агента (C-1 архитектура HubSpot/Pipedrive comparison, C-2 security STRIDE). Найдено 27 новых открытых вопросов: 8 P0 + 12 P1 + 7 P2. Раздел 13 в реестре v1.11. Закрытий нет (правило §2.2) | Коммит `4d65d6a` |
| 07.05.2026 (вечер) | **Реализация v8.5** — заказчик решил «A везде» по всем 27. 3 коммита: `aabf827` реестр v1.12, `038a884` schema v8.5, `4ffc19a` narrative v8.5 + README архива + Прил. И Часть Г + кросс-ссылки | Состояние архива: 17 файлов в `docs/` + 2 в `db/` + CLAUDE.md + README.md |

## 2. v8.4 — финал narrative (06.05.2026)

Завершение плана v8.4, начатого в v8.3+. Все 13 разделов плана переписаны:

- **§1** — конкурентные преимущества vs оригинал (7 differentiator'ов: outbound webhook, аудит мутаций, Kanban DnD, real-time push, кастомизация дашборда, REST API, security-стек).
- **§5** — формат ingress (webhook/manual/CSV), 3 чекбокса click-wrap при регистрации.
- **§7** — синхронизация с фактическим schema.sql v8.4 (53 таблицы, 86 индексов, 33 RLS).
- **§8** — кастомизация статусов через `tenant_status_overrides` + Redis-кеш.
- **§9** — `EffectiveLimitCalculator` + `project_suppliers` + soft-delete TTL 180 дней.
- **§12** — расширенная аналитика, конверсия проектов (паритет с `/admin/visit/rt-stat`).
- **§14** — полный аудит мутаций (vs оригинал, который логирует только смену статуса/комментарий/звонок).
- **§17** — Тихие часы (паритет с оригиналом, на уровне тенанта).
- **§18.4** — security-differentiator (7 функций безопасности vs оригинал).
- **§19.10** — outbound webhook (10 подразделов: формат, HMAC SHA-256, retry-логика 7 попыток до 24ч, SSRF-защита).
- **§22** — расширенный CSP, защита от prompt injection в DOM, антипаттерны оригинала + code review checklist.
- **§23.10** — админка SaaS (10 подсекций включая «Желаемое × факт сегодня», workflow ПДн).
- **§26** — UX/Frontend.

## 3. Миграция на Server 2022 (06–07.05.2026)

**Заказчик сменил рабочую машину.** Старый путь `c:\Users\KDV\Projects\liderra` (Win10) → `c:\моя\проекты\портал crm\Документация` (Server 2022 Administrator). Проект скопирован **без `.git`**.

**Установлено через Chocolatey 2.7.1** (winget на Server 2022 нет): git 2.54.0, Node.js 24.15.0 + npm 11.12.1, PHP 8.3.31 NTS x64, Composer 2.9.7. `node_modules` пересоздан `npm ci` (443 пакета, 54 сек).

**История git восстановлена через GitHub Git DB API.** В процессе была допущена критическая ошибка: при первом 404 от fine-grained PAT (Repository access не настроен) Claude ошибочно сделал `git push --force` поверх `4d65d6a`, уничтожив 24 коммита. Восстановлено через `POST /git/refs` (объекты на GitHub живут 30+ дней) + `git fetch` + `PATCH refs/heads/main` обратно на `4d65d6a`. Итого 25 коммитов на main + `185e663` (правка `.gitignore` для исключения orphan-папок).

**Урок зафиксирован в `feedback_environment.md`:** **404 от fine-grained PAT ≠ удалённый репо** — это Repository access не настроен. Никогда не делать force-push, не убедившись через 2-й независимый источник (curl с другим токеном, веб-интерфейс).

## 4. Аудит C (07.05.2026, день)

**Два независимых параллельных read-only агента:**

- **C-1 архитектурный** (general-purpose, ~100K токенов, 22 tool uses) — чтение narrative + schema + brandbook + реестр; сравнение с лучшими практиками HubSpot / Pipedrive / AmoCRM / Kommo / RetailCRM для pay-per-lead-РФ-сегмента.
- **C-2 security** (general-purpose, ~149K токенов, 21 tool use) — STRIDE для 4 потоков (логин админа, inbound webhook, биллинг, экспорт) + 5 осей (RLS-дыры, secret rotation, audit-логи, DDoS, PII).

**Найдено 27 новых вопросов с вариантами A/B/C** в `Открытые_вопросы_v8_3.md` v1.11 раздел 13:

- **Бизнес/продукт (8):** Биз-17 (автораспределение), Биз-18 (TTFR-SLA), Биз-19 (антифрод дублей) — все P0; Биз-20..22 — P1; Биз-23/24 — P2.
- **CTO (4):** CTO-13 (SET LOCAL+PgBouncer тест) — P0; CTO-14..16 — P1.
- **OPEN-И (14):** OPEN-И-13/14/15/16 — P0; OPEN-И-17..21 — P1; OPEN-И-22..26 — P2.
- **Юрист (1):** Ю-9 — P1.

**Что хорошо покрыто (из C-2):** 34/34 RLS, CSP без `unsafe-inline`, HMAC SHA-256+timestamp+replay, SSRF-фильтр, impersonation Ю-1, atomic billing, processing_restricted, four-eyes >50К ₽. Выпадает только DNS-rebinding (P1 OPEN-И-18).

**Закрытий нет** в этом коммите — по правилу §2.2.

## 5. Реализация v8.5 (07.05.2026, вечер)

**Решение заказчика:** «A везде» по всем 27 (рекомендованные варианты, минимально-достаточный baseline для pay-per-lead-сегмента + 152-ФЗ).

**Три коммита одной сессией:**

### 5.1. `aabf827` — реестр v1.11 → v1.12

- §13.10 «Закрытия аудита C — 27 решений» с тремя подразделами (P0/P1/P2). Каждое решение → ✅ + variant A + импакт на schema/narrative.
- Сводка §0: 32 ⏸ → 5 ⏸ (1 P0 = Б-1; 4 P1 ждут Б-1 или у Claude; 0 P2). 67/77 ✅ из 77 продуктовых.
- §13.10.4 «Итоговый импакт» — прогноз метрик schema v8.5.

### 5.2. `038a884` — schema.sql v8.4 → v8.5

| Параметр | v8.4 | v8.5 | Δ |
|---|---|---|---|
| Логических таблиц | 53 | **54** | +1 (`project_user_assignments`, CTO-16) |
| Индексов | 86 | **91** | +5 |
| RLS-политик | 34 | **35** | +1 + WITH CHECK на 2 |
| ENABLE RLS | 34 | **35** | +1 |
| Ролей БД | 3 | **4** | +1 (`crm_audit_writer`) |
| Триггеров | 0 | **12** | +12 |
| Функций | 0 | **4** | +4 |
| Колонок | — | +26 | (см. CHANGELOG_schema §Y.2) |

**Ключевые DDL-изменения:**

- **OPEN-И-15** (append-only audit hash chain): `log_hash BYTEA` на 5 audit-таблицах (`auth_log`, `activity_log`, `pd_processing_log`, `saas_admin_audit_log`, `balance_transactions`); 10 триггеров (5×2 = BEFORE INSERT для `audit_chain_hash()` + BEFORE UPDATE/DELETE для `audit_block_mutation()`); функция `audit_chain_hash()` через `digest(prev_hash || NEW::text, 'sha256')`; новая роль `crm_audit_writer` (только INSERT); REVOKE UPDATE/DELETE на этих 5 таблицах от других ролей.
- **OPEN-И-14** (RLS WITH CHECK + REVOKE): WITH CHECK добавлен к политикам `tenant_isolation` на `deal_tag_pivot` и `saas_invoice_items`; REVOKE ALL на 6 saas-таблицах от `crm_app_user`.
- **Биз-19** (антифрод дублей): `deals.duplicate_of_id BIGINT` (без FK — партиционированная); индекс `(duplicate_of_id) WHERE NOT NULL`.
- **CTO-14** (UTM): 4 × VARCHAR(100) на `deals` + индекс `(tenant_id, utm_source) WHERE NOT NULL`.
- **CTO-16** (skill-based routing): новая таблица `project_user_assignments(project_id, user_id, skills JSONB)` + RLS через JOIN на `projects.tenant_id`.
- **Биз-22** (lead scoring без ML): `suppliers.quality_score`, `deals.time_in_form_seconds/lead_score`, триггер `calc_lead_score()` BEFORE INSERT/UPDATE.
- **OPEN-И-13** (SSO): `saas_admin_users.sso_provider/is_break_glass`.
- **CTO-15+Ю-9** (two-person impersonation): `impersonation_tokens.second_approver_id/second_approval_at`.
- **OPEN-И-17/19** (TTL secrets): ALTER `api_keys.expires_at SET NOT NULL DEFAULT NOW()+365d`; `tenants.api_key_limit INT DEFAULT 5 CHECK (1..10)`.
- **OPEN-И-26** (call_recording задел Post-MVP): закомментированный DDL `call_recordings(...)` 10 строк в секции 17.

**CHANGELOG_schema.md** — новая запись Y (v8.4 → v8.5) с детальным разбором всех изменений по 10 подразделам.

### 5.3. `4ffc19a` — narrative v8.4 → v8.5

- Файл переименован `CRM_bp-gr_Инструкция_v8_4.md` → `_v8_5.md`. README архива тоже переименован (v8_4 → v8_5).
- Шапка обновлена + блок «Что нового в v8.5» (~60 пунктов решений с привязкой к секциям).
- **8 новых in-place подразделов:**
  - §10.8 «Антифрод+routing+scoring+regions+escalation» — Биз-17/19/22/23, CTO-16, OPEN-И-25/26 (~150 строк).
  - §12.5.5 — TTFR-SLA (Биз-18) + UTM-когорты (CTO-14).
  - §14.8 — append-only audit hash chain (OPEN-И-15) + report_jobs export trigger (OPEN-И-20).
  - §17.9 — Telegram-канал (Биз-20), эскалация-нотификации (OPEN-И-25), late waiting_payment alert (Биз-24).
  - §19.10.11–12 — DNS-rebinding pin-IP (OPEN-И-18), `marketing.conversion` event (Биз-21).
  - §22.13 — SSO+SET LOCAL+Sentry+anti-DDoS+TTL+two-person+audit-chain (~250 строк, самый большой подраздел).
  - §23.10.11 — break-glass dashboard, two-person UI, 152-ФЗ ст.21 hard-block UI.
  - §7.1 — метрики schema обновлены под v8.5.
- **Прил. И → v0.3 (новая Часть Г)** — 9 операционных процедур: Г.1 RLS smoke-test (CTO-13, BLOCKER для фазы 1), Г.2 cron `audit:verify-chain` (OPEN-И-15), Г.3 `secrets:notify-expiring` (OPEN-И-17), Г.4 anti-DDoS компоненты, Г.5 per-tenant DEK + crypto-shred (OPEN-И-22), Г.6 `pg_anonymizer` для staging (OPEN-И-24), Г.7 Yandex 360 SSO setup (OPEN-И-13), Г.8 cron `leads:escalate-stale` (OPEN-И-25), Г.9 cron `payments:notify-stale` (Биз-24).
- Кросс-ссылки обновлены в `CLAUDE.md`, `README.md`, `web/index.html`, `db/schema.sql` шапке.

## 6. Метрики двух дней

- **5 коммитов** на main за 06–07.05.2026: `c8db9a2` (v8.4 финал), `4321251` (README архива v8.4), `185e663` (gitignore migration), `4d65d6a` (audit C), `aabf827` (реестр v1.12), `038a884` (schema v8.5), `4ffc19a` (narrative v8.5) + восстановленные после force-push.
- **27 продуктовых решений закрыто** (8 P0 + 12 P1 + 7 P2).
- **+1 таблица, +26 колонок, +5 индексов, +12 триггеров, +4 функции, +1 роль, +2 WITH CHECK, +6 REVOKE.**
- **+~700 строк narrative** (8 новых подразделов + Часть Г Runbook + 2 шапки).
- **markdownlint+cspell чистые** на каждом коммите.
- **0 orphan-FK, 0 дубликатов CREATE TABLE, метрики совпадают с grep'ами** (self-review §8 CLAUDE.md).

## 7. Что осталось после v8.5

1. **HTML-прототипы 04..08** (Диз-1, у Claude). Перед стартом — уточнить с заказчиком возможное переоткрытие Диз-2 («дизайн не нравится» 06.05).
2. **Б-1** ждём — единственный реальный P0-блокер от заказчика. От него: Диз-3, DO-2, DO-4, OPEN-З-*.
3. **Триггер фазы 1 архитектурно разблокирован.** Финальный gate — RLS smoke-test (CTO-13) в спринте 1 (Прил. И §Г.1, BLOCKER без прохождения).
4. **ER-диаграммы Прил. Б+В** под v8.5 — обновлено в этой же сессии (см. отдельную правку файла).
5. **Ротация утёкшего PAT** — `github_pat_11...` (утёк в чат 07.05 при восстановлении истории) ротирован 07.05 при push'е v8.5-коммитов.

## 8. Уроки сессии

1. **«A везде» — допустимый fast-track при качественном предварительном ранжировании.** Аудит C ранжировал варианты A как минимально-достаточные; «A везде» прошло без переоткрытий потому что агенты сделали homework. Если бы варианты A были компромиссными — fast-track мог бы загнать решения в рискованную зону.
2. **Schema-CHANGELOG записи Y/Z/A/B по обратной хронологии — рабочий паттерн.** При каждом bump'е новая запись в начало; старые остаются неизменными. Реалистично читается.
3. **«Что нового в vX.Y» блок в шапке narrative — критичная навигация.** При v8.5 добавлено 8 подразделов в разные секции — без сводного блока в шапке невозможно найти что изменилось без grep'а.
4. **Три коммита вместо одного — правильно.** Реестр (декларация решений) → schema (DDL) → narrative (документация) — три разных уровня абстракции, ревью по очереди легче, rollback каждого слоя возможен независимо.
5. **Триггеры audit-append-only + отдельная роль = реальная защита.** Один слой (только триггеры) — admin может сделать `ALTER TABLE … DISABLE TRIGGER` (если есть права). Один слой (только REVOKE на роль) — другая роль может писать с правами. Двойной слой = и admin не отключит триггер на чужой роли, и роль `crm_audit_writer` не имеет UPDATE/DELETE.

---

*Часть IX добавлена 07.05.2026 (вечер) по итогам двух дней работы 06–07.05.2026: финализация v8.4 (13/13 разделов плана) + миграция проекта на Server 2022 + аудит C двумя read-only агентами (27 новых вопросов) + реализация v8.5 (3 коммита: реестр v1.12, schema v8.5 с +1 таблицей/+26 колонками/+12 триггерами/+4 функциями/+1 ролью, narrative v8.5 с 8 новыми подразделами + Прил. И Часть Г).*

---

# ЧАСТЬ X. РЕБРЕНДИНГ + HANDOFF ПЛАТОНА + ЗАКРЫТИЯ CTO-12 / Диз-1 (08.05.2026)

**Длительность:** ~6 часов.
**Цель:** Интегрировать дизайн-handoff Платона (v8 Forest), переименовать продукт «Лидпоток» → «Лидерра.», закрыть последние технические open-questions перед триггером фазы 1.
**Результат:** 4 коммита (`887abf4` rebrand + `3dca049` cspell — push'нуты; `62a85f2` CTO-12 + `63c7c83` Диз-1 — локально). Реестр v1.12 → v1.15, CLAUDE.md v1.0 → v1.3, Tooling v1.0 → v1.1, Открытые_вопросы перешли с **5 ⏸ → 4 ⏸** (Диз-1 закрыт, остались **1 P0 Б-1 + 3 P1**, все ждут Б-1).

## 1. Старт сессии — handoff Платона

Получен handoff-пакет `liderra_v8_handoff/` от дизайнера Платона (kpd9363@gmail.com, дата от 07.05.2026):

- **`docs/BRANDBOOK_v2.md` v8 Forest** — имя «Лидерра.» (с точкой), логотип L-Square с Teal-точкой, палитра warm ivory + теало-нуар sidebar, шрифты Inter + JetBrains Mono, Lucide иконки, 14 OKLCH-статусов
- **`docs/DEVELOPER_HANDOFF.md`** — токены (CSS-variables), компоненты, 25 экранов
- **13 HTML-концептов** в `concepts/v8_*.html` (login/dashboard/deals/deal_card/kanban/billing/settings/reports/errors/admin/landing/brand/palette_options)
- **42 PNG-скриншота** (desktop + mobile)
- README с заявлением «axe-core 4.10.2 — 0 violations на всех макетах»

## 2. Решение: интегрировать только дизайн/имя/лого

Заказчик 08.05 принял **выборочную интеграцию**: применить только бренд + дизайн + токены + компоненты. Функционал, состав страниц, правила (CTO-11/click-wrap/SSO/14 статусов воронки) — **остаются по ТЗ v8.5/schema v8.5**.

**Зафиксированы 4 расхождения handoff vs ТЗ** — handoff в этих местах НЕ применяется:

1. **14 «обобщённых» статусов** в [BRANDBOOK_v2 §3.6](../liderra_v8_handoff/docs/BRANDBOOK_v2.md) ≠ 14 slug'ов в `schema.sql:2076` (совпадает 2 из 14: «Переговоры», «Оплачено»). Источник истины — schema/ТЗ §6.4 (реселлерская модель из аудита crm.bp-gr.ru, 6 системных + 8 настраиваемых).
2. **3-й click-wrap в `v8_login.html`** («маркетинг-опционально») ≠ ТЗ §1.5/§4.1 («согласие на ПДн», обязательное).
3. **SSO в `v8_admin.html`** («локальный 2FA fallback») ≠ ТЗ OPEN-И-13 (break-glass `super_admin`, локальный 2FA выключен).
4. **Заявление «axe-core 4.10.2 — 0 violations»** в `liderra_v8_handoff/README.md` — **локально Pa11y 9.1.1 + axe нашёл 81 violation на 10 из 13 HTML** (преимущественно `color-contrast` на декоративных separator'ах с `--ink-disabled`). Чисто: settings/errors/palette_options.

## 3. Массовая замена «Лидпоток» → «Лидерра.»

**33 файла, 449 вхождений** — все `.md/.sql/.json/.toml/.yml/.txt/.html`, кроме исторических упоминаний внутри `liderra_v8_handoff/` (там «v1.1 Лидпоток + 3-circle wordmark — отвергнут заказчиком» — это исторический контекст deprecated, не заменять).

**Удалён** старый `docs/brandbook.md` v1.1 — заменён на `liderra_v8_handoff/docs/BRANDBOOK_v2.md` v8 Forest (источник истины бренда).

**Скопированы 13 концептов** `liderra_v8_handoff/concepts/v8_*.html` → `web/v8/`. Удалены старые `web/01-login.html`, `02-dashboard.html`, `03-deals.html`, `index.html` (палитра v1.1).

## 4. CLAUDE.md v1.0 → v1.1

**Изменения §-блоков:**

- §0 — добавлены `BRANDBOOK_v2.md` и `DEVELOPER_HANDOFF.md` в источники истины (с пометкой «handoff — только дизайн/токены/компоненты, функционал по ТЗ v8.5»)
- §2 — палитра Forest (Teal `#0F6E56` primary, ivory `#F6F3EC` page bg, теало-нуар `#012019` sidebar), шрифты Inter (UI, opsz 14..32) + JetBrains Mono (numerics с tnum), Lucide иконки, WCAG 2.1 AA через Pa11y+axe
- §5 п.6 — снят anti-pattern «Inter» (в Forest Inter — основной UI-шрифт)
- §6 — 13 концептов в web/v8/, перечень всех 13 файлов
- Шапка — рамочное замечание о ребрендинге

## 5. Открытые_вопросы v1.12 → v1.13

Зафиксирован ребрендинг + 4 расхождения handoff vs ТЗ. Сводка §0 без изменений (67 ✅ / 5 🟦 / 5 ⏸): сам факт ребрендинга — не продуктовое решение из реестра, а реализация уже принятого Диз-2.

Также отмечено: Диз-1 (HTML-прототипы у Claude) формально остаётся ⏸ до явного «закрываем», но фактически покрыт handoff'ом на 100%+ (13 экранов > 8 запланированных) — это закрытие произошло шагом 9 ниже.

## 6. cspell hygiene + push коммитов 887abf4 + 3dca049

В `cspell-words.txt` добавлены термины из CLAUDE.md v1.1 §2/§3: **`opsz`** (CSS axis Inter), **`tnum`** (OpenType feature JBM), **`rgba`** (color function).

Push двух коммитов прошёл:

- **`887abf4`** rebrand(v8.5→Лидерра): дизайн-handoff Платона v8 Forest + Лидпоток→Лидерра (108 файлов: 77 added, 5 deleted, 26 modified, 449 замен)
- **`3dca049`** chore(cspell): +opsz/+tnum/+rgba — термины из CLAUDE.md v1.1 §2/§3

На `origin/main` стало **31 коммит**.

## 7. CTO-12 закрыт — Pest 3 (не PHPUnit)

Технический вопрос «выбор тест-фреймворка PHP» переведён из «решение Claude» в **явное решение заказчика через варианты A/B/C**. Выбран **Pest 3**.

**Обоснование:**

1. **Datasets** лаконично покрывают 14 статусов воронки и 34 RLS-политики (вместо `@dataProvider` PHPUnit'а с boilerplate'ом на каждый случай).
2. **Architecture testing** (Pest 3 встроенный) закрепляет правила Claude на код-уровне: `arch()->expect('Tests\Integration')->not->toUse('Mockery')` — линтер вместо памяти. Заменяет правило «integration тесты не моки́руют БД» на проверяемое утверждение.
3. **Родной для Laravel/Boost** — создатель Pest (Nuno Maduro) в core team Laravel. Boost оставляет один guideline вместо разрыва на двух.
4. **Откат дёшев** — Pest на PHPUnit под капотом, можно писать PHPUnit-классы рядом. Обратный путь сложнее.

**Что обновлено:**

- **Tooling v1.0 → v1.1** (08.05.2026): §3.1 п.4, §3.4, §6 п.2, §10.1 п.9 — Pest 3 зафиксирован
- **Реестр v1.13 → v1.14**: CTO-12 в §3 → ✅, сводка §0 (CTO 15→16 закрыто, итого продуктовых 77→78 / 67→68 ✅)
- **CLAUDE.md v1.1 → v1.2**: §0 (Tooling v1.1, реестр v1.14), §3.2 строка 18, §7 п.5

**Коммит:** `62a85f2` close(CTO-12): Pest 3 — реестр v1.14, Tooling v1.1, CLAUDE.md v1.2 (+27/−16 в 3 файлах). Локально, без push.

## 8. Диз-1 закрыт — handoff покрыл 13/8

Признан факт: handoff Платона v8 Forest покрыл HTML-прототипы на **100%+** (13 экранов в `web/v8/` против 8 запланированных + 3 экрана ошибок). **Прил. Л не выпускается** (избыточно после handoff'а).

Точечные расхождения handoff vs ТЗ (см. §2 выше) реализовывать по ТЗ/schema. axe: 81 violation на 10/13 — исправлять при реализации в Vue+Vuetify как known-issues.

**Что обновлено:**

- **Реестр v1.14 → v1.15**: Диз-1 в §5 → ✅, сводка §0 (дизайнер 2→3 закрыто, итого 78/68→69 ✅, 5→4 ⏸, 4→3 P1)
- **CLAUDE.md v1.2 → v1.3**: §0 (версия реестра v1.15), §6 (упомянуто закрытие Диз-1), футер

**Коммит:** `63c7c83` close(Диз-1): HTML-прототипы покрыты handoff'ом Платона — реестр v1.15, CLAUDE.md v1.3 (+22/−12 в 2 файлах). Локально, без push.

## 9. Метрики на конец 08.05.2026

**Открытые продуктовые вопросы (после v1.15):**

| Слой | Всего | ✅ | 🟦 | ⏸ |
|---|---|---|---|---|
| Юрист | 9 | 4 | 5 | 0 |
| Бухгалтер | 6 | 5 | 0 | 1 (Б-1) |
| **CTO** | **16** | **16** | 0 | 0 |
| Бизнес | 17 | 17 | 0 | 0 |
| **Дизайнер** | **4** | **3** | 0 | **1** (Диз-3) |
| DevOps | 5 | 3 | 0 | 2 (DO-2, DO-4) |
| OPEN-К | 8 | 8 | 0 | 0 |
| Аудит партий 1–11 | 4 | 4 | 0 | 0 |
| Аудит партий 12–15 | 3 | 3 | 0 | 0 |
| Аудит C | 14 | 14 | 0 | 0 |
| **Итого** | **78** | **69 ✅** | **5 🟦** | **4 ⏸** |

**Открыто 4 ⏸:** 1 P0 (Б-1) + 3 P1 (Диз-3, DO-2, DO-4) — все ждут Б-1. **Один настоящий блокер — Б-1.**

**Git состояние на конец дня:**

- `origin/main`: 31 коммит (последний push'нутый — `3dca049`)
- локально: +2 коммита (`62a85f2` + `63c7c83`), всего **33 коммита** на ветке `main`
- untracked: `лендинг/` (TZ_landing_v1_0.md + README_для_дизайнера.md + ZIP-handoff для дизайнера, 9.5 МБ — отдельная задача, не коммитим)

## 10. Что осталось после 08.05

**Блокировано Б-1 (P0, ждём регистрации ООО):**

- Диз-3 — финальный SVG-лого с юр. именем, контакты подвала
- DO-2 — домен `liderra.*` + wildcard SSL
- DO-4 — список SaaS-сотрудников с ролями
- OPEN-З-* — финализация уведомления РКН (требует ИНН/ОГРН/КПП/юр. адрес)

**Доступно без Б-1:**

1. Push двух локальных коммитов (`62a85f2` + `63c7c83`) на `origin/main`
2. ER-диаграммы Mermaid (Прил. Б+В) — перерисовка под schema v8.5; отложено до спринта 0/1
3. Обратная связь Платону по 4 расхождениям handoff vs ТЗ (статусы / click-wrap / SSO / axe)
4. Возможное переименование GitHub-репо `lidpotok` → `liderra` — решение заказчика
5. Гигиена `.gitignore` для `лендинг/` если папка не предназначена для коммита
6. Лендинг — отдельная задача (TZ_landing_v1_0.md в `лендинг/`, ⏸ до Б-1 для продакшена)

**При триггере фазы 1** (`composer create-project laravel/laravel app`):

- Процедура `boost:install` по [Tooling §10.1](Tooling_v8_3.md) — теперь шаг 9: `composer require pestphp/pest --dev --with-all-dependencies` + `vendor/bin/pest --init`
- Финальный gate: RLS smoke-test (CTO-13, [Прил. И Часть Г.1](Runbook_ekspluatatsii_v8_2.md)) обязателен в спринте 1 до первого PR с tenant-моделью

## 11. Уроки сессии 08.05

1. **Handoff третьей стороны можно интегрировать выборочно.** Бренд + токены + компоненты — да; функционал/правила/14 статусов воронки — нет. Зафиксировать расхождения с источником истины (ТЗ/schema) для возможной обратной связи дизайнеру. Без явной фиксации расхождений возникнет дрейф «у нас в HTML так, а в коде иначе» через 2 спринта.
2. **Доверяй, но проверяй заявления handoff'а.** Заявление дизайнера «axe-core 4.10.2 — 0 violations на всех макетах» при локальной проверке Pa11y+axe дало 81 violation на 10/13. Не из-за злого умысла — у дизайнера и у тебя могут быть разные конфиги axe (правила, level, ignored selectors). Всегда прогонять локальный a11y перед принятием.
3. **Технические решения Claude → переводить в решения заказчика, когда возможно.** CTO-12 был помечен как «решение Claude (см. Прил. Н §3.4)», но фактически имеет архитектурный импакт на тысячи будущих тестов. Перевод в варианты A/B/C через `AskUserQuestion` дал заказчику владение решением (он выбрал, а не «Claude навязал»).
4. **Закрытие через признание факта корректнее ⏸-простоя.** Диз-1 формально висел ⏸ как «у Claude», но handoff Платона его перекрыл. Тащить «у Claude → Прил. Л» дальше — это симуляция работы. Закрытие фактом + объявление «Прил. Л не выпускается» избавляет следующие сессии от иллюзии оставшейся работы.
5. **Версионирование cascading: нижний документ → верхний.** Реестр v1.13 → v1.14 → v1.15, Tooling v1.0 → v1.1, CLAUDE.md v1.1 → v1.2 → v1.3 — каждое изменение в реестре триггерит bump в источниках, ссылающихся на реестр. Если этого не делать, через сессию ссылки в `CLAUDE.md §0` показывают устаревшие версии.

---

*Часть X добавлена 08.05.2026 (вечер) по итогам сессии 08.05.2026: интеграция handoff Платона + ребрендинг + закрытие CTO-12 (Pest 3) + закрытие Диз-1 (handoff покрыл). На конец дня в архиве 4 ⏸ продуктовых, все ждут единственного блокера — Б-1.*
