Воркспейс — план
План єдиного воркспейсу для дискусії та проектування. Механіка логік — у Unification.
✅ — по ідеї очевидно; 💬 — на дискусію.
Стан рішень
| Блок | Стан |
|---|---|
| Запуск сесії | ✅ |
| Онлайн TU (тримання, перевірка, реконект) | ✅ |
| Дії оператора + збереження результатів | ✅ |
| Медіа-галерея | ✅ |
| Блок / видалення RU | ✅ |
| Спільні сервіси (live-view, перекладач, нотатки) | ✅ |
| Унікальні логіки | ✅ |
| Профіль RU | ✅ |
| Таски: назви, типи, таймери, створення | 💬 |
| Сендери (Chathouse + Prime) + блек-лісти | 💬 |
| Фаворити + чат/мейл-історія | ✅ |
| Фрілоадери | ✅ |
| Технічне (закласти при проектуванні) | 💬 |
Запуск сесії
- Логін оператора → конект нашого сокета. Тут же в усіх проектах: перевірка версії програми і синхронізація часу зі світовим.
- Конект/реконект сокета завжди повертає актуальний список TU зі статусами. На цьому ж етапі — перевірка зміни (робочих годин) оператора і перевірки допуску TU (свої в кожному проекті).
- Стартові дані — одним запитом: спільне ядро + свої набори по проектах.
- Логін TU на сайт + сокет по TU — механіка своя в кожного сайту (див. Unification).
- Пре-логіки — вирішили прибрати: окремого стартового етапу (фаворити на сайті, айсбрейкери) не буде.
- Старт основних логік (онлайн TU, дії оператора, таски, сендери, оновлення фаворитів/історії). Чек-ліст статусів стартових логік показується оператору в усіх проектах.
Дисконект від нашого сервера: авто-реконект; мережа недоступна довше хвилини → закриття програми; вхід іншого оператора на ту саму анкету → примусове відключення анкети.
TODO: прописати план дій і ситуацій при логіні (нотифікація тімліду в Telegram).
Онлайн TU
Єдина петля в кожному проекті:
- Тримання онлайн — механізм свій у кожного сайту (Golden — активний пінг; Chathouse — батч-пінг адмін-апі; Prime — сокет-конект + регулярні запити).
- Перевірка — раз на ~60 с питаємо апі, чи TU онлайн; скрізь є списковий/батч-запит — використовуємо його, не по одній TU.
- Реконект — TU офлайн → перезапуск логіки TU цілком, не лише сокета.
- Фіксація часу онлайну TU.
Дії оператора + збереження результатів
- Підрахунок дій оператора по типах і його онлайну; кік-закриття програми при неактивності 10 хв; оновлення останнього онлайну в редіс.
- Результати логік зберігаються на наш сервер батчем: результати сендерів, дії та онлайн оператора, періоди стрімів, перегляди профілів, критичні логи.
Медіа-галерея
- Один інтерфейс галереї з двома формами списку: «все одразу» і «курсором» — залежить від сайту.
- Чат і лист — контексти однієї галереї; у Golden це два окремі пули під тим самим інтерфейсом.
- Набір типів медіа свій по проектах (ядро — фото/відео; аудіо, стікери, пости — де є).
- Відправка листа мусить підтримувати режим «медіа обов’язкове» (Chathouse блокує лист без медіа при квоті).
Рішення — медіа
На воркспейсі медіа тільки отримуємо: фото та листи, доступні для відправки, і бачимо seen/sent. Редагування і модерація медіа переходять на сайт.
Блок / видалення RU
- Блок — у кожного сайту свій сигнал (Golden — готовий список id, хто заблокував; Prime — батч-перевірка блокувань + сокет-подія; Chathouse — прапорець у діалозі) → спільна реакція: помітити фаворита, зняти таски пари, виключити з сендера.
- Видалення профілю RU — прямого сигналу немає в жодного сайту; визначаємо непрямо (помилка відправки, зникнення зі списків), реакція — як на блок.
- Ведення списків блокувань — оновлення інфо у фаворитах.
Спільні сервіси
- Тімлід live-view — тімлід бачить стан воркспейсу оператора в реальному часі (наш сокет).
- Перекладач — через наш сервер (DeepL/AI), однаковий усюди.
- Нотатки (+ AI-нотатки) — спільна колекція для всіх проектів, отримання по курсору разом з AI-нотатками.
- Інвайти для сендерів — створення і вибір; повністю наше апі. (Хто створює — питання в блоці «Сендери».)
Профіль RU
Профіль RU (id, ім’я, аватар, вік) потрібен скрізь: картка таска, діалог, колонка фаворитів. Сайти віддають його дуже нерівно: Chathouse несе повний профіль прямо в списку діалогів і в сокет-події; Prime дає лише id — профіль тягнеться окремим батч-запитом; Golden у діалогах/подіях профілю не дає — є лише точковий запит по id і збирання списку онлайн-RU, тому профілі тримаються у власному сторі. Критичний випадок — перший контакт: RU написав уперше, а картку вже треба показати.
Рішення
Рішення — профілі RU
Поки без стору — робимо, як буде логічно і зручно.
Таски 💬
Ціль дискусії: зафіксувати назви, типи, таймери і способи створення єдиного набору тасків. Колонка «Рішення» заповнюється на обговоренні.
Каркас (зафіксовано): скрол-сервіс обходить діалоги (онлайн / unanswered / фаворити) і віддає потрібні → таск-сервіс робить з діалогу таск. Три механізми створення: сокет (реалтайм-подія) · скрол (інтервальний обхід) · статистика (де є). Golden списку діалогів не має — обходить наш список фаворитів; Prime не має статистики — мейл-таски створюються сканом. Деталі проходів (інтервали, глибина, умови) — Unification.
Рішення — набір тасків
Рішення — набір тасків
Цільовий набір (назви, таймери, умови створення, VIP-приставка, сортування по пріоритету) і реалізація по проектах з наявним апі — Tasks.
Типи і способи створення (зараз)
| Тип | Golden | Chathouse | Prime | Рішення |
|---|---|---|---|---|
| Unanswered чат | сокет + скрол | сокет + скрол | сокет + скрол | |
| Unanswered мейл | статистика | сокет + скрол | сокет + скрол | |
| NeedToWrite чат | скрол | сокет + скрол | скрол (×2) | |
| NeedToWrite мейл | статистика | сокет + скрол + статистика | — (зводиться) | |
| OpenLimits | — | скрол | сокет + скрол | |
| OpenLimits VIP - chat request | — | — | планувальник (наш DB) | |
| Like | сокет | сокет + скрол | сокет + скрол | |
| LikeMail | — | — | скрол | |
| Typing | — | сокет | — |
ActiveChat (Golden) — не окремий тип: платний чат лише змінює заголовок Unanswered чат. UnansweredEmail (Golden) — окремий клієнт-email канал, не листи сайту; описується окремо.
NeedToWrite — варіанти створення (зараз)
| Варіант | Суть | Golden | Chathouse | Prime |
|---|---|---|---|---|
| Пройшов час — чат | RU онлайн, останнє від TU, є чат-ліміти → таск у чат | онлайн-фаворит, останнє від TU >10 хв | фаворит на сайті (saved), останнє від TU >1 год | фаворит на сайті (bookmark), останнє від TU ≥2 год |
| Пройшов час — лист | TU писала останньою, лист давно не йшов → таск у лист | фаворит онлайн, лист >12 год або бонус | той самий прохід: чат-лімітів нема, є мейл-ліміти, наш лист >12 год | фаворит на сайті, RU офлайн, останнє від TU і останній лист >12–16 год, є ліміти |
| Статистика | RU оплатив/прочитав наш лист → лист | EmailRead / OpenAttach | inmail_read | — |
| Післячатове | платний чат закінчився, ≥10 хв без відповіді → лист | — | PostChatMail | — |
Таймери (зараз)
| Тип | Колір | Golden | Chathouse | Prime | Рішення |
|---|---|---|---|---|---|
| UnansweredMessage | жовтий | 50 с | 120 с | 120 с | |
| UnansweredMail | жовтий | 600 с* | 900 с | 900 с | |
| NeedToWriteMessage | зелений | 120 с | 180 с | 180 с | |
| NeedToWriteMail | зелений | 600 с | 1200 с | — | |
| Like | синій | 50 с | 300 с | 300 с | |
| LikeMail | синій | — | — | 300 с | |
| LimitsAreOpened | червоний | — | 300 с | 300 с | |
| LimitsAreOpened VIP | червоний | — | — | 300 с | |
| Typing | фіолетовий | — | без таймера | — | |
| UnansweredEmail | жовтий | 3600 с | — | — |
Питання до дискусії
Назви, таймери й умови створення — вирішено, див. Tasks.
Питання 1 — пріоритети тасків
Прописати чітко пріоритети: скільки тасків одночасно на пару TU+RU (один чатовий + один мейловий?) і який тип над яким має пріоритет.
Зараз: Golden — Unanswered/ActiveChat витісняє NeedToWrite/Like, UnansweredMail витісняє NeedToWriteMail; Chathouse — Unanswered витісняє NeedToWrite, мейл-тасків ≤2 на оператора; Prime — новий таск пари витісняє старий.
Питання 2 — закриття тасків
Прописати поведінку видалення/закриття таска: оператор вийшов з роботи, не закривши таски · перевірка онлайну каже, що RU/TU офлайн · хтось когось заблокував.
Як зараз по проектах — Current State («Закриття тасків»).
Інші питання:
- Інтервали й глибина скрол-проходів: єдині числа чи свої під кожне апі.
- Перевірка онлайну RU: Chathouse окремого апі не має (онлайн видно лише в списку діалогів) — чим замінимо.
Сендери 💬
Ціль дискусії: звести спільну логіку сендера Chathouse + Prime з таблицею параметрів і оновити блек-лісти сендерів. Golden — окреме питання: його чат/мейл-сендери (FAV/NEW, NAF/FANM) зводимо сюди чи лишаємо окремою логікою (описується окремо).
Спільна логіка (зафіксовано, Prime ≈ Chathouse):
- Сендер не самостійний: кого слати, вирішує скан онлайн-діалогів.
- Бере діалог, де останнє від TU, старше порогу, RU онлайн, з лімітами, не заблокований і не в блек-лісті.
- Спершу чат-інвайт; якщо чат-шаблонів чи лімітів нема — мейл.
- Ланцюжок інвайтів по черзі, без повторів тому самому RU; повторна відправка парі TU+RU — не раніше затримки.
- Блек-лист перевіряється перед самою відправкою.
- Побічне: історія відправок, лічильники шаблонів і автодій, помітка «шаблони закінчились».
Параметри (зараз)
| Параметр | Chathouse | Prime | Рішення |
|---|---|---|---|
| Затримка чат | 1 год | 2 год | |
| Затримка мейл | 6 год | 12 год | |
| Додаткові дослання | ≤2 (текст/стікер/фото), з перевіркою доставки | нема | |
| Кап на одного RU | ≤5 TU за хвилину | нема | |
| Low-credit RU | окремий мейл-шаблон (spend 0–20); фото — 20+ | нема | |
| Мова інвайтів | лише латиниця | — | |
| Медіа в мейлі | фото (крім low-credit) | ≤10 фото + ≤10 відео |
Питання до дискусії
Питання 3 — спільна логіка сендера
Звести спільну логіку роботи сендера; параметри по проектах — заповнити колонку «Рішення» в таблиці.
Рішення — інвайти
Оператори можуть створювати інвайти на модерацію тімліду й бачити активні інвайти в сендері. Додавання, видалення, зміна порядку — оновлюється в Electron.
Рішення — онлайн-прохід: таск чи сендер
Зелені (Follow-up) таски — завжди тільки активним фаворитам онлайн. Не-фаворити з онлайн-проходу йдуть у сендер.
Блек-лісти (сендерні)
Зараз одна суть розмазана по різних сховищах і назвах. Заготовка — три типи на пару TU+RU + опційний глобальний:
- (a) RU заблокував TU — по ідеї треба зберігати у фаворитах, але голден дає апі всіх РЮ.
- (b) TU/оператор заблокував RU — ставиться вручну, але тут на чатхаусі цей список на фаворитах, а на голдені є і це блокування РЮ і окремі блек листи сендерів.
- (c) сендер-виключення — службовий список; ставиться автоматично при помилках відправки.
- Глобальний по RU — наповнюється вручну, адмін-інструмент (зараз лише Prime).
Питання 4 — логіка блек-листів
Спростити логіку блек-листів: прописати, які точно будуть листи, як туди потрапляють id (автоматично чи вручну) і на які сендери вони впливатимуть.
Рішення — white-list
Чат-сендер Golden (фаворити) і сендери Prime/Chathouse працюють по списку white-list. У white-list потрапляють усі неактивні фаворити (від 7 днів до 3 місяців) та активні з маленькою сумою. Вручну додати чи зняти можна тільки активного фаворита з маленьким глобальним балансом. Ігнор від сендерів винести в глобальні фаворити.
Інші питання:
- Єдині назви (зараз (b) = blockedByTU у Golden = isBlackList у Chathouse/Prime).
- Перевірити: чи не потрапляють id у блек-лісти мейл-сендера автоматично.
Фаворити + чат/мейл-історія
Ціль дискусії: прийняти рішення, звідки береться список фаворитів і чим наповнюється колонка фаворитів (останнє повідомлення, чат/мейл-історія).
Що дає сайт: Prime/Chathouse мають апі фаворитів, профілів і останнього повідомлення в діалозі; Golden не має нічого з цього — фаворити зі статистики, все тримається в нас.
Рішення
Рішення — фаворити
Фаворитів рахуємо й оновлюємо «під капотом» у нас; колонку рендеримо з апі сайту.
Рішення — чат-історія
Chathouse/Prime — з апі, як було. Golden — фейкова чат-історія: зберігаємо історію в локальній базі і при логіні підтягуємо.
Інші питання:
- Єдиний критерій «фаворит» / «активний фаворит»: платні дії за 7 днів (Golden/Chathouse) та сумарний поріг та дата платних дій (Prime).
- Тут треба ще подумати як ми можемо комбінувати оновлення онлайну та РЮ які заблокували ТЮ
Фрілоадери
Зараз одна назва — два різні концепти; у Golden концепту нема взагалі.
Як є
| Chathouse | Prime | |
|---|---|---|
| Що означає | RU платить лише бонусами, реальних грошей не було | RU мало платив: менше 11 платних дій сумарно по всіх TU |
| Як попадає | автоматично — перерахунок платежів RU щодня/щотижня | автоматично — рахується на льоту з профіту RU |
| Як зникає | одразу після першої оплати реальними грошима | автоматично при ≥11 платних дій |
| На що впливає | виключення з мейл-тасків + бейдж в UI (сендер не чіпає) | лише бейдж в UI |
Рішення
Рішення — фрілоадери
Критерій: платить лише бонусними кредитами (Chathouse) або поріг 11 платних дій (Prime). Ставиться і знімається автоматично. Golden: додаємо у фаворити бонусних RU (сума 0), працюють як звичайні фаворити. Ідею «не створюємо Follow-up таски + автоматично потрапляє в сендер» — поки ігноруємо.
Унікальні логіки
Фічі окремих проектів — лишаються в єдиному воркспейсі окремими модулями:
- Створення діалогів (Prime) — планувальник VIP: для TU з правом створення чату і вільними лімітами бере кандидата з пулу якісних RU → таск оператору «написати першим»; не частіше 1 VIP / 2 год на TU; коли тасків нема — сигнал «можна створити чат». Chathouse: проактивного нема, порожні заготовки діалогів дають таск-нагадування. Golden: нема.
- Ньюзфід (Prime) — оператор вручну створює і публікує пости від імені TU; видно, яка TU сьогодні ще не постила; автопостингу нема. Реакції RU на пост стають звичайними тасками (лайк → Like, відповідь → Unanswered).
- Стрім камер TU (Golden) — трансляція анкети + фіксація інтервалів трансляцій.
- Перегляди профілю (Golden) — збереження, хто дивився анкету.
- Клієнт-email канал (Golden) — зовнішні поштові акаунти TU: скан інбокса → таск UnansweredEmail; окремий канал, не листи сайту.
Технічне — закласти при проектуванні
Не фічі воркспейсу, а інженерні речі, які треба закласти в каркас одразу:
- Анти-дудос API — обмеження частоти й черги запитів.
- Логування запитів та помилок.
Питання (обговорити):
- Кешування запитів діалогів (як-от чат-історія) — щоб зменшити кількість повторних запитів.
Кандидати (на розгляд, не рішення):
- Єдина обробка помилок партнерського API — класифікація в одному місці: 401 → релогін, «заблокований» → реакція на блок, 5xx/таймаут → ретрай з бекофом; щоб кожна логіка не вигадувала свою.
- Фіча-флаги з сервера — вимкнути окрему логіку (сендер, скрол, таски) без релізу, коли вона зійшла з розуму.
- Метрики роботи — лічильники запитів по API, тайминги логік і черг → на наш сервер; видно, хто дудосить і що гальмує.
- Захист від подвійного запуску інтервальних логік — єдиний патерн (isBusy/watchdog) замість свого в кожній.
- Захист від подвійної відправки — ретрай не має відправити повідомлення/інвайт двічі.
- Коректне закриття програми — дослати data-sync батч і закрити таски перед виходом.
- Дебаг-знімок стану воркспейсу — зібрати стан одним кліком для розбору інцидентів тімлідом/саппортом.
- Пісочний режим — запуск логік без реальних відправок, для тестування.
Зв’язки
- Unification — механіка кожної логіки.
- Current State — as-is по проектах.
- Server Coupling — архітектура переносу (тут свідомо не чіпаємо).