Обзор домена олимпиад

Зачем нужно

Домен олимпиад отвечает за проектирование и проведение соревновательных мероприятий «Систематики»: олимпиад, конкурсов, турниров и других интеллектуальных соревнований.

Домен поддерживает разные предметы, сезоны, туры, форматы проведения, индивидуальное и групповое участие, очные площадки, проверку работ, публикацию результатов и выдачу документов. Математическая олимпиада — первый подробный референс, но модель не захардкожена под один предмет, сезон или двухтуровую структуру.

Пользовательские слои

Олимпиады проектируются не как один административный кабинет, а как набор пользовательских слоёв:

Слой	Что видит и делает
Ученик	регистрируется, проходит тур в детском режиме, отправляет ответы, видит личные результаты и документы
Родитель	регистрирует ребёнка, дозаполняет данные, оплачивает при необходимости, смотрит результаты и документы ребёнка
Преподавательский режим	выбирает организацию и работает со своими Learning Workspace / Learning Group
Административный подслой преподавательского режима	в выбранной организации управляет регистрациями, помощниками, статусами и отчётами в пределах роли
Площадочный подслой преподавательского режима	в выбранной организации ведёт заявку площадки, слоты, списки и передачу работ
Админ «Систематики»	управляет сезоном, регламентом, публикациями, исключениями, арбитражем и документами
Витрина	показывает публичные страницы, опубликованные результаты, площадки списком/на карте и ссылки на LMS-разбор или тренажёр

Организация и площадка не являются отдельными пользовательскими контекстами рядом с преподавательским. Пользователь входит в преподавательский режим, выбирает организацию, а дальше получает подслои по роли: учитель, координатор, помощник, ответственный площадки или сотрудник площадки.

Ключевые возможности

• event/season/tour/track model для мероприятий с разной структурой;
• registration и participation как отдельные сущности;
• участники без аккаунта identity с последующим claim-доступом;
• регистрация через Learning Workspace / Learning Group без владения каноническим списком учеников;
• competition_group как season-specific snapshot/registration projection, а не общий список учеников преподавателя;
• очные площадки и назначение участников;
• tour activity bindings через LMS activity runtime без копирования канонических задач; для competitions-first MVP допускается temporary LMS-compatible activity adapter;
• competition-facing submission refs, files/scans refs, auto/manual/hybrid checking через LMS/runtime или adapter;
• results, rankings, publications и award documents;
• training publication прошедшей LMS activity/review mode без влияния на результаты;
• official data package для ГИР через identity protected attributes без хранения сырого СНИЛС в competitions;
• ученический раздел «Олимпиады» с текущими, будущими и прошедшими сезонами, личными статусами, архивом и LMS-тренажёрами;
• teacher conduct application для заявки преподавателя на проведение первого тура;
• teacher materials для анонса, проведения, отчёта, итоговой новости и благодарностей;
• расширенная заявка площадки с правилами входа, документами, сопровождающими, facility rules и разделением публичных/административных полей;
• audit всех действий, влияющих на доступ, работу, баллы и публикации.

Главные инварианты

1. Участник олимпиады может существовать без identity account. Канонический учебный субъект — student_profile_id; для linked account дополнительно действует ADR-031: в одном сезоне допускается только один активный competition_participant на identity_user_id.
2. Способ прохождения хранится на уровне competition_tour_participation, а не только на группе или сезоне.
3. Task-bank владеет задачами; LMS activity runtime владеет attempts/responses/files/checking result. Competitions хранит activity refs, task number, max score, item refs и score snapshots. Временное исключение для competitions-first MVP описано ниже.
4. CRM владеет оплатой и entitlement; competitions хранит только статус допуска к участию.
5. Publication status отделён от calculation/finalization status.
6. Learning Workspace / Learning Group владеет учебными группами; competitions хранит только олимпиадную проекцию регистрации сезона.
7. Внешний или штатный преподаватель видит только участников своих Learning Groups и опубликованные данные по visibility gates.
8. Родитель может зарегистрировать ребёнка, но прохождение тура выполняется ребёнком в детском режиме.
9. Финальный тур может быть единственным туром сезона; очный формат не означает автоматически официальный зачёт.
10. Тренировочная попытка в LMS/тренажёре не является олимпиадной попыткой и не влияет на результаты.
11. Official data package для ГИР состоит из СНИЛС ребёнка, даты рождения ребёнка, email родителя и телефона родителя; raw values принадлежат identity/protected attributes, competitions хранит только readiness/status/ref/audit.

