# Вопросы и решения для CTO **Зачем этот разговор.** CTO - первый зритель демки, и одновременно единственный, кто может принять четыре решения, без которых платформу нельзя проектировать: аутентификация, источник данных о сотрудниках, модель прав и кто делает бэкенд. Остальное мы решим сами. **Как пользоваться.** Блок 0 - это то, что мы **рассказываем**, а не спрашиваем: факты, ради которых разговор вообще имеет смысл. Блоки 1-4 - решения, нужные до демки. Блоки 5-7 можно отложить. --- ## 0. Что уже выяснено (рассказать, не спрашивать) Это результат разбора сохранённых копий отчётов, без доступа к серверу. **Нет единого списка того, что существует.** Три источника внутри самого halleg дают три разных перечня отчётов: | Источник | Сколько отчётов | |---|---:| | Реестр в навигации (`sidebar.js`) | 16 | | Блок «Прямые ссылки» | 18 | | Статистика посещений за неделю | 13 | Всего известных страниц - 19. При этом: - **`Trader Shifts`** - второй по популярности отчёт (8 415 посещений, 54 пользователя) - отсутствует и в навигации, и в прямых ссылках. Люди как-то на него заходят, но найти его через меню нельзя. - **`metrics-legend`** (справочник метрик) и **`threshold-analysis`** есть только в прямых ссылках. В навигации их нет, поэтому и посещений у них нет. - Четыре отчёта в навигации за неделю не открыл никто. **Метрики расходятся, и это доказуемо.** В страницы зашиты собственные описания метрик. Извлекли 105 определений; **13 метрик определены по-разному в разных отчётах**. Не формулировками - сутью: - `Score` в `Trader_Scoreboard` и в `Weekly_KPI` - две разные формулы с разными компонентами и весами. - `PayIn Volume` - три разных фильтра: «провайдеры с объёмом > 5 000», «все кроме операторов-провайдеров», «просто сумма за период». - `Active Accounts` - в одном отчёте `COUNT(DISTINCT)`, в другом сумма уникальных по каждому часу, то есть один счёт считается многократно. - `Deposit` - в одном отчёте зависит от выбранного периода, в другом ALL-TIME. Разбор: `local/discovery/metrics-conflicts.md`. **Нагрузка на halleg сконцентрирована в одном отчёте.** ≈ 498 000 вызовов `/api/*` в неделю, из них **401 000 (80%) даёт `Trader_Operational`** - он делает 26 запросов на каждую загрузку страницы. Пик в 2.7 раза выше среднего, порядка 2.7 агрегирующих запроса в секунду. Разбор: `local/discovery/report-weight.md`. **Вывод для разговора:** платформа - это не «сделать красивее». Это единый каталог того, что существует, единый слой определений метрик и точка, где чинится нагрузка. --- ## 1. Аутентификация 1. Google Workspace как SSO - подключаем? Известно, что все 106 пользователей - внутренние сотрудники, внешних нет. Значит все должны быть в Workspace - так? 2. Нужен ли резервный обычный вход по логину и паролю - на случай недоступности SSO и для служебных учёток? 3. Сейчас `/api/me` возвращает `role` и плоский список доступных отчётов. Фронтенд проверяет только `role === "admin"`, остальные значения не различает. Мы эту схему заменяем целиком или надстраиваем над существующей? 4. Кто владеет пользователями сейчас - отдел аналитики руками или есть централизованное управление? ## 2. CRM как источник данных о сотрудниках Ты говорил, что подключишь CRM. Нужны детали. 5. Какая CRM и есть ли у неё API или вебхуки на изменение сотрудника? 6. По какому полю сопоставлять сотрудника в CRM с пользователем отчётов: корпоративная почта, табельный номер, что-то ещё? 7. С какой задержкой статус в CRM меняется после реального увольнения - в тот же день или через неделю? Если через неделю, автоблокировка проблему безопасности не решает, и нужен ещё ручной рычаг. 8. Ловим только увольнение или **перевод между отделами** тоже? При модели «отдел → роль → набор отчётов» перевод обязан менять доступы автоматически, иначе человек копит права, переходя с места на место. Именно так и появляются лишние доступы. 9. Внешних пользователей сейчас нет - все 106 внутренние. Планируются ли подрядчики или партнёры с доступом к отчётам? Если да, им нужен отдельный механизм с явным сроком действия, потому что в CRM их не будет. 10. CRM - источник правды только про «работает / не работает», или ещё и про отдел и должность? От этого зависит, выводятся роли автоматически или назначаются руками. ## 3. Модель прав 11. **Решено на этой итерации: права только на уровне отчёта целиком.** Прав на уровне строк и колонок не делаем. Подтвердить надо вот что: когда они понадобятся - а рано или поздно понадобятся, «менеджер видит только своих трейдеров» - это переписывание всех запросов в бэкенде, а не настройка во фронте. Заложить это в дорожную карту сейчас дешевле, чем переделывать потом. 11a. Есть ли требования регуляторов или внутренних политик, из-за которых права на уровне строк понадобятся раньше, чем мы рассчитываем? 12. Есть ли данные, которые нельзя показывать части сотрудников: маржа, комиссии, персональные данные клиентов? **Решено, не обсуждается:** выгрузка в Excel обязана уважать права. Пока прав внутри отчёта нет, это сводится к простому правилу «нет доступа к отчёту - нет и выгрузки». Но когда появятся права на уровне строк и колонок, экспорт обязан их соблюдать, иначе скрытое утекает через файл. Заложить в бэкенд сразу - переделывать потом дороже. 13. Нужен ли журнал доступа - кто какой отчёт открывал и когда? Требуется ли он для аудита или комплаенса? 14. Кто в итоге выдаёт и отзывает доступы: руководитель отдела, отдел аналитики, ты? ## 4. Бэкенд и разделение работ 15. Кто делает бэкенд платформы - существующая команда, новые люди, подрядчик? Когда они могут начать? 16. Мы делаем фронтенд и макет ролевой системы. Чтобы бэкенд потом подключился без переделок, нужен согласованный контракт API. Кто со стороны бэкенда его согласует и когда? 17. Отдадите ли доступ к репозиторию отчётов halleg? Не к серверу и не к продовым данным - только код. Без него глоссарий метрик собирается лишь по 11 страницам из 19. 18. Существует ли файл **`TIER_CALCULATION.md`**, на который ссылается формула `Score` в Weekly KPI («Power BI Main Dashboard, 1:1 з Affiliate-pc»)? Если да, это готовая точка правды хотя бы для скоринга. ## 4a. Генерация блоков через Claude Аналитики уже генерят блоки с графиками и таблицами через Claude и публикуют результат без ревью. Если встраивать это в платформу, нужны твои решения. 18a. Готов ли ты к тому, что платформа вызывает Claude API на сервере? Это бюджет, ключи и исходящий доступ в интернет с бэкенда. 18b. Допустимо ли, чтобы в промпт уходили названия метрик, структура таблиц и примеры данных? Если данные чувствительные, нужен режим, где уходит только схема. 18c. Принципиальный вопрос: генерируем **код** или **конфигурацию**? Сгенерированный JS исполняется в браузере у всех пользователей отчёта, а ревью сейчас нет. Декларативный конфиг блока (тип графика, метрика из реестра, разрез, фильтры) такой возможности не даёт, зато его можно валидировать схемой. Мой ответ - конфигурация, подробности в ответе на вопрос про генерацию. 18d. Нужно ли обязательное ревью перед публикацией сгенерированного блока, или платформа публикует сразу? ## 5. Инфраструктура 19. Где живёт платформа: внутренний домен, VPN, публичный адрес с авторизацией? Какой домен закрепляем? 20. **Решено 21.09.2026: отчёты переезжают к нам целиком.** Платформа на своём сервере, нужен весь код отчётов и их бэкенд, halleg выводится из эксплуатации. Дороже на старте, но нагрузка чинится один раз и навсегда. Отклонённый вариант, платформа у нас, а отчёты остаются на halleg и открываются через неё, потребовал бы сквозной авторизации между двумя доменами и CORS, а нагрузку на halleg не лечил бы, а маскировал. Следствия для разговора: вопросы 21 и 22 про кэш и реплику становятся вопросами к переезду, а не к текущему halleg. Нужен план миграции: порядок переноса отчётов, срок параллельной работы двух систем, момент отключения halleg. 21. Есть ли кэширование ответов `/api/*` или каждый запрос идёт в базу? От этого зависит, насколько оценка нагрузки в 498 000 вызовов в неделю близка к реальности. 22. Отчёты читают из продовой базы напрямую или из реплики? ## 6. Приоритеты 23. Что для тебя важнее в первую очередь: контроль доступов, снятие нагрузки, единый источник метрик или единая точка входа? Если выбрать одно - что? 24. Есть ли внешний срок - аудит, проверка, отчётность - к которому что-то обязано быть готово? 25. Какие отделы подключаем после аналитики, трейдеров и саппорта? ## 7. Что решаем сами, если не возразишь Это не вопросы, а уведомление. Возражения принимаются сейчас, потом дороже. - **Стек демки:** статический HTML без сборки, данные отдельно от разметки. Причина: бэкенда пока нет, а переезд на нормальный SPA позже выйдет дешевле, чем строить его сейчас вслепую. - **UX существующих отчётов не меняем.** Приводим к единой палитре и чиним то, что тормозит. Переработка - отдельный разговор после запуска. - **Мобильную версию не делаем.** - **Языки:** EN, RU, UA - все три, как сейчас. - **Мёртвые отчёты** (ноль посещений за неделю) в демку не тащим, выносим в архив.