Критерии готовности олимпиад

Зачем нужно

Документ фиксирует признаки готовности олимпиадного домена к разработке, приёмке и запуску.

Кто использует

• competitions team;
• product;
• engineering;
• QA;
• support.

Сценарии

• проверить полноту целевой модели олимпиады;
• принять MVP домена;
• определить блокеры перед сезоном;
• согласовать интеграции с identity, Learning Workspace, task-bank, LMS и storefront.

Правила

• Готовность проверяется по полному циклу: настройка, регистрация, проведение, проверка, публикация, документы.
• Регламент конкретной олимпиады может добавлять критерии, но не отменяет базовые правила домена.
• Результаты и задания должны быть защищены до разрешённой публикации.

Интеграции

• identity — роли и аккаунты;
• Learning Workspace / Learning Group — учебные группы и списки учеников;
• task-bank — задания;
• LMS — разборы и тренажёрные попытки;
• storefront — публичные страницы и публикация;
• CRM — коммуникации;
• management — аналитика.

Безопасность

Роли, доступы, результаты, ответы и документы должны быть ограничены по статусу тура, связи с участником и правам пользователя.

Готовность

• можно создать олимпиаду, сезон и тур;
• участники, родители и преподаватели могут пройти двухшаговую регистрацию;
• official data package для ГИР проверяется через identity protected attributes и не хранит raw official fields в competitions;
• преподаватели работают через выбранную организацию и Learning Groups;
• преподаватели могут подать заявку на проведение и открыть материалы олимпиады;
• competition_group используется только как snapshot/projection сезона;
• тур связан с LMS activity runtime или temporary LMS-compatible activity adapter;
• task structure locked до открытия тура, а task-bank используется как content/source, не runtime;
• answers/files/scans принимаются через LMS activity runtime или temporary adapter, competitions хранит refs/status/snapshots;
• первый тур поддерживает пакетную отправку ответов по ученикам с lock и досылкой новых учеников до закрытия окна;
• площадки проходят заявку, публикуются списком/на карте, поддерживают выбор/смену и capacity guard;
• площадки содержат participant-facing правила входа, документы, сопровождающих и facility rules;
• MVP-апелляции отделены от арбитража подозрительных работ;
• результаты считаются и публикуются;
• документы, награды и благодарственные письма формируются через общий документный контур;
• роли и доступы ограничены;
• административные изменения аудируются.

Детальные критерии

Документация

• границы домена описаны в scope.md;
• модель данных описывает event, season, tour, track, participant, registration, official data package, teacher conduct application, teacher material, group, venue, activity binding, task structure, submission refs, score snapshots, result, publication и document;
• схема БД содержит external refs, constraints, publication status и audit;
• все основные сущности имеют статусные модели;
• API разделяет public, participant, teacher, venue, checker и admin endpoints;
• API фиксирует teacher mode с выбранной организацией, а площадочные и административные функции как подслои роли;
• DTO и validation описаны для registration, claim, activity binding, submission refs, score snapshots, result, publication и documents;
• матрица прав покрывает self, family, teacher mode, learning group, teacher admin layer, teacher venue layer, checker, systematika admin и public contexts;
• тест-план покрывает unit, integration, e2e, security и resilience сценарии.

Сезоны и туры

• event создаётся отдельно от season;
• season поддерживает registration policy и fee policy;
• количество туров не хардкодится;
• tour format, delivery mode и result track не смешиваются;
• финальный тур может быть единственным;
• очный формат не означает автоматически официальный зачёт;
• tour lifecycle запрещает submissions после close без admin override;
• cancellation не удаляет registrations, payments и audit.

Участники и регистрация

• индивидуальная регистрация создаёт participant, registration и season participation;
• регистрация поддерживает предварительный шаг, дозаполнение и approval;
• parent registration создаёт участие ребёнка, а прохождение тура идёт в child mode;
• official data package требуется только для официального сценария регламента;
• official data package включает СНИЛС ребёнка, дату рождения ребёнка, email родителя и телефон родителя;
• competitions хранит только requirement/status/ref/audit, а raw official fields принадлежат identity protected attributes;
• учитель может инициировать ручной ввод official data package только в разрешённом official flow;
• pending parent account/invite не становится подтверждённым родительским доступом без действия родителя или trusted flow;
• текстовое поле «учитель» не создаёт автоматическую связь с преподавателем;
• teacher registration использует Learning Workspace / Learning Group;
• competition_group является season snapshot/projection, не canonical списком учеников;
• organization registration может создавать participant из organization_student_id с identity_organization_id и organization_student_snapshot;
• duplicate detection создаёт review queue, а не silent merge;
• claim access связывает participant с user/family только после approval;
• paid season требует CRM payment/entitlement signal перед approval;
• TourParticipation хранит delivery mode конкретного участника.

Организации и площадки

• organization может быть organizer, closed group host, open venue или совмещать роли;
• organization/venue actions доступны как подслои преподавательского режима с выбранной организацией;
• venue application проходит approval;
• approved venue публикуется списком и/или на карте;
• participant может выбрать или сменить площадку по правилам сезона;
• venue capacity и assignments проверяются;
• capacity нельзя уменьшить ниже текущих назначений без admin process;
• участник видит правила входа, документы, сопровождающих, facility rules и public comment до выбора площадки;
• storefront не получает private contacts, technical capabilities и admin internal comments;
• смена площадки показывает предупреждение об отмене предыдущего назначения;
• venue видит только назначенных участников;
• списки площадки и передача работ аудируются.

Activity runtime, task-bank и task structure

