# Приёмка боевого liderra.ru через «телевизор-доказательство» — дизайн

**Дата:** 19.06.2026. **Статус:** дизайн согласован с владельцем в брейншторме, готов к writing-plans.
**Источники:** ранбуки [R0–R5](../runbooks/) + [R3b](../runbooks/2026-06-18-acceptance-r3b-onboarding-digest.md); [хартия](2026-06-18-acceptance-test-charter.md); [карта логики прода](2026-06-18-prod-logic-map.md).
**Кодовая фраза стены:** «роутер-наставник» (на момент дизайна стена снята).

## Цель (зачем)
Дать владельцу **уверенность**, что, взяв деньги у клиентов, портал их не подведёт — клиенты не столкнутся даже с грубыми ошибками. Не «зелёные галочки на веру», а **всё видно глазами** на реальных экранах, с доказательством из базы, и **записано** для повторной сверки.

## Проблема и JTBD (discovery-interview 19.06)
- **Проблема:** владелец не начнёт брать деньги, пока сам не УВИДИТ, что портал работает для платящего клиента и не даст грубых ошибок. Галочки/отчёты не убеждают.
- **JTBD:** «помоги прожить портал глазами клиента и понять, что внутри происходит и как мы закрываем его потребность — чтобы уверенно продавать».
- **Формат (ключевое уточнение):** не по-шаговый показ «клиент 1 → поставщик», а **КИНО** того, что делает исполнитель (внутрянка Лидерры+поставщика записывается), со **СТОП-и-ОЦЕНКОЙ на агрегат-итогах**: «7 клиентов сделали → вот итог у поставщика; что менялось и ПОЧЕМУ; как выглядит в итоге». На этих точках владелец оценивает и даёт «дальше».
- **Сигнал успеха:** владелец сам, посмотрев кино и оценив итоги по темам, говорит «беру деньги».

## Критерий успеха (что значит «не облажались»)
Все классы рисков доказаны ЧИСТЫМИ, каждый — карточкой ранбука с реальным доказательством:
1. **Деньги до копейки** — нет двойных списаний и потерянных копеек; баланс = лента = база; цена ступени верна; нехватка → полный откат.
2. **Изоляция** — никто не видит чужие данные (экран/прямая ссылка); шеринг не течёт.
3. **Лид не пропадает** — каждый оплаченный лид доходит; идемпотентность; каскад/лимит; сбой → retry → failed без потерь.
4. **Онбординг** — самозапись (капча + код на живой ящик + реквизиты по ИНН + старт 300₽).
5. **Заморозка/баланс** — мгновенная пауза+письмо; вечерний sweep заморозка/разморозка корректны.
6. **Заказ поставщику** — rt-проекты B1/B2/B3 реально появляются в `crm.bp-gr.ru`.
7. **Отчёты/импорт** — числа отчётов = база; импорт НЕ списывает деньги.
8. **Нагрузка** — держит целевой объём с запасом на текущем (поднятом) железе.

## Презентация = «ТЕЛЕВИЗОР» (кино + стоп-кадр итога, всё глазами)
Форма показа — живой визуальный плеер в браузере (не бумажные таблицы): **кино** прогона (что и как делает исполнитель, внутрянка записывается) + **стоп-кадр ИТОГА** на каждой теме для оценки. Зоны:
- **Стоп-кадр ИТОГА (главное):** агрегат по теме — «7 клиентов сделали → результат у поставщика / распределение по 7 / списания+балансы / кто заблокирован», + **ПОЧЕМУ так** (формула/правило). Не по одному клиенту, а сводно.
- **Кабинеты клиентов** c1–c7 (+c8) — **реальные скрины живых сессий**; в итоге видно, у кого появилась сделка и что изменилось (агрегатно по всем).
- **Портал поставщика** `crm.bp-gr.ru` — реальный экран; rt-проекты как итог заказа 7 клиентов.
- **Сервер** — живая загрузка (CPU/память/очередь Redis/БД).
- **Канал к поставщику** (для Слоя 2) — латентность HTTP, ярусы, повторы, сессия.
- **Деньги/база** — итоговая сверка (Σ списаний = начало−конец, тройная запись, RLS=0 для чужого).
- **Карта рисков** (8 клеток) — зеленеет по итогам тем; каждая ✅ кликабельна → перематывает **запись** на тот момент.
- **Запись (кино)** всего прогона — DVR: пауза/перемотка/LIVE; внутренние процессы Лидерры и поставщика сохранены для drill-down и пересмотра.

