task-service

TaskService

Спільне зберігання та читання тасків. Умови створення, пріоритети й локальний active pool належать Task Factory в Electron; запис виконується через Electron Gateway.

Поточний lifecycle

1. Family task runner або Golden Electron формує таск.
2. Таск записується в active collection своєї Family.
3. Prime, Chathouse та Udate додатково тримають active pool у пам’яті server runner і віддають його у workspace через socket. У Golden active pool тримає Electron.
4. Після відповіді таск отримує answer; після заміни, завершення таймера, offline або іншого закриття — canceled з причиною.
5. Repository конвертує повний таск у скорочений saved task, визначає денний документ за operator + supervisor + день створення і пушить його в *_action_operators.tasks[].
6. Початковий документ видаляється з active collection. Тому *_task містить лише активні таски й часто є порожньою.

Hard delete видаляє active task без запису в історію. Answer і cancel, навпаки, повинні залишити saved task у *_action_operators.

Звідки створюються зараз

Family	Джерело
Golden	Electron викликає electron-api/task/create; update, answer, cancel і delete також ідуть через Electron API Golden
Prime	PrimeTaskRunner: online, unanswered chat/mail, socket, open limits, favorites та окреме створення VIP chat
Chathouse	TaskRunner: online, unanswered, socket, need-to-write mail і post-chat mail
Udate	UdateTaskRunner: online, unanswered, socket, favorites та інші поточні перевірки Udate

Тимчасові UI-сигнали на кшталт typing не повинні потрапляти в постійну історію тасків.

Де дані використовуються зараз

Дані	Звідки читаються	Використання
Active tasks	golden_task, prime_task, chathouse_tasks, udate-task	Відновлення active pool після логіну/reconnect і поточний workspace оператора
Completed tasks	*_action_operators.tasks[]	Історія виконаних тасків у workspace
Task history TU + RU	*_action_operators.tasks[]	Відновлення follow-up-станів і захист від повторного створення
Task metrics	*_action_operators.tasks[]	Кількість створених/виконаних, on-time/out-of-time, швидкість відповіді
Task Dashboard	*_action_operators.tasks[]	Денна й періодна агрегація по operator, supervisor і типах тасків
Golden chat/mail history	golden_action_operators.tasks[]	Прив’язка виконаного таска до відповідного повідомлення або листа
Prime VIP chat	prime_task + prime_action_operators.tasks[]	Відновлення активного VIP-таска та останніх закриттів у CreatingChatScheduler

*_action_operators одночасно зберігає таски, агрегати ручних/автоматичних відправлень та інші operator-дані. Тому Task history зараз залежить від чужої сутності й читається через масиви денних документів.

Що спрощуємо

1. Electron Task Factory один раз реалізує правила active pool, пріоритетів, create, answer, cancel і remove для всіх Family.
2. Electron Gateway приймає task-команди та записує Task у спільну collection.
3. Create додає один документ; answer або cancel атомарно заповнює result у тому самому документі.
4. TaskService читає ту саму collection для frontend, startup data, статистики, дашборду та метрик.
5. *_action_operators.tasks[] і golden_task_archive більше не використовуються для нових тасків.
6. Family-сервіси не мають власних Task repositories або конвертації в saved task.

Операції

№	Операція	Хто викликає	Результат
1	Create	Electron Task Factory → Gateway	Idempotent insert активного Task
2	Answer	Electron Task Factory → Gateway	result.type = answered
3	Cancel	Electron Task Factory → Gateway	result.type = canceled з причиною
4	Remove	Electron Task Factory → Gateway	Видалення active Task, який не повинен увійти в історію
5	Active list	Electron startup/recovery	Активні таски operator/TU
6	History	family-application-api та Electron startup	Закриті таски за operator, TU + RU або період

Під час міграції кожен поточний читач *_action_operators.tasks[] переводиться на TaskService. Після цього поле tasks можна прибрати з operator action documents окремою міграцією.