На стороні оператора MatchGuard означає: людина заходить у систему і бачить чіткий, спокійний, преміальний інтерфейс, у якому зрозуміло що робити зараз, скільки на цьому можна заробити, і де гроші вже лежать на балансі.

Operator CRM — це робоче місце виконавця. Мінімалізм, швидкість, точна типографіка, відсутність зайвого шуму — але з акцентами там, де це додає азарту: прогрес, стріки, баланс.

Персона, під яку проєктуємо кожен екран:

• Здебільшого віддалений виконавець із країн з нижчою вартістю праці — LATAM, Східна Європа, Південно-Східна Азія, MENA.
• Заходить через десктоп (робочі сесії) і телефон (швидкі сесії 10–20 хвилин, перевірка балансу).
• Працює одразу за гроші — мотивація фінансова, тож фінансовий стан інтерфейсу завжди на видноті.
• Не є технічним користувачем. Криптогаманець уже має, але інтерфейс не повинен припускати знання Web3.
• Не реєструється сам — доступ створює Admin. На CRM немає форми реєстрації, лише вхід.

• На сайті CRM (app.matchguard.ai) публічна тільки сторінка входу. Усе інше — за авторизацією.
• Облікові записи створює Admin із адмінки. Оператор отримує логін і початковий пароль на пошту.

При першому вході система примушує:

1. Змінити пароль.
2. Підтвердити пошту.
3. Пройти онбординг-тур (можна скіпнути, але система ввічливо нагадає).

Може змінити сам: пароль, аватар, мову, тему, налаштування сповіщень, дефолтні налаштування виплат.

CRM і адмінка живуть в одному моно-репозиторії Turborepo, але як два незалежних Next.js-застосунки з окремими білдами і розгортанням на різних доменах. Спільний код (UI-кіт, типи, i18n-словники, API-клієнт) шариться через внутрішні npm-пакети. Бекенд — єдиний NestJS-сервіс, що обслуговує обидва фронти на основі role-based гардів. Деталі — у 4.1–4.3.

4.1 Багатодоменна архітектура

Продукт розгорнутий на трьох окремих доменах і на двох серверах:

Свідоме рішення — окремі apex-домени, а не піддомени (app.matchguard-ai.com). Мотивація:

• Reconnaissance-захист. З бренд-домену не видно, де живуть операторська й адмінська зони — subdomain enum їх не знайде.
• Ізоляція cookies і origin-boundary. Лендінг з формами й третьосторонніми скриптами не ділить origin з чутливими зонами. Різні apex — жорсткий cookie/CORS boundary за замовчуванням.
• Індексація. Admin і CRM — robots: noindex, окремий домен посилює ізоляцію від SERP.
• Бренд-розподіл. Домени можуть виглядати нейтрально (без згадки бренду) для операторських цілей.

4.2 Один проєкт чи три? → Монорепо Turborepo

Розглянуто три архітектурні варіанти:

Структура моно-репо:

matchguard-platform/            (git repo)
├── apps/
│   ├── crm/                    → Next.js → CRM-домен
│   └── admin/                  → Next.js → Admin-домен
├── packages/
│   ├── ui/                     → shadcn обгортки, спільні компоненти
│   ├── types/                  → TS-типи, DTO, енуми (єдине джерело)
│   ├── api-client/             → типізований клієнт NestJS
│   ├── i18n/                   → спільні строки, next-intl утиліти
│   ├── icons/                  → централізовані іконки (lucide)
│   └── config/                 → ESLint / TS / Tailwind preset
└── services/
    └── api/                    → NestJS backend (єдиний для CRM і Admin)

Бекенд — один NestJS-інстанс на приватному API-хості, обслуговує обидва фронти. Розподіл прав — на рівні гардів (@Roles('OPERATOR'), @Roles('ADMIN'), @Roles('SUPERADMIN')). Оператор фізично не може досягти admin-endpoints — блокується гардом на бекенді, навіть маючи URL. CORS-whitelist — тільки CRM- і Admin-домени. Landing лишається окремим проєктом на окремому сервері й у монорепо не потрапляє.

4.3 Взаємодія з лендінгом

Лендінг фізично на окремому сервері й поза монорепо, тож потрібен чіткий контракт передачі даних (заявки, ліди). Схема для MVP — пряма HTTP-передача:

• Endpoint POST /public/leads. Захист: Cloudflare Turnstile на формі, HMAC-підпис shared secret'ом, rate-limiting по IP, whitelist Referer/Origin.
• Тіло — лише нечутливі дані заявки. Без auth-токенів і сесій — односторонній публічний вхід. Усі leads логуються (source, IP, UA, timestamp) для антифроду.
• У БД — окрема таблиця landing_leads (не входить у users). Адмін бачить заявки в секції «Applications» і конвертує дією «Approve as operator» — тоді дані переносяться в users з правильним adminId.

На майбутнє (якщо трафік зросте): замінити прямий POST на брокер (Redis Streams / NATS / RabbitMQ) з ретенцією 7 днів, щоб лендінг працював навіть під час робіт з API. Для MVP — over-engineering, прямий POST закриває задачу.

Карта екранів, які бачить оператор:

/login                      → публічна сторінка входу
/operator                   → редирект на /operator/dashboard
/operator/dashboard         → головна (огляд, активна робота)
/operator/tasks             → список призначених задач
/operator/tasks/:id         → деталь задачі (категорії всередині)
/operator/work/:id          → робочий екран (виконання завдань)
/operator/balance           → баланс, історія, статистика
/operator/balance/withdraw  → майстер виведення коштів
/operator/messages          → чат з адміном
/operator/notifications     → центр сповіщень
/operator/profile           → профіль (read-only поля + аватар)
/operator/settings          → налаштування
/operator/help              → FAQ, перезапуск туру, контакти

Загальний tone

