Робоче місце,
у якому видно
роботу і гроші.

На стороні оператора 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.»
• Фінал: «🎉 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.

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

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

• 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. Із попереднього списку закрито:

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