Перейти к основному содержимому

Сценарии competitions

Зачем нужно​

Документ описывает внутридоменные сценарии competitions: подготовка события, регистрация, проведение тура, проверка работ, публикация результатов и наградных документов.

1. Создание олимпиады и витрины​

  1. Куратор создаёт competition_event и competition_season с регламентом.
  2. Создаёт любое число competition_tour; финальный тур может быть единственным.
  3. Для каждого тура задаёт delivery modes, tracks и official status. Очный тур не считается официальным автоматически.
  4. Связывает тур с LMS activity или, для competitions-first MVP, temporary LMS-compatible adapter.
  5. Фиксирует task structure: task number, max score, LMS item refs and source refs.
  6. Публикует на витрину регламент, сроки, правила регистрации, список/карту площадок и ссылки на LMS-разбор/тренажёр, если они доступны.

2. Индивидуальная регистрация ученика​

  1. Ученик открывает регистрацию на витрине или в личном кабинете.
  2. Создаёт предварительную регистрацию pre_submitted.
  3. Дозаполняет обязательные поля второго шага.
  4. Если сценарий официальный, регламент может потребовать official data package: СНИЛС ребёнка, дату рождения ребёнка, email родителя и телефон родителя.
  5. Сбор official data package проходит через identity protected attributes; competitions получает только readiness/status/ref.
  6. После оплаты/entitlement при необходимости регистрация переходит в submitted, pending_review или approved.

3. Родитель регистрирует ребёнка​

  1. Родитель выбирает ребёнка из family или создаёт запись ребёнка.
  2. Создаёт предварительную регистрацию и дозаполняет данные ребёнка.
  3. Система создаёт competition_participant ребёнка и помечает child_mode_required.
  4. Родитель видит статус, оплату, результаты и документы.
  5. В момент тура ребёнок проходит олимпиаду в детском режиме; родитель не получает право отправлять ответы вместо ребёнка, если это не разрешено регламентом.

4. Преподаватель регистрирует группу или выбранных учеников​

  1. Пользователь входит в преподавательский режим и выбирает организацию.
  2. Система показывает Learning Workspaces / Learning Groups, доступные через соседний домен.
  3. Преподаватель выбирает Learning Group или отдельных учеников.
  4. Competitions создаёт competition_group как снимок сезона и competition_group_member как registration projection.
  5. Преподаватель отправляет group registration; при платном участии entitlement проверяется per group или per participant.
  6. Преподаватель может добавить помощников с правами вроде ввода ответов, загрузки файлов или просмотра списка.

competition_group не является каноническим списком учеников преподавателя. Изменения состава Learning Group после регистрации не меняют олимпиадную проекцию без явного действия.

5. Заявка преподавателя на проведение​

  1. Пользователь входит в преподавательский режим и выбирает организацию.
  2. Открывает действие “Провести Олимпиаду”.
  3. Выбирает сезон и тур, обычно первый тур.
  4. Указывает место, ожидаемое количество участников, даты/период, классы, формат и контакты.
  5. Отправляет TeacherConductApplication.
  6. approval_required определяется policy: для обычного первого тура submitted может быть достаточен, а approval нужен для закрытых материалов, официального финала, открытой площадки или risk/admin policy.
  7. Администратор одобряет, отклоняет или возвращает на уточнение, если approval required.
  8. После submitted или approved согласно policy преподаватель получает материалы и продолжает регистрацию учеников через Learning Group.

Заявка на проведение не заменяет регистрацию участников и не создаёт competition_group автоматически.

6. Первый тур через преподавателя​

  1. Тур открывается по расписанию, материалы доступны только в окно тура.
  2. Преподаватель открывает список участников из снимка Learning Group.
  3. Для каждого ученика вводит ответы или отмечает отсутствие.
  4. Перед отправкой UI показывает предупреждение: сколько учеников будет заблокировано, есть ли пустые ответы и что после отправки редактирование закрывается.
  5. После подтверждения создаются/обновляются LMS/adapter attempts и competition-facing competition_submission refs, отправленные работы переходят в locked.
  6. До окончания окна тура преподаватель может дослать новых учеников, если они ещё не были отправлены и регламент разрешает late add.
  7. После проведения преподаватель отправляет фотоотчёт, связанный с заявкой на проведение и/или competition_group.

7. Онлайн-прохождение ребёнком​

  1. В окне тура ребёнок входит в детский режим.
  2. Открывается LMS activity или temporary adapter activity.
  3. Ребёнок отправляет ответы и файлы в runtime.
  4. После отправки LMS/adapter attempt блокируется, а competitions сохраняет refs/status.
  5. Родитель и преподаватель видят только разрешённые статусы до публикации.