Інтерфейс має дихати. Багато повітря, мало рамок, ніяких градієнтних кнопок з 2014 року. Один акцентний колір + нейтральна шкала. Світла тема — м'які тіні. Темна — без чорного #000: м'який вугільний (#0B0D10 / #111418) з ледь помітними внутрішніми підсвітами карток.

Кольори

Приклад палітри для подальшої деталізації дизайнером:

Типографіка

Один шрифт — Inter із чіткою шкалою: 12 / 14 / 16 / 20 / 28 / 40. Числа — табулярні (особливо в балансі та статистиці), щоб не «плавали».

Радіуси, тіні, стани

• Cards / inputs: rounded-xl (12 px); modals: rounded-2xl.
• Тіні м'які, тільки на елементах, що реально «плавають» — поповер, тостер, модалка.
• Чіткі й ввічливі empty / loading / error / success стани з ілюстрацією і однією CTA. Ніяких «Сталася помилка» без подробиць.

Анімації

• Page transitions: легкий fade + slight Y-shift.
• Toast: slide in від нижнього правого (десктоп) / зверху (мобільний).
• Hover: 150 ms ease-out. Прогрес-бари — плавна заливка з невеликим shimmer.
• prefers-reduced-motion поважаємо.

Desktop ≥ 1024px

┌────────────────────────────────────────────┐
│ ┌────────┐  ┌──────────────────────────┐    │
│ │        │  │ Topbar                   │    │
│ │ Side   │  ├──────────────────────────┤    │
│ │ bar    │  │                          │    │
│ │        │  │     Page content         │    │
│ │        │  │                          │    │
│ └────────┘  └──────────────────────────┘    │
└────────────────────────────────────────────┘

Sidebar (collapsible) — три смислові розділи:

• Робота: Dashboard · My Tasks · Continue Work (швидкий вхід в останню активну категорію).
• Гроші: Balance · Withdraw.
• Зв'язок: Messages (з бейджем непрочитаних) · Notifications.
• Профіль: Profile · Settings · Help.
• Внизу — блок «Earned today: $X.XX» + аватар + кнопка згортання.

Topbar справа наліво: language switcher → theme toggle → notifications bell → user menu (Profile, Settings, Logout).

Mobile < 768px

• Sidebar схований у Drawer (відкривається з лівого краю).
• Замість sidebar — bottom navigation з 5 пунктами: Home · Work · Balance · Messages · More.
• Topbar компактний: логотип, баланс, bell, аватар. На робочому екрані — окремий mobile-режим зі збільшеними тач-зонами.

Tablet 768–1023px

Сайдбар згорнутий до іконок за замовчуванням, розгортається на ховер/клік.

Це найважливіша частина продукту. У оператора має скластись враження за перші 5 хвилин, що ним займаються.

Технологія і логіка

Обираємо Driver.js (MIT, легка, framework-agnostic, дружить з Next.js 15 через dynamic import). Альтернативи — Onborda або React Joyride v3. Прогрес туру зберігається на бекенді (User.onboardingProgress), щоб продовжити з іншого пристрою. Перезапуск — будь-коли зі сторінки Help.

Тур розбито на 3 акти по ~30 секунд — один безперервний 90-секундний тур втомлює, а три короткі «акти» — це геймдиз-патерн.

• Підсвітка sidebar: «This is your workspace. Everything you need is here.»
• My Tasks: «Your admin assigns you tasks — work packages with categories inside.»
• Balance + баланс у кутку: «Every completed item adds to your balance.»
• Theme: «Working at night? Switch to dark mode anytime.»

• «Let's open your first task» → перехід на /operator/tasks.
• Категорії всередині: «Each category pays a different price per unit.»
• Кнопка Start working → екран завдання.
• Демо: кнопки Approve / Reject / Skip і гарячі клавіші 1/2/3.

• Balance: «When you're ready to withdraw, come here.»
• Withdraw: «We send payouts in crypto — USDT, USDC, BTC, ETH and more.»
• Messages: «Need to ask your admin something? Write directly here.»
• AI-асистент (правий нижній кут): «Stuck on something? Our AI assistant is always here — 24/7.»
• Фінал: «🎉 You're ready. Good luck and welcome to MatchGuard.»

10.1 /login — Sign in

• Центральна картка ~420 px, легкий glassmorphism, логотип + слоган.
• Помилки — інлайн під полем, без red'а на весь екран.
• Внизу: «Forgot password?», селектор мови, лінк на статус системи.
• Після 5 невірних спроб — м'який captcha (Cloudflare Turnstile).

10.2 /operator/dashboard — Home

Посадкова сторінка — те, що оператор бачить щодня першим. Зверху вниз:

1. Welcome strip: «Good evening, {FirstName}» + дата + індикатор streak («🔥 5-day streak»).
2. Active work card: назва активного завдання, прогрес-бар, скільки залишилось і скільки ще заробити, CTA «Continue working».
3. Today's stats: Tasks done · Earned today · Average rate ($/hour).
4. Earnings chart: лінійний графік за 14 днів (Recharts).
5. Activity feed: «+$0.05 — Photo Moderation #023», «Task 'Traders #15' assigned», «Admin sent you a message».
6. Tips card + Quick actions (mobile only).

10.3 /operator/tasks — My Tasks

• Вкладки Active / Completed / All; сітка карток (3 кол. desktop, 1 mobile).
• Картка: title, призначені категорії з лічильниками, загальний прогрес-бар, потенційний заробіток, дедлайн з кольоровим індикатором, кнопка Open.
• Сортування: за прогресом, дедлайном, призначенням.

10.4 /operator/tasks/:id — Task detail

• Над фолдом: загальний прогрес + сумарний заробіток із цього завдання.
• Список лише призначених оператору категорій (інші він не бачить — це принципово): назва, ставка «$0.05/item», прогрес «220/500», очікуваний дохід із решти, CTA Start / Continue.
• Якщо одиниць немає — статус «Awaiting refill» з тултіпом.

10.5 /operator/work/:id — Робочий екран

Серце продукту. Тут оператор проводить найбільше часу — інтерфейс спокійний, фокусний, швидкий.

┌────────────────────────────────────────────┐
│ Topbar (мінімальний, без sidebar)          │
├────────────────────────────────────────────┤
│  ┌──────────────────────┐  ┌─────────────┐  │
│  │                      │  │ Action      │  │
│  │  Item content        │  │  ✅ Approve [1] │
│  │  (фото / відео /     │  │  ❌ Reject  [2] │
│  │   профіль)           │  │  🚩 Flag    [3] │
│  │                      │  │  ⏭️  Skip   [4] │
│  └──────────────────────┘  └─────────────┘  │
├────────────────────────────────────────────┤
│ Progress • 120/500 • Earned session: $6.00 │
└────────────────────────────────────────────┘

• Гарячі клавіші 1/2/3/4, авто-збереження після кожної дії — без «Save».
• Undo останньої дії (Ctrl+Z) впродовж 5 секунд. Skip не зараховує оплату, повертає item у пул.
• Pause/exit будь-коли — сесія зберігається. На мобільному — нижня панель з великими кнопками + свайпи (опційно).
• На вибраних категоріях (Deepfake Detection) бічна панель містить підказки — ознаки, на які звертати увагу.

10.6 /operator/balance — Balance

• Hero: Available — усі виконані одиниці зараховуються миттєво й автоматично, без ручної модерації адміна.
• Pending — виведення у процесі (від кнопки Withdraw до фінального підтвердження транзакції в мережі). Lifetime earned + CTA Withdraw.
• Графік earnings (7d / 30d / 90d / All) + donut-розбивка по категоріях.
• Tabs: Earnings history (дата, завдання, категорія, кількість, сума) · Withdrawals history (статус, txid → explorer).

10.7 /operator/balance/withdraw — Withdraw wizard

Майстер у 3 кроки на одній сторінці; крок 2 розблоковується після валідного кроку 1.

10.8 /operator/messages — Chat with Admin

• Один зафіксований канал — з призначеним адміном. Інтерфейс месенджера, realtime через Socket.IO.
• Текст з базовим Markdown, прикріплення (зображення до 10 MB), реакції-емодзі (опц.), системні повідомлення інлайн.
• Можна поскаржитись адміну на item із робочого екрану («Ask admin» з підвантаженим контекстом).
• Заборонено: писати іншим операторам, перевідкривати канал, видаляти історію.

10.9 /operator/notifications — Center

• Фільтри: All · Work · Balance · Messages · System. Mark all as read.
• Перехід на джерело події (лінк «Open task»). Toast у правому нижньому куті + запис у центр.

10.10 /operator/profile — Profile

• Аватар (uploadable, з кропом). First / Last name — read-only з тултіпом.
• Operator ID, інфо адміна (ФІО + нікнейм + аватар, «Assigned since»), email, member since. У оператора рівно один адмін — без мультиселектора чи перемикача.
• Stats: lifetime earned, total items, streak best, achievements.

10.11 /operator/settings — Settings

10.12 /operator/help — Help

• Search bar · FAQ за категоріями · «Replay onboarding tour» (велика кнопка).
• Глосарій (Task, Category, Item, Pending) · «Contact your admin» / «Contact support» · uptime indicator.

Окрім чату з живим адміном (10.8), у CRM є другий канал допомоги — AI-асистент, що працює цілодобово і відповідає миттєво.

11.1 Навіщо окремо від чату з адміном

Чат з адміном — для питань, що потребують людського рішення. AI-асистент — для всього, що можна пояснити з документації миттєво, не чекаючи, поки адмін онлайн: «Як вивести гроші?», «Чому я не можу вивести кошти?» (пояснює 7-денний період і мінімум $1 245.50), «Що таке категорія Deepfake Detection?», «Де історія виплат?», «Як змінити мову?», «Що означає Awaiting refill?». Це знижує навантаження на адмінів і дає відчуття, що допомога є завжди.

11.2 Розміщення і поведінка

• Плаваюча іконка у правому нижньому куті на всіх сторінках (крім /operator/work/:id, де згорнута до крапки, щоб не заважати фокусу — розгортається по кліку).
• Клік відкриває компактне chat-вікно (bottom sheet на мобільному, floating panel ~380×520px на десктопі) — не окрему сторінку, не редирект.
• Бейдж-анімація при першому вході (крок в Акті 3 онбординг-туру). Стани іконки: default / hover / active / typing.
• Історія діалогу зберігається per-user — можна закрити й повернутись, контекст не губиться в межах сесії.

11.3 Що асистент вміє

Може: відповідати на питання про функціонал (та сама база знань, що й /operator/help, але в розмовному форматі); пояснювати терміни (Task, Category, Item, Pending, Trust Score — у загальних рисах); давати короткі туторіали з підсвіткою елементів (легка інтеграція з тим самим механізмом, що й Driver.js-тур); допомагати з навігацією («Take me there»); ескалувати до живого адміна — «This looks like something your admin should help with» → CTA відкриває /operator/messages з попередньо заповненим повідомленням.

11.4 Технічна реалізація

11.5 Безпекові межі

11.6 Аналоги

Intercom Fin / Resolution Bot — стандарт AI-first support-віджета з чіткою ескалацією до людини. Linear's in-app assistant — мінімалізм, відповіді в контексті сторінки. Notion AI Q&A — RAG на власній документації, той самий підхід переносимо на Help-контент.

Канали доставки

Поведінка та стек

• Toast: автохайд 5с (info) / 7с (success), ручний close для error. Стек до 3 видимих, один CTA максимум, опційний звук «tick».
• Socket.IO gateway в NestJS, кімнати room:user:{id} + room:task:{id}.
• Бекенд публікує події через BullMQ → fan-out на гейтвей. Reconnect з offline-індикатором у топбарі.

• Daily streak — дні поспіль із виконаною роботою (поріг конфігурується). Показ на dashboard і в profile.
• Levels на основі lifetime items: не дають матеріальних переваг — лише статус і бейдж біля аватара. Запобігають синдрому «тільки гроші».
• Achievements: «7-day streak», «First $100 withdrawn», «Multi-category master». Колекція в profile.
• Personal records — тільки персональні, без leaderboard: лідерборди створюють тиск, уникаємо їх у MVP.

Підтримувані мови (11)

Принципи

• next-intl + JSON-словники по фічах. Дати/числа/валюти — через Intl.* з прив'язкою до локалі.
• Плюрали — ICU MessageFormat. RTL: автоматичний dir="rtl", sidebar дзеркалиться праворуч.
• Дефолтна мова: cookie → user setting → Accept-Language → English.
• На наступних ітераціях — Crowdin або Lokalise (поза скоупом MVP).
• FAQ і Help-контент локалізуємо самотужки (у нашій кодовій базі/БД), без зовнішніх helpdesk-платформ (Crisp / Intercom / Help Scout): уже є вбудований канал з адміном, а статичний FAQ якісно перекладається стандартним workflow. До хелпдеска повернемось, коли зʼявиться окрема support-команда.

• HTTPS-only. JWT: короткий access 15 хв + httpOnly refresh 30 днів з ротацією при кожному використанні (anti-replay).
• При деактивації акаунта адміном refresh-токен інвалідується миттєво; на логіні оператор бачить екран «Your account has been suspended» без деталей і публічної CTA на підтримку (деталі — у адміна іншими каналами).
• Rate limiting на /login, /withdraw, /messages. Cloudflare Turnstile після 5 невдалих логінів.
• 2FA (TOTP) — обов'язкове перед першим виведенням. Whitelist гаманців із email-підтвердженням.
• IP geo-логування при кожному вході; підозрілий новий регіон — email-нотифікація.
• Усі чутливі дії (зміна пароля, додавання гаманця, виведення) викликають email.
• CSP, XSS, SQL-injection — стандартно. Логи без PII. Sentry зі скрабом sensitive полів.

Ми свідомо відмовились від ручної модерації адміном (Додаток A, п. 1): кожен виконаний item зараховується автоматично, миттєво і без людини в циклі. Щоб це не стало дірою для зловживань, потрібна повноцінна автоматична модель довіри. Нижче — вся її механіка.

15.1 Класи загроз

• Speed farming — клікає «Approve» на все підряд заради лічильника.
• Boting — скрипт/макрос натискає замість людини.
• Multi-accounting — одна людина реєструє кілька акаунтів у різних адмінів.
• Collusion — група координує однакові відповіді, щоб пройти cross-check.
• Accuracy drift — працює чесно, наростив довіру, потім починає фейкувати.
• Payout abuse — швидкий фарм → миттєве виведення → зникнення (частково покрито 7-денним cool-down'ом і whitelist-гаманцями з 2FA).

15.2 Сигнали, які збирає система

• Honeypots (gold questions). У кожну категорію підмішуються items з відомою правильною відповіддю — 3–7% для нормальних, до 20% на probation. Оператор не знає, який item — honeypot. Помилки прямо знижують accuracy.
• Time-per-item baseline. Розподіл часу ретельного оператора (median, p25–p95). Хронічно нижче p25 → підозрілий; нижче p5 → майже гарантовано фейк.
• Cross-validation (soft consensus). Частина items іде на 2–3 операторів (вони не знають про перетин). Сходяться → валідно, всі отримують оплату. Розходяться → arbitration-pool. Одну категорію можна призначити кільком операторам (але не двічі одному в межах завдання).
• Behavioral biometrics (light). Патерн взаємодії у workspace: інтервали між кліками, рух миші, hotkeys vs миша, hesitation time. Ідеально рівні інтервали й нульовий рух миші — сигнал бота.
• Device fingerprint + IP. Композитний fingerprint (FingerprintJS OSS) + IP + гео. Ідентичний композит на кількох акаунтах → multi-accounting.
• Answer distribution. 98% approve при нормі категорії 60% → сигнал.
• Withdrawal velocity та session anomalies — різкі відхилення від власного базлайну оператора.

15.3 Trust Score — композитний показник

Усі сигнали агрегуються в число 0–100 на оператора. Зважений композит, перекалібровується щоквартально:

Score змінюється поступово (exponential moving average), а не стрибками — щоб один поганий день не убив історію нормального оператора.

15.4 Реакція системи залежно від Trust Score

Нові акаунти стартують з 55 (Normal) і мають 3-денний probation з honeypots 20%. За 3 дні добропорядні виходять у Trusted, проблемні — у Watch/Restricted.

15.5 Прозорість для оператора

• Trusted / Normal: нічого, робота як завжди.
• Watch: нічого явного; можливо трохи більше складніших items у пулі.
• Restricted: м'яке повідомлення на dashboard: «We noticed some unusual activity. Your withdrawals are temporarily paused for review.» — без конкретних сигналів.
• Suspended: той самий екран «Your account has been suspended», що й для деактивації адміном.

Адмін у своїй панелі бачить trust score команди, розбивку по сигналах і рекомендацію системи. Може вручну змінити стан (напр. зняти ban), але не може напряму підняти/занизити score — це системний показник, захищений від маніпуляцій.

15.6 Кошти підозрілого оператора

• Watch / Restricted → суми лежать на балансі, зростають, але не виводяться до нормалізації score.
• Suspended → баланс заморожений; після ручного review адмін може розморозити.
• Banned (рішення адміна після review) → баланс конфіскується. Правило в Terms of Service, які оператор акцептує при першому вході — без цього економічний стимул фроду не зникає.

15.7 Чому так, а не ручна модерація

• Масштабованість. Один адмін не перегляне 5 000 items/день від 20 операторів. Час адміна дорогий.
• Швидкість. Затримка платежу знижує engagement чесних. Миттєве зарахування утримує.
• Консистентність. Автоматика робить однакові рішення на однакових патернах; людина — ні.
• Data-driven. Статистика по мільйонах дій → retro-калібрація ваг. Ручні рішення не дають циклу навчання.
• Стандарт індустрії. Toloka, Appen, Clickworker, Scale AI працюють саме так.

15.8 Поза скоупом антифрод-модуля

• Точна ML-модель для behavioral biometrics — v1 rule-based на порогах, v2 з ML.
• Graph-based ML для detection collusion — на пізніше.
• Авто A/B-калібрація ваг Trust Score — на пізніше. ZK-докази роботи — далеке майбутнє.

Деталі імплементації (алгоритми, пороги, обробники) — окремий технічний документ. Цей розділ описує вимоги і логіку продукту, а не код.

CRM — це не просто responsive, це mobile-first для робочих сесій. Багато операторів робитимуть прості модерації з телефону.

• Workspace окремо оптимізований під мобілку: великі тач-зони, свайпи (опц.), фіксована нижня панель дії.
• Сітки 3-кол → 1-кол. Усі модалки — bottom sheet. Топбар компактний (баланс — лише сума).
• Жести pull-to-refresh у списках. iOS PWA installation (іконка, splash, standalone).
• Шрифти 16+ px (інакше Safari зумить). На повільних мережах — skeleton screens, optimistic UI у workspace.

• Адмінська панель (/admin/*) — окремий vision-документ.
• Робота SuperAdmin (завантаження контенту, створення варіацій, призначення).
• Бекенд-схема БД у деталях — окремий технічний документ.
• API-контракти — окремий OpenAPI. Лендінг matchguard.ai — окремий проєкт.
• Деталі імплементації автоматичного контролю якості і антифроду (алгоритми, обробники подій, ML-моделі) — окремий технічний документ. Логіка продукту описана в розділі 15.
• Лідерборди, командна гейміфікація — після MVP.

Після затвердження цього vision-документу:

Раніше — відкриті запитання; у v0.2 зафіксовані 9 ключових рішень.

Оновлено у v0.3. Із попереднього списку закрито:

Залишається відкритим:

Щоб адмінка читалась у контексті — вся ієрархія MatchGuard:

• SuperAdmin створює Variations (пакети контенту з категоріями) і призначає їх Admin-ам. Admin сам контент не завантажує.
• Admin отримує варіації «згори» і розподіляє їхні категорії між своїми операторами.
• Кожен Admin бачить і керує тільки своєю командою. Оператори іншого адміна для нього не існують.
• Оператор автоматично закріплюється за адміном, який його створив (один оператор — рівно один адмін).
• Термін «Variation» — рідна назва в адмінці. Оператор у CRM бачить це як «Tasks», але адмін працює з поняттям «Variation».

Admin — керівник групи операторів, умовний «team lead» підрядників. Його робота: набирати й заводити операторів, роздавати роботу (варіації та категорії), стежити за продуктивністю і якістю, комунікувати з операторами, наглядати за балансами і виплатами, тримати «особові справи» (документи, нотатки).

Admin — не технічний, але операційно грамотний користувач. Проводить у панелі багато часу і хоче швидко бачити стан команди, швидко заводити людей, швидко роздавати роботу і не робити помилок (наприклад, не призначити ту саму роботу двічі).

2.1 Окремий домен, НЕ піддомен

Адмінка — окремий apex-домен, фізично й логічно відрізаний від лендінгу, і це найчутливіша зона всієї системи. Чому не admin.matchguard-ai.com:

• Reconnaissance. Піддомен елементарно знаходиться через passive DNS, certificate transparency logs, subdomain enum. Окремий нейтральний apex цього не видає.
• Cookie / origin isolation. Піддомени ділять scope .matchguard-ai.com. XSS на лендінгу (маркетингові скрипти — велика поверхня) дістає cookie всього дерева. Окремий apex — жорсткий бар'єр.
• Індексація. Лендінг публічний і в SEO; адмінка невидима для пошуковиків. Окремий домен + noindex.
• Психологічний бар'єр. Оператор ніколи не натрапить на адмінку — навіть не здогадується про існування admin-URL.

2.2 Три домени, дві зони чутливості

CRM і Admin — різні apex-домени й між собою. Технічно з одного монорепо (apps/crm, apps/admin), але розгортаються на різні домени різними білдами — код адмінки фізично не потрапляє в бандл CRM.

2.3 Аналіз доменних імен (кандидати)

Кандидати для CRM (нейтральне, «робоче», легко диктується, бажано .com):

Кандидати для Admin (ще нейтральніше, можна generic-технічне, нічого не розкриває):

2.4 Як перевірити доступність

1. Bulk-search: Porkbun, Cloudflare Registrar (за собівартістю), Namecheap Beast Mode — вставляєш список, бачиш вільні/зайняті + ціни.
2. Перевір усі потрібні TLD для фіналіста (.com/.io/.app/.co) — зайняти основний + захисний.
3. Trademark-перевірка (Google + USPTO/EUIPO), щоб ім'я не збіглося з чужою маркою.
4. Реєструй через Cloudflare — одразу DNS, проксі, WAF, noindex-заголовки.

2.5 Мережева ізоляція (додатково до домену)

• Cloudflare Access (Zero Trust) — доступ до admin-домену лише після автентифікації на edge (email OTP / SSO), ще до того, як запит дійде до застосунку.
• Обов'язкове 2FA для всіх адмін-акаунтів (не опційне). noindex, robots deny-all, немає sitemap.
• Окремі жорсткіші rate-limiting і WAF-правила. Гео-логування входів (моніторинг, не блокування — доступ за країною не обмежуємо).

Стек — той самий, що у Частині I (монорепо Turborepo, apps/admin — окремий Next.js 15, спільні packages/*, єдиний NestJS з role-based гардами, Postgres + Prisma, Redis + BullMQ, Socket.IO). Специфічне:

/login                     → вхід (Cloudflare Access + форма + 2FA)
/admin                     → редирект на /admin/dashboard
/admin/dashboard           → головна: огляд команди, KPI, алерти
/admin/operators           → список операторів (моя команда)
/admin/operators/new       → створення оператора
/admin/operators/:id       → картка (профіль, стата, документи, нотатки, лог)
/admin/operators/:id/edit  → редагування (обмежені поля)
/admin/variations          → варіації, призначені мені SuperAdmin'ом
/admin/variations/:id      → деталь варіації + категорії + пул контенту
/admin/assignments         → центр призначень (хто що робить)
/admin/assignments/new     → майстер призначення роботи
/admin/analytics           → аналітика команди
/admin/finance             → баланси, запити на виведення, історія виплат
/admin/messages            → командний інбокс
/admin/notifications       → центр сповіщень
/admin/settings            → налаштування (профіль, безпека, сповіщення)
/admin/help                → довідка

5.1 Desktop

Структура як у CRM (sidebar + topbar), але «щільніша» — адмінка інформаційно насиченіша. Sidebar згрупований: Огляд (Dashboard, Analytics) · Команда (Operators з лічильником, Add Operator) · Робота (Variations, Assignments) · Фінанси (Finance з бейджем «3 pending») · Зв'язок (Messages, Notifications); внизу Settings, Help, профіль адміна.

Topbar: заголовок + breadcrumbs (глибша вкладеність), глобальний пошук Cmd/Ctrl+K (знайти оператора за іменем/email/ID), мова, тема, сповіщення, меню профілю.

5.2 Mobile / tablet

Desktop-first (адмін працює з комп'ютера). На планшеті/телефоні: sidebar → drawer, важкі таблиці → карткові списки, масові дії спрощені, аналітика — вертикальний стек графіків.

Має за 5 секунд відповісти на «як справи в команді і де втрутитись». Зверху вниз:

1. Заголовок + період: «Your team · Today» з перемикачем Today / 7d / 30d.
2. KPI-стрічка (4–5 карток): Active operators, Items processed (+тренд), Team earnings, Pending withdrawals, Avg trust score команди.
3. Attention / алерти — найважливіший блок; система сама піднімає: «trust score впав до Watch», «3 operators idle 3+ днів», «категорія Deepfake 95% done, running low», «2 withdrawal requests waiting». Кожен з CTA «Переглянути».
4. Team activity chart — items/earnings по команді (Recharts).
5. Top / bottom performers — рейтинг для ока адміна (операторам не видно).
6. Recent operators + Quick actions (Add operator / Assign work / Open messages).

Операційне ядро адмінки.

7.1 /admin/operators — список команди

• Таблиця (TanStack): аватар + ФІО, Operator ID, email, статус (Active/Idle/Restricted/Suspended), trust-рівень (рівень кольором, не число), Items, Earnings, Last active, дії (Open / Message / Assign / Suspend).
• Фільтри (статус, trust, активність, дата), пошук (ім'я/email/ID), сортування, масові дії (Assign variation / Send message / Export), експорт CSV/XLSX.

7.2 /admin/operators/new — створення

Форма: First / Last name*, email* (унікальний по системі), мова інтерфейсу, нікнейм/примітка, опційно — одразу призначити стартову варіацію.

7.3 /admin/operators/:id — картка (особова справа)

Вкладки:

• Overview: аватар, ФІО, нікнейм, ID, email, мова, дати; статус + trust-рівень; швидкі дії; міні-стата (lifetime items/earned, баланс, streak).
• Work / Assignments: призначені варіації (кожна раз — правило B), категорії, per-operator completion, історія — саме звідси система знає, що вже призначалось, і блокує повтор.
• Performance: графіки items/accuracy (honeypots)/швидкість/agreement; trust-рівень і динаміка з розбивкою по сигналах (адмін бачить, оператор — ні).
• Finance: баланс, історія нарахувань і виведень, статуси.
• Notes: внутрішні нотатки (оператор не бачить), таймлайн.
• Activity log: логіни з країною/IP/девайсом (з прапорцем), призначення, зміни статусу, виведення; нові гео-регіони підсвічуються.

Documents — приватне файлове сховище на оператора (медіа, PDF, скани, договори):

• Сховище: Cloudflare R2 (без egress-плати) або S3/MinIO, приватні bucket'и, публічного доступу немає в принципі.
• Шифрування: at-rest SSE на рівні bucket'а; для чутливих типів (ID/договори) — application-level envelope AES-256-GCM нашим ключем ще до завантаження (ключі в KMS, ротуються); in-transit тільки TLS.
• Доступ: лише presigned URLs з коротким TTL (~5 хв) після перевірки прав (row-level scoping). Постійних лінків не існує.
• Drag & drop з прогресом і прев'ю; валідація MIME + ліміт розміру + антивірусний скан (ClamAV у черзі BullMQ) перед доступністю; метадані (тег, дата, хто, розмір); аудит кожного перегляду/завантаження/видалення.
• Файли бачить тільки адмін оператора і SuperAdmin — сам оператор у CRM їх не бачить.
• Ретенція: автовидалення через 1 місяць — фоновий job стирає файли старші за 30 днів разом з об'єктом і ключем шифрування (незворотно, з записом в audit log). Мінімізує PII, спрощує GDPR-відповідність.

7.4 /admin/operators/:id/edit

Admin може змінити First/Last name (оператор сам — ні), нікнейм, дефолтну мову, статус (suspend/reactivate). Не може бачити/змінювати пароль — лише «Send password reset». Усі зміни в activity log.

7.5 Деактивація / suspend

Suspend — м'яке призупинення; оператор бачить «Your account has been suspended», баланс замороджується. Reactivate повертає доступ. Видалення — лише soft (archived), щоб зберегти історію і фінанси. Усі дії — з confirm-модалкою.

Варіації створює SuperAdmin і призначає їх адмінам. Admin бачить тут ті, що йому передали.

8.1 /admin/variations — мої варіації

Картки: назва, категорії з лічильниками (обсяг / зроблено), скільки операторів працює, загальний прогрес, статус (Active/Completed/Paused), дедлайн. Фільтри: активні / завершені / за дедлайном.

8.2 /admin/variations/:id — деталь

Заголовок + статус + прогрес. Список категорій; для кожної: назва + ставка ($/item — глобальна від SuperAdmin, адмін бачить, але не змінює), обсяг, зроблено/залишилось, призначені оператори, прогрес, «Assign this category». Загальна статистика: обсяг, темп, прогноз завершення. Кнопка «Assign work».

Найважливіша механіка «щоб нічого не поламалось». Тут живуть правила проти дублювання роботи.

9.1 /admin/assignments — центр призначень

Матриця «хто що робить»: рядки — оператори, колонки — активні варіації, у клітинках — персональний статус (не призначено / у роботі X% / завершено для цього оператора). Розгортання клітинки → розбивка по категоріях. Видно, хто перевантажений, хто вільний, де «діри». Швидка дія з клітинки: призначити / зняти.

9.2 /admin/assignments/new — майстер

9.3 Правила валідності (критично)

Наслідок для категорій: вибір категорій відбувається в межах цього єдиного призначення — адмін одразу відмічає всі потрібні. Додати категорію тому ж оператору по тій самій варіації згодом = редагування наявного assignment (новий дочірній запис), а не новий assignment. Другий assignment тієї ж варіації тому ж оператору — заблоковано.

9.3.1 Per-operator completion

Варіація «виконана» індивідуально для кожного оператора, а не глобально. Приклад: оператор A закрив усі свої категорії «Solana #023» → для нього Completed. Це не завершує варіацію для команди — її можна призначити B, C, D (для них вона свіжа). Оператору A повторно — не можна (правило B), іншим — скільки завгодно (у межах контенту в пулах). Статус завершення живе на рівні пари (operator × variation).

Це природно поєднується з cross-validation антифроду (Частина I, розділ 16): один контент навмисно проходить через кількох операторів для перехресної перевірки — тому варіація не «згорає» після першого виконавця.

9.3.2 Технічний захист

• Unique-constraint у БД на (operatorId, variationId) — навіть при гонитві паралельних запитів другий assignment відхиляється на рівні індексу, а не лише в UI.
• Статус завершення в записі assignment (assigned / in_progress / completed) — прив'язаний до (operator, variation), що й дає per-operator completion автоматично.
• Категорії — дочірні записи (assignment_categories) зі своїм прогресом; додавання = новий дочірній запис без порушення unique-constraint.

9.4 Додаткові захисти

Не можна призначити категорію без контенту («Awaiting refill» — кнопка неактивна) чи suspended-оператору; опційне попередження при N незавершених призначеннях; cross-validation overlap (різні оператори на одній варіації — дозволено; той самий двічі — ні).

• Період-перемикач (7d / 30d / 90d / custom). Team overview: items, earnings, active operators, avg trust, throughput.
• Per-operator breakdown (items, earnings, accuracy, швидкість, trust-динаміка); по варіаціях (темп, прогноз, вузькі місця); по категоріях (де продуктивніше, де більше помилок за honeypots).
• Quality signals (скільки у Watch/Restricted, тренди); фінансова аналітика (нараховано / виведено / у балансах, прогноз).
• Експорт будь-якого зрізу в CSV/XLSX; візуалізації (Recharts/Tremor, heatmap активності, донати).

• Team balances: оператори з Available / Pending / Lifetime.
• Withdrawals — повністю автоматичні через NOWPayments, без ручного апруву адміна. Зарахування миттєве, виведення дозволене після 7 днів + мінімум $1 245.50; далі система сама відправляє payout. Адмін наглядає і бачить статуси, а не апрувить.

Withdrawals history (усі стани, txid, мережа, сума), заморожені баланси (suspended/restricted з причиною), експорт звітів.

Інша сторона чату, який оператор бачить у CRM (Частина I, 10.8).

• Список діалогів — усі оператори, що писали, зверху непрочитані; вікно діалогу з історією, прикріпленнями; realtime через Socket.IO; пошук.
• Broadcast команді — надіслати кільком одразу («Нова варіація доступна»). Системні повідомлення інлайн. Бейджі непрочитаного.
• Обмеження: адмін спілкується тільки зі своїми операторами — чужої команди в інбоксі немає.

Фільтри: Team (idle / новий оператор), Work (варіація завершується, закінчився контент), Finance (запит на виведення, аномалія), Quality (оператор впав у Watch/Restricted), System. Realtime toast + центр (як у CRM), CTA-переходи на джерело.

• Cloudflare Access / Zero Trust перед застосунком (2.5); обов'язкове 2FA для всіх адмін-акаунтів.
• Row-level data scoping: Admin бачить у БД тільки свою команду — жоден запит не поверне чужих операторів.
• Усі чутливі дії (створення/suspend оператора, зміна даних) — у незмінний audit log. Документи — шифрування at-rest, приватні bucket'и, presigned URLs, аудит доступу.
• Rate-limiting і WAF жорсткіші за CRM; noindex, немає sitemap.
• JWT: access 15 хв + refresh 30 днів (той самий TTL, що й у операторів — додаткову чутливість покриваємо Cloudflare Access + обов'язковим 2FA, а не коротшим токеном).
• Гео-логування, не гео-фенсинг: країна кожного входу записується і підсвічується при аномалії, але доступ за країною не блокується. Жорсткий гео-фенсинг свідомо не впроваджуємо.

• Роль SuperAdmin повністю: створення варіацій, завантаження контенту, налаштування ставок, заведення адмінів, глобальна аналітика, системні параметри — окремий документ наступної ітерації.
• Схема БД у деталях і API-контракти — окремий технічний документ.
• Деталі документообігу/KYC і юридичної відповідності — окремо.
• Точна ML-механіка антифрод-сигналів — концептуально в Частині I (розділ 16), деталі — окремий тех-документ.

Закрито в цьому раунді:

SuperAdmin — власник усієї системи, не прив'язаний до команди. Головні відмінності від Admin:

Усе, що є в безпеці адмінки (Частина II, розділ 15), плюс посилення саме для SuperAdmin:

• Cloudflare Access / Zero Trust перед застосунком (як для всієї адмінки).
• Passkey / апаратний ключ (WebAuthn) — не просто TOTP, а фізичний фактор. Це найчутливіший акаунт у системі.
• Re-auth на найнебезпечніших діях — перед зміною ставок, конфіскацією балансу, видаленням варіації з контентом, зміною системних фінансових параметрів.
• Правило «дві пари очей» (опційно, off за замовчуванням). Оскільки SuperAdmin-ів двоє, критична дія одного може вимагати підтвердження другого (four-eyes). Вмикається в System Settings.
• Кожна дія SuperAdmin — у незмінному глобальному audit log (III-9). Refresh-TTL — той самий (30 днів); чутливість покривають фактори вище, а не коротший токен.

Базова модель даних, від якої залежить уся робота SuperAdmin. Два рівні:

2.1 Category Type — глобальний тип

Живе на рівні всієї системи, визначається один раз: назва («Photo Moderation»), іконка, ставка $/item (глобальна, однакова скрізь), набір дій оператора (Approve/Reject/Flag), гайдлайни (інструкція + приклади для workspace), конфіг honeypot (поле є, механізм вимкнено на старті — III-6). Ставка і правила задаються тут раз і успадковуються всюди.

2.2 Category Pool — екземпляр у варіації

При створенні варіації всередині для кожного типу створюється пул — контейнер під контент саме цієї варіації. «Photo Moderation в Solana #023» — окремий пул items, що успадкував ставку й правила від глобального типу.

2.3 Каталог: стартові 7 типів

Побудований на дослідженні аналогів (Sightengine, Hive, Chekkee, TaskUs, Toloka, Appen). Дії — проста класифікація кнопками (оплата за одиницю):

7 категорій — у діапазоні «5–8» з ТЗ. Кожна має власну ставку, дії та гайдлайни. Набір керований (III-4).

3.1 Майстер створення

Статуси: Draft — готується, операторам не видно; Active — у роботі, автопризначається всім адмінам, оператори отримують items; Paused — нова робота не видається, прогрес зберігається; Archived — прибрана з активних, лишається в історії/аналітиці.

3.2 Призначення варіацій адмінам

3.3 Керування

Список усіх варіацій з фільтрами; деталь — усі 7 пулів, обсяг, зроблено по всій системі, темп, прогноз. Дії: Pause / Resume / Archive / Delete (критична: re-auth + опційне «дві пари очей»). Дозаливка контенту в наявний пул (порожній пул → «Awaiting refill», після дозаливки робота відновлюється).

Розділ, доступний тільки SuperAdmin:

• CRUD типів (створити / редагувати / архівувати). Для кожного: назва, іконка, ставка $/item, набір дій, гайдлайни (текст + приклади), конфіг honeypot (поки неактивний).
• Зміна ставки діє на майбутні нарахування; минулі транзакції не чіпаються. Історія ставок логується (хто, коли, з якої на яку).
• Архівування типу не видаляє історичні дані — лише прибирає з нових варіацій.

5.1 Спосіб завантаження

Окремий плаский zip-архів медіа на кожну категорію. SuperAdmin відкриває варіацію → бачить 7 пустих категорій → у кожну окремо завантажує zip (плаский набір фото/відео) → пайплайн наповнює пул. Одна категорія = один архів; ніяких вкладених папок.

5.2 Пайплайн (асинхронно, BullMQ)

1. Розпакування і валідація — MIME, розмір, цілісність; биті файли відсіюються зі звітом.
2. Зберігання — Cloudflare R2 (приватне, presigned доступ).
3. Генерація прев'ю / тумбнейлів для швидкого рендеру в workspace.
4. Дедуплікація — перцептивний хеш, щоб контент не потрапив у пул двічі.
5. [Місце під honeypot-ін'єкцію] — крок передбачено, але на старті вимкнено (III-6).
6. Наповнення пулу — валідні унікальні items стають доступними операторам.

Підсумок для SuperAdmin: напр. «482 / 500 processed, 15 duplicates skipped, 3 invalid files». Статус кожного архіву в реальному часі, історія завантажень по пулу, можливість дозалити ще архів (поповнення).

SuperAdmin налаштовує «ручки» движка довіри (Trust Score, Частина I розділ 16):

• Ваги сигналів — honeypot, cross-validation, time-per-item, behavioral, answer distribution, device/IP, payout velocity.
• Пороги станів Trust Score (Trusted / Normal / Watch / Restricted / Suspended) і тривалість probation.
• Реакції системи на кожен стан (затримки, блокування виведення).
• Ручний розбір ескалацій — найтяжчі кейси; тут же рішення про конфіскацію балансу забаненого (за ToS) — критична дія з re-auth.

Дзеркало того, як Admin створює операторів (Частина II, 7.2):

7.1 Створення

Форма: ім'я, прізвище, email, нікнейм (оператори бачать ФІО + нікнейм). Криптографічно стійкий тимчасовий пароль, mustChangePassword + обов'язкове 2FA при першому вході. Лист-запрошення на email (логін, тимчасовий пароль, лінк на admin-домен). Пароль показується SuperAdmin'у один раз (Copy), далі — тільки хеш.

7.2 Керування

• Список адмінів з показниками: розмір команди, продуктивність, оборот, остання активність. Картка: команда операторів, статистика, лог дій, «особова справа».
• Дії: Suspend / Reactivate, Reset password, редагування. Reassignment операторів між адмінами (з логуванням; оператор бачить одного поточного адміна).
• Видалення — тільки soft (archived). Усі активні варіації автоматично доступні кожному адміну (III-3.2).

8.1 Dashboard SuperAdmin

Огляд усієї системи: оператори/адміни онлайн і активні сьогодні; items/день по всій системі й тренди; оборот (нараховано / виведено / у балансах); custody-баланс NOWPayments (критичний показник ліквідності); топ- і проблемні команди; системні алерти (аномалії, низька ліквідність, сплески виведень).

8.2 Фінанси

• Усі виплати всіх команд зі статусами (машина станів, Частина II розділ 11), txid, мережа, сума.
• Custody-баланс і прогноз: чи вистачає коштів на очікувані виплати.
• Комісія/податок — фіксована сума (не відсоток); точну цифру SuperAdmin виставить пізніше (поле в System Settings). Утримується з виведення оператора.
• Експорт звітів (CSV/XLSX) для бухгалтерії.

8.3 Аналітика

Зрізи по адмінах, командах, варіаціях, категоріях, операторах — продуктивність, якість (антифрод-сигнали), гроші, темпи. Візуалізації (Recharts/Tremor), heatmap, експорти.

• Усі чутливі дії всіх ролей (SuperAdmin, Admin, система): створення/зміна/видалення варіацій, зміна ставок, створення адмінів/операторів, suspend, виведення, конфіскації, зміни системних налаштувань.
• Immutable (append-only) — записи не редагуються і не видаляються. Кожен: хто, що, коли, з якого IP/девайсу, деталі до/після.
• Пошук, фільтри, експорт. Юридичний і безпековий фундамент — довести, хто що зробив.

Єдиний розділ, доступний тільки SuperAdmin — параметри, які більше ніхто не чіпає:

Понад те, що бачить Admin, роль SuperAdmin відмикає:

/admin/superadmin/dashboard    → глобальний дашборд
/admin/variations              → усі варіації + створення
/admin/variations/new          → майстер створення варіації
/admin/variations/:id/upload   → завантаження контенту в пули
/admin/category-types          → глобальний каталог категорій (CRUD, ставки)
/admin/admins                  → керування адмінами
/admin/admins/new              → створення адміна
/admin/admins/:id              → картка адміна
/admin/finance/global          → глобальні фінанси + custody-баланс
/admin/analytics/global        → глобальна аналітика
/admin/antifraud               → конфіг Trust Score + ескалації
/admin/audit-log               → глобальний незмінний журнал
/admin/system-settings         → системні параметри

Звичайні розділи адмінки (operators, messages, notifications) SuperAdmin теж бачить, але в глобальному охопленні, не обмеженому однією командою.

• Impersonation / «View as» (вхід очима адміна/оператора для дебагу) — свідомо поза MVP; потребує суворого логування.
• Honeypots / gold set editor — відкладено (III-6), місце в архітектурі лишено.
• API-інтеграція автозаливки контенту з крипто-дейтинг платформи — на майбутнє; на старті ручне завантаження архівами.
• Схема БД у деталях і API-контракти — окремий технічний документ.