алгоритм распределения. Бизнес-задача: распределить взаимную проверку студентами заданий. Все на SQL. На Supabase будет выполняться (есть особенности). На вход функции: sprint_strapi_document_id (идентификатор учебной недели) Ожидаемый результат: По 3 заданиям, привязанным к учебной неделе проведены распределения студентов с соблюдением ряда условий. Подробнее: ЧТО ДЕЛАЕТ ГЕНЕРАТОР (ПРИМЕРНО) 1. Старт Получает идентификатор спринта и режим работы («затереть всё» или «дописать недостающее»). Спринт = учебная неделя. 2. Очистка (по желанию) Если запрошен «затереть всё» — удаляет из результата всё, что относится к этому спринту, и фиксирует, сколько строк исчезло. 3. Снимок входных данных Собирает четыре набора сведений, без хранения в БД: 1. перечень дуэлей (2 пользователя делают одну задачу) спринта и их тип (тренировочная / боевые); 2. список разрешённых участников (не уволены, из нужного потока); 3. для каждой сыгранной пары — самые свежие ответы обоих игроков — у каждого ответа есть pair_id; 4. из предыдущего пункта формирует сами пары: «идентификатор пары + оба игрока». 4. Рассчитывает квоты Для каждого допущенного пользователя считает: сколько он сыграл ответов × 3 — столько он обязан проверить. У кого получилось 0 — тот сразу «вне игры» (ему нечего проверять, он никому не нужен). 5. Готовит «кольца» – два воображаемых циклических списка Первое кольцо: шесть «слотов» подряд для каждого будущего рецензента. Второе кольцо: шесть «слотов» подряд для каждой пары, которую надо проверять. 6. Базовый round-robin 1. Для тренировочных дуэлей всем парам заранее выбирает «сдвиг» — на сколько позиций провернуть кольцо рецензентов. Для боевых дуэлей сдвиг 0. 2. «Накладывает» кольцо рецензентов на кольцо пар с учётом сдвига и тем самым назначает первых шесть рецензентов каждой паре, игнорируя случаи «рецензент = игрок пары». Получается черновой чертёж назначений. 3. Из квоты каждого назначенного рецензента вычитает израсходованные слоты. 7. Дозакрывает пары, где оказалось меньше 6 рецензентов Пока остаются «дыры»: • выбирает кандидатов с ещё не обнулённым лимитом, которых нет в данной паре и которые не столкнутся с ограничениями; • назначает их, строго не превышая «осталось проверить» ни у пары, ни у кандидата; • обновляет, сколько ещё нужно и какие квоты остались. 8. Сохраняет результат Каждое назначение дублирует на обе записи пары (чтобы вышло ровно 12 строк на пару: 6 рецензентов × 2 игрока). Старые строки не дублируются — если они уже существуют, пропускает. 9. Проверяет себя Есть две жёсткие проверки — если хотя бы одна не пройдена, всё откатывается и бросается исключение: 1. у каждой пары должно быть ровно 6 назначений, иначе фиксируется список «неполных» пар (попадают в лог) и генератор падает; 2. ни у одного рецензента фактическое число назначений не может превышать рассчитанную квоту; нарушители фиксируются в отдельный список и тоже приводят к падению. 10. Формирует отчёт Возвращает JSON: • уникальный идентификатор запуска; • статус «OK» или «ERROR»; • массив шагов-сообщений в хронологическом порядке: сколько строк стерто, сколько сохранено, попали ли пары в «неполные», есть ли «перебранные» квоты, прошла ли финальная валидация. Полный набор логических «баз»,-которыми оперирует генератор (ниже — только смысловая структура: названия полей и связь с алгоритмом; никаких SQL-таблиц или DDL-врезок) 1. Пользователи • user_id – внутренний идентификатор участника • stream_id – учебный поток (курс) • team_id – команда внутри потока • dismissed_at – дата отчисления / увольнения или пусто Зачем нужно → позволяет • убрать выбывших, • узнать команду игрока для правил FULL-CONTACT, • связать участника с потоком спринта. 2. Страйки • user_id – кто получил штраф • sprint_id – за какой спринт штраф Зачем нужно → если есть запись по текущему спринту, пользователь не допускается к проверкам. 3. Потоки и Спринты • stream_id ↔ sprint_id – один поток может иметь несколько спринтов Зачем нужно → определить, каких пользователей считать «своими» для данного спринта. 4. Команды • team_id – идентификатор команды • stream_id – чей поток Зачем нужно → различать «свою» и «чужую» команду в боевых дуэлях. 5. Дуэли • duel_id – внутренняя ссылка в ответах • sprint_id – к какому спринту относится • type – TRAINING или FULL-CONTACT Зачем нужно → отфильтровать дуэли спринта и понять, нужны ли правила баланса команд. 6. Ответы на дуэли • pair_id – уникальный идентификатор пары игроков • user_id – автор конкретного ответа • rival_id – соперник автора • duel_id – какая дуэль • hash – общий «ключ партии» (одинаков у двух строк пары) • created_at – когда отправлен ответ Зачем нужно → • брать самый свежий ответ каждого игрока в паре, • посчитать, сколько ответов сыграл каждый пользователь → сколько рецензий он обязан выдать (квота = 3 × ответы), • сформировать список всех пар «hash + duel». 7. Назначения на проверку (целевая таблица) • reviewer_id – кто будет проверять • duel_id – дуэль пары • user_id – чей ответ проверяется • hash – «ключ партии» (чтобы различать пары) Зачем нужно → конечный результат работы генератора; строка уникальна в сочетании (reviewer_id, hash, duel_id). 8. Внутренние счётчики-выкладки генератора. Что нужно ещё: поддержка и сопровождение, разработать документацию. Если сработаемся — есть много задач на стэке Supabase/Bubble/N8N.