Gap-анализ бизнес-сценариев (шаг 4)¶

Дата: 2026-06-26 · Автор: команда документации (роль doc-ba). · Статус входа: черновик для планирования шага 5.

Цель: свести покрытие документации сценариями и список того, чего не хватает — и как «не описано, но есть в системе», и как «продуктовый пробел (to-be)». Это вход для дописывания сценариев (шаг 5) и Trientes (шаг 2).

Метод и источники¶

• Что задокументировано сейчас: docs/projects/teslapay/scenarios/* (перенос из вики main/TeslaPay/*), docs/projects/trientes/scenarios/* (пока копии TeslaPay), docs/_shared/*.
• Что должно быть описано: swimlane-сценарии admin_panel/docs/scenarios/ (SC-001..015) + возможности сервисов (admin_panel/docs/services/*, analysis/*).
• Продуктовые пробелы (to-be): admin_panel/docs/analysis/missing-scenarios.md (аудит 2026-03-04: 67 недостающих сценариев, 21 «сломанное взаимодействие»).

Легенда статуса покрытия: | Метка | Значение | |---|---| | ✅ | Задокументировано сценарием (хотя бы как перенос из вики; качество/сверка — отдельно) | | 🟡 | Частично / поверхностно / требует переписи по шаблону | | 📝 | Есть в системе, но НЕ описано сценарием — основной долг документации | | 🔮 | Продуктовый пробел (to-be) — функционала нет/сломан (из missing-scenarios.md); описывать как целевой при наличии решения |

⚠️ Метки ✅/🟡 отражают наличие документа, а не сверку с кодом. Сверка (verified_with_code) — зона doc-sa (шаг 7/5). Продуктовые пробелы 🔮 взяты из аудита от 2026-03; перед описанием как «есть» — перепроверить в коде (могли реализовать).

TeslaPay — покрытие по доменам¶

auth / профиль¶

kyc-aml¶

accounts / payments¶

cards¶

limits-fees¶

b2b¶

payments / эквайринг (платформенный контур, релевантный TeslaPay)¶

Trientes — покрытие¶

Текущее состояние: trientes/scenarios/* — дословные копии TeslaPay (не адаптированы) + Scenarios/search.md (универсальный поиск). Собственно Trientes (крипто-эквайринг) почти не описан.

Шаг 2 = превратить копии в корректные Trientes-сценарии: общие — пометить sync: copy (синхронны) либо fork (разошлись); специфичные крипто-эквайринговые — написать заново (офрамп, котировка, AML-блок).

Межпродуктовые пробелы (затрагивают всё, из аудита)¶

🔮 Аудит-трейл (P0, нет нигде) · распределённая трассировка · health-check protocol · circuit breakers · DLQ Kafka · Сага/компенсация мультисервисных транзакций · rate limiting на шлюзе · graceful degradation · feature flags · управление жизненным циклом данных. Это скорее архитектурные/нефункциональные темы — кандидаты в tech-info/диаграммы потоков (doc-architect), а не в пользовательские сценарии.

Сводный долг документации (приоритезация для шага 5)¶

Группа A — переписать существующее по шаблону (🟡→✅). ~50 сценариев TeslaPay. Массовая, механическая + сверка с кодом. Бьётся по доменам между doc-sa (по сервисам) и doc-ba (сквозные).

Группа B — описать существующее, но недокументированное (📝). Приоритет: 1. Возврат/чарджбэк (payments) — есть платформенный acq, разнести/описать. 2. Депозит Trientes (crypto) — есть в crypto-acquiring. 3. 3DS онлайн-оплата картой. 4. Выписки по счёту (если реализованы — проверить).

Группа C — целевые to-be (🔮), описывать при наличии решения/после сверки. P0 в первую очередь: PSD2 SCA, синхронная AML-блокировка, управление PIN карты, сверка расчётов, восстановление 3DS, фиатный офрамп Trientes, мультисподпись/HSM (крипто).

Перед переводом любого 🔮 в «as-is» — обязательная сверка с кодом (doc-sa): аудит от 2026-03 мог устареть (часть админских пунктов уже реализована — см. раздел 6 missing-scenarios.md).

Находки сверки с кодом (по мере прогона)¶

Расхождения «вики/admin_panel ↔ реальный код», вскрытые при переписи. Детали — в Сверка с реализацией каждого сценария.

Домен auth (TeslaPay, сверено 2026-06-26 по CREL/users, CREL/api-gateway)¶

• D-1. Статус нового пользователя = confirmed, а не new (CREL/users/internal/service/user.go:187). Вики и sc-001-registration.json говорят new. Вопрос владельцу: так задумано или баг? Влияет на «нужен ли KYC до финопераций».
• D-2. Сложности пароля (буквы+цифры) в коде нет — только длина 8–128.
• D-3. Шага «установка PIN» в CREL нет (вероятно фронт). Подтвердить.
• D-4. Блокировки после 5 неверных OTP нет; lockout есть только у TOTP-flow (эскалирующий, порог 5).
• D-5. Отдельных шагов consent/email в users нет (email опционален).
• D-6. Методы 2FA (enable/confirm/disable) НЕ проброшены через api-gateway — точка входа фронта не подтверждена.
• D-7. Резервных кодов 2FA (admin_panel «8 кодов») в коде нет. Вход только по phone (email не поддержан в SignIn).
• Инфра-заметка: OTP-хранилище users — in-memory map (теряется при рестарте, без счётчика попыток).

Домен auth — доп. находки (сверено 2026-06-26 по CREL/users, CREL/api-gateway)¶

• D-8. Пользовательское закрытие/удаление аккаунта НЕ реализовано в CREL/users/api-gateway (несмотря на детальный сценарий и регуляторное требование). Статус removed меняется только служебно/из KYC. Критично.
• D-9. PIN и Face/Touch ID — полностью клиентские: серверного следа в CREL нет (SC-002/SC-110/SC-114). Зафиксировать как платформенный факт.
• D-10. Нет серверных гейтов подтверждения (2FA/доп. фактор) на бизнес-операции (изменение профиля SC-112, восстановление пароля SC-111), хотя матрица аутентификации их требует. Системный разрыв «матрица ↔ код».
• D-11. У password_reset_request нет TTL — бессрочно валидный reset-ключ/код до использования (security-гэп).
• D-12. Терминология: вики remote ↔ код removed (статус).

Домен kyc-aml (сверено 2026-06-26 по CREL/kyc, CREL/scoring, CREL/crypto-gateway, CREL/admin-api)¶

• Корректировка прежнего тезиса: AML-скоринг не «fire-and-forget». Транспорт асинхронный (Kafka scoring_requests→scoring_responses), но операция блокируется: crypto-gateway держит tx в WaitingScoring до ответа (CREL/crypto-gateway/internal/service/user_tx_out.go:713-738). Fire-and-forget — только запись AML-алерта в admin-api. Особый кейс Marble block_and_review → ответ не публикуется до решения оператора (admin-api поллит).
• KYC-провайдер — welID (Sumsub-совместимый), не «SamSub»; загрузка документов через SDK провайдера, kyc получает вебхуки (HMAC-SHA1). Вердикт RED→ON_HOLD (не REJECTED).
• Единого «AML-балла пользователя» нет; medium/high — эвристика admin-api по reason; вердикт скоринга бинарный is_ok.
• TODO: где скорятся фиат-операции (в коде инициирует только crypto-gateway); сверка aml_1..aml_12 ↔ Marble/AmlScenario — отдельная волна.

Данные (сверено 2026-06-26)¶

• accounts (CREL/accounts): схема миграций существенно расходится с admin_panel/docs/analysis/db/01-accounts-db.md (2026-03-04, устарел). assets.id: модель string vs БД UUID.
• users (CREL/users): схема расходится с admin_panel/docs/analysis/db/02-users-db.md (устарел; EAV user_data удалена миграцией). Возможные «мёртвые»/легаси артефакты: users.is_activated (не читается репозиторием), activation_links (нет обращений в internal/).
• Общий вывод: admin-db-дампы от 2026-03 устарели — источник истины только миграции CREL/<svc>.

🚩 Для инженерной/продуктовой команды (не доковые решения): D-1 (статус new/confirmed), D-8 (нет закрытия аккаунта), D-10 (нет серверных 2FA-гейтов на операции), D-11 (нет TTL у reset). Это потенциальные функциональные/комплаенс/security разрывы, выявленные при документировании.

Домены accounts / payments / cards (сверено 2026-06-26)¶

🚩 Значительная часть «платёжных» сценариев вики TeslaPay — целевые (to-be), не реализованы или не подключены к пользовательскому пути: - Закрытие счёта (SC-130): gRPC-метода нет; accounts.is_active — мёртвый toggle (нигде не вызывается). - Блокировка счёта (SC-131): scoring.ManualBlock — информационный флаг для админки, не enforced на пути денег (нет проверки в api-gateway/accounts), не меняет is_active. - Внутренний перевод (SC-141): реализован, атомарен (транзит-счёт, double-entry), но лимитов и 2FA в backend НЕТ, комиссия = 0. - Google/Apple Pay (SC-140), card→card P2P (SC-142), снятие в банкомате (SC-143): как описано — не существуют (G/A Pay только в крипто-обмене; P2P нет; ATM-обработчика нет; ближайшее — debit по Verestro-карте). - SEPA (SC-101): рельс есть в fuse-pay-service (провайдер Fuse, не абстрактный SEPA), но не подключён к api-gateway и не интегрирован с accounts; деньги — float64. - Пластиковая карта (SC-150): не реализована (конвейер всегда VIRTUAL). - PDF чеки/выписки, реальные IBAN/BIC (view_balance/history): в коде нет; IBAN/BIC в gateway — захардкоженные плейсхолдеры. - Деньги: внутри accounts — корректно NUMERIC(28,8); во внешних адаптерах fuse-pay-service/Fenige — float (нарушение принципа decimal).

🚩🔒 Security — сервис cards (репозиторий АРХИВИРОВАН, фиксы заблокированы до разархивации): - Вебхуки Verestro /external-api/verestro/* (балансы, кредит/дебет, reversal) — без аутентификации. - PIN передаётся провайдеру и логируется открытым текстом (doRequest печатает payload; входящие вебхуки логируются целиком). - Контракт CreateVirtualCardResponse возвращает полный PAN+CVV (на сейчас частично нейтрализовано закомментированным кодом). - HandleRequest без транзакции (// todo: use tx!) — риск частично созданных сущностей (баланс без карты).

Данные kyc / scoring (сверено 2026-06-26)¶

• kyc: access_tokens.CreateAccessToken строит INSERT с несуществующей колонкой и не вызывает Exec — токен доступа фактически не сохраняется (баг/мёртвый код).
• scoring: scoring_request.amount и crystal_checks.risk_score хранятся строкой (VARCHAR) при decimal-семантике; рассинхрон типов модель↔схема.
• admin-db-дампы (08-kyc-db.md, 05-scoring-db.md, 2026-03) — устарели; источник истины — миграции CREL.

Домены limits-fees / support / b2b / exchange (сверено 2026-06-26)¶

• 🚩 Лимиты НЕ enforced preflight. Учёт потребления — async из Kafka (limiter consumer), но CheckExceed вызывает только admin-api по запросу оператора; ни один операционный сервис (accounts/перевод/обмен/эквайринг) лимит перед операцией не проверяет. Кэш лимитов — заглушки (return nil,false); учёт/проверка не атомарны (гонка), нет дедупликации Kafka-событий.
• 🚩 Блокировка пользователя (SC-013): users.SignIn НЕ проверяет is_enable — заблокированный технически может авторизоваться (потенциальный баг, CREL/users/internal/service/user.go:234-281). Отмены активных операций/сессий при блокировке нет.
• 🚩 B2B не реализован: регистрация ЮЛ (SC-181) отсутствует полностью; смена управляющего (SC-180) — лишь операторский toggle is_manager, без бизнес-воркфлоу (профиль ЮЛ, приглашение, подтверждение, KYC управляющего).
• Оплата счетов (SC-171) и подписки/рекуррент (SC-172) — не реализованы (целевые; «invoice» в эквайринге — это карточный эквайринг мерчанта, не коммунальные платежи).
• Обмен валюты (SC-190): реализован в 2 контурах — quick-exchange (внутренний, decimal, курс из orderbook) + ExchangerService (крипто + фиат on/off-ramp; G/A Pay/SEPA — методы оплаты фиат-обмена). Лимитов пользователя в обмене нет.
• Единого fee-сервиса нет; комиссии считаются в эквайринге (decimal). Self-service управления лимитами пользователем нет (ставит оператор).

Данные limiter / sender / courses (сверено 2026-06-26)¶

• limiter: суммы в БД NUMERIC(18,2), но в Go — string + ParseFloat/NullFloat64 (нарушение decimal, потеря точности). Кэш — заглушки; нет ретеншна партиций events.
• courses: курсы корректно NUMERIC(28,8)/decimal; нюанс — SMA читает AVG(price) в float64.
• sender: денежных колонок нет; notification_params.code глобально UNIQUE — конфликт с мультипроектностью; notification_senders.config (JSONB) = credential провайдеров.
• Дампов limiter/sender/courses в admin-db нет (аудит 2026-03 не смог подключиться к их БД) — сверка только по коду.

AML-правила aml_1..aml_12 (SC-201..212, сверено 2026-06-26)¶

• 🚩 Ни одно из 12 AML-правил не реализовано хардкодом в CREL. Транзакционный AML: scoring вызывает внешний rule-engine Marble (один ScenarioID) + Crystal (KYT крипто-адресов). Вся логика правил (пороги, окна, агрегаты, словари, списки стран/категорий, velocity) — в конфиге Marble, которого нет в репозитории → verified_with_code: false для всех 12.
• admin-api.AmlScenario — только CRUD-каталог метаданных правил (код/порог/regulatory basis) для UI + запись AML-алерта по is_ok=false; движок оценки не там. Seed даёт маппинг aml_N → SCN-0NN.
• 🚩 Контракт ScoringRequest несёт одну операцию без истории/агрегатов/страны/описания/категории/признака high-risk → правила, требующие этих данных (бездействие, обороты, ключевые слова, страны, «первая операция», круговые переводы, high-risk), на стороне CREL принципиально невычислимы без агрегации внутри Marble или доработки контракта. Вопрос владельцу: где хранятся чёрный список (aml_7), страна операции (aml_9), признак high-risk (aml_12); есть ли batch-прогон для aml_12.

Данные crypto-gateway / cards / quick-exchange / notifications (2026-06-26)¶

• 🚩🔒 crypto-gateway: приватные ключи кошельков — открытым текстом (keys.private_key_hex, без Vault/KMS/HSM, используются напрямую при подписи; тестовые ключи в сиде). RPC-URL/API-ключи адаптеров — тоже plaintext (adapter.url/option). P0.
• crypto-gateway: типы сумм непоследовательны — часть NUMERIC, часть строкой (user_tx_out.amount, commission_*, балансы system-кошельков) — риск точности. 15 таблиц, 15 FK.
• cards: текущая схема (миграции) ЛУЧШЕ устаревшего admin-дампа по PCI — хранится только last4 PAN, CVV/PIN не персистятся (PIN — плейсхолдер wpin). Балансы — целые в минорных единицах (BIGINT). (Замечания аудита 07-cards-db о plaintext PAN/CVV — к текущей схеме не относятся.)
• quick-exchange: суммы NUMERIC(99,18), но history.fee — строкой. notifications: 2 таблицы (notifications,templates), FK нет.

Что дальше¶

• Шаг 5 работает по группам A→B→C, каждый сценарий — по _TEMPLATE/scenarios/sc-000-template.md, со сверкой кода (doc-sa) и индексом.
• Шаг 2 (Trientes) использует группу из раздела Trientes выше.
• Шаг 6 (диаграммы) — после готовности сценариев, swimlane-модель уже заложена в шаблон.
• Этот файл ведёт doc-ba; обновлять по мере закрытия пробелов.