• tour activity binding связан с LMS activity или temporary LMS-compatible adapter;
• task-bank refs используются как content/source refs, а не runtime refs;
• locked activity/task structure нельзя менять без новой версии или audit;
• competitions хранит task number, max score, LMS item refs и score snapshots;
• answer keys не копируются как источник истины в competitions;
• LMS activity runtime unavailable blocks launch unless approved temporary adapter exists;
• task-bank unavailable before lock блокирует activity binding или создаёт explicit issue, кроме заранее утверждённого temporary content snapshot;
• training publication прошедшей activity не влияет на competition result.
• published training publication содержит lms_ref; storefront_ref не заменяет LMS ownership.

Ученический интерфейс

• ученик видит текущие, будущие и прошедшие олимпиады;
• карточка списка показывает личный статус ученика и доступный CTA;
• будущая олимпиада может показать предварительную регистрацию, напоминание или подготовку;
• прошедшая олимпиада ведёт в тренажёр только при published LMS/training link;
• архив доступен отдельно от ограниченного списка прошедших олимпиад;
• карточка олимпиады показывает разные CTA в зависимости от состояния регистрации, тура, проверки, публикации, апелляций и документов;
• результаты по задачам показываются только по publication policy.

Проведение и submission refs

• participant запускает или продолжает LMS activity attempt из competitions в разрешённом delivery mode;
• raw answers не принимаются competitions API, если execution LMS-owned;
• competition-facing submission refs/status после lock не редактируются участником;
• преподавательская отправка по группе требует warning и lock отправленных учеников;
• первый teacher-led тур может требовать approved TeacherConductApplication;
• до окончания первого тура можно дослать новых учеников, если это разрешено регламентом;
• финальный MVP принимает файлы/zip/изображения без обязательной привязки каждого файла к ученику, late upload фиксируется;
• фотоотчёт имеет статусы submitted/confirmed/unconfirmed, unconfirmed требует комментарий;
• фотоотчёт может быть связан с заявкой преподавателя на проведение, competition group и/или venue;
• void submission/ref требует reason;
• file uploads проходят validation;
• teacher/venue upload не раскрывает чужие работы;
• submission/ref status синхронизирован с LMS/adapter checking.

Проверка и результаты

• checking поддерживает LMS runtime, temporary adapter, manual override и imported modes;
• LMS/adapter возвращает score by item;
• competitions stores immutable score snapshots before result calculation;
• score changes после checking/finalize требуют permission, reason и audit;
• result calculation происходит отдельно от publication;
• процентные ориентиры порогов фиксируются snapshot и утверждаются вручную;
• удержанный результат исключается из публикации до release;
• finalized result нельзя менять без recalculation/amendment;
• rankings считаются отдельно по track/category;
• disqualified participant не попадает в public standings, если policy не разрешает.

Публикации и документы

• personal results и public results публикуются отдельными actions;
• public publication требует finalized results;
• публикация результатов идёт по классам и зачётам;
• work publication может быть personal-only;
• award documents генерируются только для finalized award status;
• award status использует детальные коды diploma_1, diploma_2, diploma_3, honorable_mention_1, honorable_mention_2, participation_certificate, no_award;
• gratitude documents доступны для помощников, команды, организации и площадки;
• document verification раскрывает только public-safe data;
• revoked document сохраняет verification history.

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

• MVP-апелляция создаётся для несогласия с проверкой или результатом;
• UI-статус апелляции “Новая” мапится на technical submitted;
• арбитраж подозрительных работ ведётся отдельной сущностью и workflow;
• арбитраж может удержать результат от публикации;
• решения апелляции и арбитража имеют reason и audit.

Интеграции

• identity используется для user/family/organization facts and access signals;
• Learning Workspace / Learning Group используется для teacher groups and canonical student roster;
• CRM отдаёт payment/entitlement для paid registrations;
• LMS activity runtime отдаёт attempts/status/checking/score by item для competition mode;
• task-bank отдаёт content/source refs; temporary content snapshots мигрируются в task-bank отдельной фазой;
• LMS получает ссылки на разбор/тренажёр; training attempt не влияет на competition result;
• storefront получает только published public data и participant-safe поля площадок;
• management получает агрегаты без PII и raw submissions;
• notifications получают события registration/tour/result/document.

Безопасность

• participant не видит чужие результаты и работы;
• parent не получает доступ без family/claim link;
• teacher видит только разрешённые Learning Groups и competition snapshots;
• helper видит только выданные ограниченные действия;
• venue layer видит только назначенных участников;
• checker видит только assigned submissions;
• public не видит hidden results;
• public не видит withheld results;
• все score/result/publication/document изменения аудируются.

MVP acceptance

MVP competitions можно принимать, если работают:

1. event, season, tour and track lifecycle;
2. individual registration;
3. two-step registration, parent child-mode and teacher registration from Learning Group snapshot;
4. official data package readiness and identity protected collection flow;
5. claim access flow;
6. teacher conduct application and teacher materials;
7. LMS activity binding and locked task structure or explicit temporary LMS-compatible adapter for competitions-first MVP;
8. submission/attempt refs with answers/files in LMS/adapter, group answer lock, late new students before first-tour close and MVP bulk file upload;
9. venue application with expanded participant-facing fields, public list/map, selection/change and capacity guard;
10. student olympiad list and student olympiad card;
11. checking integration, immutable score snapshots, appeal and arbitration split;
12. result calculation, manual threshold approval, finalization and withholding;
13. personal/public publication split by class/track;
14. award and gratitude document generation stub or implementation;
15. permissions for self/family/teacher mode/helper/venue layer/checker/systematika admin;
16. tests from test-plan.md for critical flows.