## Два слоя
### Слой 1 — Корректность (КИНО + стоп-оценка на итогах)
- Исполнитель делает всё живьём по ранбуку; **внутренние процессы Лидерры и поставщика записываются** (кино «что и как я делаю» + детальный лог для drill-down).
- **Единица показа — не микро-шаг, а ТЕМА с агрегат-итогом:** онбординг (7 регистраций) → заказ поставщику → шеринг+изоляция → деньги/тарифы → каскад/лимит → заморозка → отчёты/импорт.
- На каждой теме: прогон записывается как кино → затем **СТОП-кадр ИТОГА**: «7 клиентов сделали X → вот результат (у поставщика / распределение по 7 / списания+балансы / кто заблокирован)», **что менялось и ПОЧЕМУ** (формула/правило), как выглядит в итоге. Владелец оценивает → **«дальше»**.
- **Жёсткий СТОП:** расхождение в деньгах или утечка изоляции на итоге → красным, «дальше» заблокировано до разбора. На боевом не «чиним на ходу» — фиксируем «ожидали/получили/факт из базы» и зовём владельца.
- НЕ показываем «клиент 1 поменял → поставщик» по одному; показываем агрегат по всем 7 и причину.

### Слой 2 — Нагрузка (исполнитель гонит на максимум) — СЕРВЕР и КАНАЛ
- Инъекция лидов нарастающим темпом до потолка.
- Меряем **две стороны**:
  - **Сервер:** CPU/память/диск, глубина очереди Redis, длительность транзакций/локов БД, время задания по типам.
  - **Канал к поставщику:** латентность HTTP к `crm.bp-gr.ru`, ярусы (AJAX→Playwright-форма→ручная очередь), повторы/обновления сессии, троттл/коды ответов — узкое место может быть в канале, не только в сервере.
- Вывод по факту: «держит X лидов/сутки безопасно, потолок Y, узкое место Z (сервер ИЛИ канал)». H1 (синхронное письмо в транзакции доставки) устранено деплоем — измеряем НОВОЕ узкое место (единственный воркер, латентность канала и т.д.).
- Порядок: Слой 1 ПЕРЕД Слоем 2 (если деньги/изоляция сломаны — нагрузку гонять незачем).

## Запись и сверка (DVR)
- Каждый шаг пишется на диск: реальные скрины + числа из базы + журнал + вердикт.
- Плеер = видеомагнитофон: **пауза / перемотка по кадрам / ползунок / LIVE**.
- Клик по клетке риска → переход к её моменту в записи. Архив остаётся у владельца для пересмотра в любой момент.

## Провижининг и подготовка (предусловие)
- Тест-клиенты c1–c7 (+c8) заводятся **прямым SQL** (метка `TEST-`), парный скрипт удаления (R1). `imitation:seed` на проде запрещён, эндпоинта создания тенанта нет.
- Онбординг (Слой 1, шаг 1) проверяется **через реальную самозапись** на живые ящики `kdv1@bk.ru` / `stels_info@bk.ru` (код приходит только письмом; капча реальная).
- Один реальный сквозной заказ доходит до поставщика; тест-проекты чистятся **до 21:00 МСК** (иначе пойдут реальные платные лиды).
- **Сервер под прогон поднимаем** (владелец) — чтобы показывать все кабинеты живьём без экономии.

## Границы и защита
- **Не трогать** `lkomega`/tenant 2, реальные источники/домены, живую поставку. Любое касание реального бизнеса → немедленный стоп.
- Деньги в прогоне — **тест-баланс**, не реальные.
- Чтение базы — read-only (`sudo -u postgres psql -c 'SELECT…'`); мутации прода — осознанно и под контролем владельца.
- Teardown в конце (R5): поставщик → слепки → тест-тенанты по метке → Redis → проверка, что чисто.

## Что НЕ входит (YAGNI)
- Пополнение/счета (G5) — заглушка до ООО, не тестируем.
- Безопасность/атаки, юр — вне прогона (отдельные гейты).

## Открытые мелочи к плану
- Точный механизм кнопки «Дальше» (кнопка в плеере с флагом ↔ слово в чате) — решить в плане.
- Сколько кабинетов реально держать одновременно после апгрейда сервера (цель — все 7).
- Целевой объём нагрузки (ориентир 10 000 лидов/сутки) и пик.