Границы

Краткая карта границ:

Область	Владелец
Пользователи, family, organization, роли	identity
Задачи, решения, answer schema, usage/source refs	task-bank
Activity runtime, attempts, responses, files, checking result	lms
Коммерческое право участия	crm
Публичные страницы и лендинги	storefront
Учебные программы и roadmap	lms
Learning Workspace / Learning Group	learning workspace / lms layer
Метрики, goals, dashboards	management

Полная спецификация границ: scope.md.

Competitions-first MVP exception

Если олимпиада запускается до готовности LMS activity runtime или task-bank, допускается temporary LMS-compatible activity adapter.

Правила исключения:

• activity_binding.mode = 'temporary_adapter' используется только для первого launch slice и явно отмечается в данных;
• adapter содержит locked activity snapshot, item refs, max score and scoring snapshot for this tour;
• canonical ownership задач не переносится в competitions: после готовности task-bank content snapshots мигрируются в task-bank, а runtime переезжает в LMS activity;
• исторические submissions/results остаются воспроизводимыми по locked activity structure и score snapshots;
• публичные страницы олимпиады могут временно жить в competitions до готовности storefront;
• payment_status может временно храниться в competitions до готовности CRM только как допусковой status, не как коммерческий source of truth.

Акторы

Актор	Роль в домене
Ученик	проходит олимпиаду в детском режиме, отправляет ответы, смотрит свои результаты
Родитель	регистрирует ребёнка, дозаполняет данные, смотрит семейные результаты и документы
Преподаватель	в выбранной организации регистрирует Learning Group или выбранных учеников, добавляет помощников
Помощник преподавателя	помогает проводить тур и загружать ответы в урезанном контуре
Ответственный площадки	в площадочном подслое выбранной организации ведёт заявку, вместимость, списки и передачу работ
Проверяющий	проверяет assigned submissions
Методист	связывает туры с LMS activity, task-bank source refs и score contract
Администратор «Систематики»	управляет сезоном, турами, публикацией, арбитражем, документами и исключениями
Посетитель витрины	читает регламент, опубликованные результаты, карту площадок и материалы разбора

Карта документов

• scope.md — границы, акторы, соседние домены и запреты.
• mvp-launch-plan.md — competitions-first MVP slice и временные исключения до готовности всей экосистемы.
• data-model.md — event, season, tour, participants, external teachers, venues, activity bindings, submission refs, score snapshots, results, documents.
• database-schema.md — PostgreSQL DDL, constraints, external refs и audit.
• state-machines.md — lifecycle seasons, tours, registrations, participations, submissions, results, publications и documents.
• api-map.md — public/admin/user endpoints, permissions и error codes.
• api-contracts.md — DTO, validation и response schemas.
• permissions-matrix.md — endpoint/action → permission → actor context → audit.
• events.md — входящие и исходящие события, payloads, идемпотентность и retention.
• screen-spec.md — public, participant, parent, teacher, venue, checker и admin screens.
• user-flows.md — подробные сценарии участия, групп, площадок и claim.
• features/*.md — детальные спецификации capabilities, включая external teachers.
• test-plan.md — unit, integration, e2e, security и resilience tests.
• acceptance.md — критерии готовности к разработке и hand-off.

Готовность

Домен готов к ground-up реализации, когда:

• все 15 канонических файлов домена имеют status: active;
• DDL содержит participant claim uniqueness и external teacher profile;
• API, permissions и state machines покрывают external teacher flow;
• integration-файлы используют канонические event names и обязательные секции;
• test-plan проверяет регистрацию, submission, проверку, публикацию и документы end-to-end.