# Коллаборация CFD Emulation

## Момент подключения
- У пользователя нет текущей задачи и все лимиты заняты;
- Пользователь не может продолжить работу над текущей задачей так как все лимиты заняты;
- Текущий пользователь имеет право участвовать в коллаборации;
- Пользователь имеет право работать в колонке;
- Ответственный имеет право работать в режиме коллаборации;
- Пользователь может участвовать в одной коллаборации;
- Приоритет в выборе задачи согласно алгоритму вытягивания;
- До конца задачи осталось топлива > 1(2?) итерации ответсвенного.
## Момент выхода из коллаборации
- На каждой итерации проверяем не освободились ли wip-лимиты (запускаем режим проверки лимитов для текущих задач);
- Если текущих задач нет и нет возможности взять новую, то продолжаем работу;
- При смене колонки, 2 пользователь проверяет wip-лимиты и право находится в новой колонке;
- Задача завершена / потрачено все топливо.
## Определяем кто может подключаться
В первом релизе могут подключаться все выбранные пользователи; ручная настройка в следующем релизе вместе с возможностью выбора колонок/лейнов для пользователя.
Сейчас достаточно будет делать проверку может ли пользователь участвовать в коллаборации, которая всегда возвращает `true`.
## Рассчет прожигания топлива
Подключенный пользователь прожигает топливо задачи на 50% менее эффективно. То есть, когда работают 2 пользователя над задачей, то скорость прожигания топлива будет составлять 150%.
## Общий алгоритм
- Проверяем wip-лимиты для своих задач, возможность взять новую: если лимиты свободны, то обычная логика, иначе: включается режим коллаборации;

__Для режима коллабрации:__
- Сортируем карточки в работе (state 2) по алгоритму вытягивания (ближе к завершению);
- Проверяем может ли текущий работник работать в коллаборации, есть ли право работать в текущей колонке, подключение к работе даст эффект (верхний лимит на скорость сжигания топлива) -- да ? подключаемся : пропускаем ход;
- На каждой итерации проверяем условие выхода.

## Вопросы
> Если задача почти завершена, то помочь завершить даже если лимиты для своих задач освободились?

Например, если задача завершена на 75-80%
> Кол-во одновременных коллабораций для пользователя

1
> Сколько пользователей может участвовать в коллаборации?

По идее, не должно быть лимита на кол-во участников. Если объемную задачу можно распараллелить, то лучше создавать отдельные карточки (не будет штрафов на сжигание топлива).

> Штрафы на сжигание топлива для 3+ участника

Можно установить верхний лимит сжигания топлива по карточке (например, 300%) или уменьшаем эффективность сжигания для каждого нового участника. Т.о., с определенного момента нет смысла подключать нового участника (нужно лучше декомпозировать исходную объемную задачу).

> (следующий релиз) Пользователь _А_ не может работать в режиме коллаборации, а пользователь _Б_ может. У пользователя _А_ в работе находится объемная карточка. Может ли пользователь _Б_ подключиться к работе?

НЕТ?

> Возможно следует немного поменять архитектуру `CardWipLimitAnalyser`

Верхний уровень - координатор/главный менеджер
инициализирует все классы-провайдеры на основе `analyseData, startDayColumnFill, config`
отвечает только за переключение дней и итераций внутри дня
При смене итерации или дня дергает cardPool и WorkerManager

WorkerManager оперделяет кого и в какой послдеовательности вызывать `fillWorkers и sortWhoMoreFreely`

Каждому Worker должны быть доступны инстансы всех менеджеров (провайдер в конструктор, который может вернуть нужный инстанс)
Вся логика должна быть в Worker - сам проверяет лимиты, сам выбирает следующюю карточку, оставить ли работу над текущей, имеет ли право двигать, переходить ли в режим коллаборации
в следующих релизах еще будет инициализация воркера по правам (куда может двигать/ может ли участвовать в коллаборации, ...)

кмк, будет удобнее следить за логикой алгоритма, так как все решения будут в методе run/burnIteration для Worker'а