8. Очная площадка​

  1. Организация в площадочном подслое преподавательского режима подаёт заявку площадки.
  2. Заявка включает адрес, контакты, классы, слоты, вместимость, правила входа, документы, сопровождающих, сменку, воду/еду, доступность, printing/scanning capabilities и public/admin comments.
  3. Админ «Систематики» проверяет заявку, адрес, контакты, классы, слоты, вместимость и participant-facing условия.
  4. После админского approval площадка публикуется списком и/или на карте только с public-safe полями.
  5. Участник видит правила площадки до выбора.
  6. Участник выбирает площадку или меняет её до закрытия выбора; при смене UI предупреждает об отмене предыдущей записи.
  7. Уменьшение вместимости ниже текущего числа участников блокируется и требует admin process.
  8. После тура площадка загружает работы или передаёт их администратору.

9. Финальный тур и MVP-загрузка файлов​

  1. Финальный тур может быть единственным туром сезона.
  2. Материалы финала открываются строго по времени.
  3. В MVP преподаватель, помощник, площадка или админ может загрузить файлы, zip или изображения пакетом.
  4. Привязка каждого файла к ученику желательна, но не обязательна для MVP.
  5. Поздняя загрузка фиксируется флагом, причиной и audit.

10. Фотоотчёт​

  1. Преподаватель или ответственный площадки отправляет фотоотчёт после проведения.
  2. Статус становится submitted.
  3. Админ подтверждает отчёт (confirmed) или возвращает unconfirmed с комментарием.
  4. Повторная отправка сохраняет историю и не меняет результаты.

11. Проверка​

  1. LMS activity runtime или temporary adapter выполняет checking и возвращает score by item.
  2. Competitions сохраняет immutable score snapshots.
  3. Ручная проверка проходит анонимно в LMS/runtime или adapter, с версиями баллов и комментариями.
  4. Изменения после проверки требуют reason, новую snapshot/version и audit.

12. Апелляция и арбитраж​

  1. Участник, родитель или преподаватель подаёт MVP-апелляцию по результату или проверке.
  2. В админке новая пользовательская апелляция отображается как “Новая”, что технически соответствует submitted.
  3. Апелляционная комиссия принимает решение; accepted appeal создаёт новую версию score/check или recalculation.
  4. Подозрительные работы, нарушения регламента и санкции идут в отдельный competition_arbitration_case.
  5. Арбитраж может удержать результат от публикации, но не подменяет пользовательскую апелляцию.

13. Публикация результатов​

  1. По завершении проверки куратор запускает расчёт по классам и зачётам.
  2. Пороговые правила наград задаются процентными ориентирами и фиксируются в snapshot.
  3. Админ вручную утверждает пороги, удержания и публикационный scope.
  4. Личные результаты и публичные списки публикуются отдельными actions.
  5. Удержанные результаты не попадают на витрину до решения администратора.

14. Наградные и благодарственные документы​

  1. По утверждённым результатам создаются дипломы, грамоты, сертификаты и документы участия.
  2. Общий документный контур генерирует номер, PDF, verification code и статус.
  3. Преподаватели, помощники, команда проведения, организация и площадка могут получить благодарственные письма.
  4. Текстовые получатели благодарностей допускаются, если человек не является пользователем платформы.

15. Материалы преподавателя​

  1. Преподаватель открывает “Материалы Олимпиады” в выбранной организации.
  2. До регистрации видит афиши, баннеры, анонсы и правила.
  3. Перед туром видит инструкции, список участников и материалы проведения.
  4. Во время тура видит материалы тура, бланки и отправку ответов.
  5. После тура видит фотоотчёт и статус проверки.
  6. После публикации результатов видит результаты учеников, итоговую новость и благодарности.

16. Ученик смотрит список олимпиад​

  1. Ученик открывает раздел “Олимпиады”.
  2. Система показывает текущие, будущие и прошедшие олимпиады.
  3. Каждая карточка показывает личный статус ученика и следующий CTA.
  4. В прошедших олимпиадах показываются последние 5-6 сезонов, ссылка на архив и тренажёр только при published LMS/training link.

17. Ученик открывает карточку олимпиады​

  1. Ученик открывает конкретную олимпиаду.
  2. Видит расписание, регистрацию, туры, результаты, работу, апелляции, документы, подготовку, разборы и тренажёр.
  3. CTA меняется по состоянию регистрации, тура, проверки, публикации и документов.
  4. Если official data package требуется и не готов, карточка показывает недостающие поля без раскрытия raw protected values.
  5. Если тренажёр опубликован, переход ведёт в LMS/training контур и не создаёт competition attempt.

18. Архивация сезона​

  1. По завершении периода — сезон закрывается.
  2. Доступ к работам остаётся для участников и владельцев access_claim.
  3. Дипломы остаются доступны.

Связанные документы​