Поэтапный план реализации

Зачем нужно

Документ фиксирует рабочий план реализации первого крупного продукта новой экосистемы Systematika: полного олимпиадного контура competitions и минимального набора возможностей из соседних доменов, без которых competitions не может работать корректно.

Детальный backlog epics/tasks и traceability 1:1 по таблицам, endpoint-ам, статусам и тестам вынесен в competitions-implementation-backlog.md.

Это не план полной последовательной реализации всех 7 доменов. Полная целевая архитектура остаётся прежней, но первый delivery focus меняется:

1. Сначала реализуем production-ready competitions.
2. Из platform, identity, lms, task-bank, storefront, crm и management берём только минимальные supporting slices.
3. Supporting slices не должны незаметно превращаться в полноценные домены.
4. Все временные упрощения фиксируем явно и закрываем через exit criteria.

Главная стратегия

Первый релиз строится вокруг полного цикла Олимпиады: настройка Олимпиады -> публикация -> регистрация -> организация проведения -> участники и группы -> LMS activity для тура -> сдача работ -> проверка -> score snapshots -> результаты -> публикация -> документы -> архив и аудит.

Остальные домены в первом этапе обслуживают этот цикл:

Домен	Роль в первом этапе
platform	Минимальный стек, CI, events, API conventions, observability, UI Kit
identity	Auth, users, sessions, organization-lite, organization students, selected organization, protected attributes
lms / Learning Workspace	Минимальный roster slice плюс минимальный LMS activity runtime для выполнения олимпиадного задания или совместимый temporary adapter
task-bank	Источник задач, подборок, activity templates, versions and locked content snapshots, если готов; не является runtime прохождения Олимпиады
storefront	Публичные страницы олимпиад можно временно держать в competitions до готовности storefront read-model
crm	Для первого бесплатного или ручного платного запуска можно не строить полный CRM; admission/payment status остаётся временным полем competitions
management	Не входит в первый production scope, кроме минимальных operational exports/reports

Источники плана

Документ	Роль в плане
domains/competitions/mvp-launch-plan.md	Базовый launch slice для первого олимпиадного релиза
domains/competitions/overview.md	Границы и инварианты competitions
domains/competitions/scope.md	Что входит и что не входит в competitions
domains/competitions/data-model.md	Сущности олимпиадного контура
domains/competitions/api-contracts.md	API-контракты competitions
domains/competitions/acceptance.md	Критерии готовности competitions
ecosystem/domain-map.md	Канонические границы 7 доменов
ecosystem/ownership.md	Источники истины по сущностям
integrations/README.md	Матрица cross-domain интеграций
platform/acceptance.md	Минимальная готовность платформы
migration/risks.md	Риски миграции
competitions-implementation-backlog.md	Детальный backlog и traceability coverage

Архитектурные правила первого этапа

1. competitions владеет только олимпиадным lifecycle: event, season, tour, track, registration, participant, access snapshot, submission, check, result, publication, award document.
2. competition_group в первом релизе является season/event snapshot, а не каноническим списком “моих учеников”.
3. Канонический roster “мои ученики / мои группы” остаётся в Learning Workspace (lms), даже если его первый slice минимален.
4. organization, organization_membership, organization_student и selected organization остаются в identity.
5. educator_profile остаётся trust profile в identity и не выдаёт прав сам по себе.
6. Если task-bank или LMS activity runtime не готовы, допускается temporary LMS-compatible activity adapter с locked snapshot и audit. Он не должен превращаться в task-bank, activity template editor или полноценный LMS и должен иметь migration trigger.
7. Если storefront не готов, публичные страницы олимпиады временно живут в competitions, но не становятся storefront source of truth.
8. Если CRM не готов, competitions может хранить admission/payment status только как временный статус допуска, не как коммерческий источник истины.
9. Любое временное владение или shortcut получает migration trigger.
10. В первом релизе нельзя проектировать соседний домен шире, чем нужно для полного olympiad cycle.
11. Олимпиадный тур исполняется как LMS activity или temporary LMS-compatible activity adapter.
12. Competitions хранит только структуру задач для результата: task number, class/category, max score, LMS activity/item ref и score snapshot.
13. Competitions не владеет каноническим контентом задач, answers runtime, training attempts и LMS progress.
14. После завершения Олимпиады activity может быть опубликована как trainer/review mode в LMS.

Полная матрица реализации competitions

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

Доменные сущности

Группа	Сущности, которые должны быть реализованы
Event and season	competition_event, competition_season, competition_grade_category, competition_tour, competition_track, competition_award_policy
Participants and access	competition_participant, competition_registration, competition_official_data_package, competition_season_participation, competition_tour_participation, competition_access_claim
Groups and organizations	competition_group, competition_group_member, competition_organization, competition_organization_role
Venues	competition_venue, competition_venue_assignment, venue application lifecycle
Teacher operations	competition_teacher_conduct_application, competition_teacher_material, helper grants, external_teacher_profile, external teacher student links
Activity and task structure	competition_tour_activity_binding, competition_tour_task_structure, competition_tour_task_item, LMS activity refs, task-bank source refs, competition_training_publication
Delivery	competition_submission как competition-facing attempt/submission ref и status, competition_submission_file как file ref, photo report
Checking	score snapshots, checking status refs, checker assignment only for temporary adapter or imported/manual mode
Results	competition_result, competition_ranking, award status, withholding, recalculation/amendment
Publications	competition_publication, personal publication, public standings, work publication
Documents	competition_award_document, competition_document_generation_job, verification code, revoke history
Audit	competition_audit_log for all security, score, publication, document and admin actions

Status models

Entity	Required lifecycle
Event	draft -> active -> archived
Season	draft -> registration_open -> running -> checking -> results_review -> published -> archived, with cancellation path
Tour	draft -> scheduled -> open -> closed -> checking -> results_ready -> published -> archived, with cancellation path
Registration	draft, pre_submitted, needs_completion, submitted, pending_review, approved, duplicate_hold, rejected, cancelled
Official data package	not_required, not_filled, incomplete, needs_verification, confirmed, rejected
Season/Tour participation	pending/admitted/active/completed/withdrawn/disqualified variants
Submission	not_started, started, submitted, locked, checking, checked, void
Tour activity binding	draft -> review -> locked -> published -> archived
Result	draft -> calculated -> review -> finalized, with void/withhold/release and separate publication
Publication	draft -> scheduled -> published -> hidden -> archived
Venue application	draft -> submitted -> needs_changes -> approved/rejected/cancelled
Teacher conduct application	draft -> submitted -> needs_changes -> approved/rejected/completed/cancelled
Appeal	draft -> submitted -> in_review -> accepted/rejected/cancelled
Arbitration case	opened -> in_review -> cleared/sanctioned -> closed
Award document	pending -> generated/failed -> revoked

API groups

API group	Required surface
Public	events, event page, season page, venue list/map, public results, training links, document verification
Admin event/season/tour	event, season, tour, grade category, track, policy and status management
Registration and participants	pre-registration, completion, final registration, admin moderation, claim access, official data collection/status
Teacher mode	organizations, Learning Groups, competition group snapshots, group registrations, helpers
Teacher conduct and materials	conduct applications, application review, season/tour materials, material publication windows
Venues	venue applications, approval, capacity, public-safe venue payload, selection/change, assignments, venue participant lists
Activity runtime and delivery	tour activity binding, LMS activity launch, participant attempt handoff, group submission refs, submission files, bulk files, photo reports, lock/void/admin override
Checking	LMS/adapter checking status, score snapshots, checker queue only for temporary adapter/manual mode, comments, override reason
Results	calculate, review, finalize, withhold/release, rank by class/track, threshold approval
Appeals and arbitration	appeal create/review/decision, arbitration cases and decisions
Publications	personal results, public standings, work publication, hide/revoke publication
Documents	generate, regenerate, revoke, verify, download by scoped visibility
External teachers	profile, verification, student links, assigned results
Audit/admin settings	audit logs, event types, delivery modes, award policies, templates, notification bindings

Frontend screens

Area	Required screens
Public	event list, event page, season page, rules, venue list, venue map, public results, document verification
Student cabinet	olympiad list, olympiad card, registration, missing official data state, tour workspace, result, work, appeal, documents, archive
Parent cabinet	child registration, child data completion, claim access, child results, child documents, consent/visibility actions
Teacher mode	organization selector, Learning Groups, competition group snapshot, group registration, helpers, materials, tour delivery, results, documents
Teacher admin layer	group/organization registration statuses, participant reports, photo report statuses, gratitude letters
Venue layer	venue application, capacity, participant-facing rules, assigned participants, file/bulk upload, photo report
Admin season	event/season settings, grade categories, tours, tracks, registration policy, fee policy, venues, activity bindings, checking, results, publications, documents, appeals, arbitration, materials, audit
Checker	queue, masked attempt/submission card, activity/item snapshot, files/scans or LMS refs, rubric, score fields, comments, reason
Results/publication	calculate, review, finalize, threshold approval, publish personal, publish public, hide/revoke, export
Admin settings	event types, subjects, delivery modes, award policies, document templates, notification templates, audit logs

Permissions and visibility

Context	Must enforce
self	participant sees only own registration, submissions, results, documents
family	parent sees child only through family/claim link
teacher_mode	teacher works only in selected organization and allowed Learning Groups
learning_group	handoff is allowed only through Learning Workspace permissions
teacher_admin_layer	organization-scoped registration/admin reports only
teacher_venue_layer	venue-scoped participants, files and materials only
helper_limited	helper can only perform explicitly granted actions
checker	checker sees only assigned masked submissions
systematika_admin	full admin with reason/audit on dangerous actions
public	only published public-safe data

Visibility gates must cover personal results, public results, withheld results, submissions/scans, activity structure before tour, answer/check details, documents and verification payloads.

Security and privacy

Required controls:

1. Raw official fields are rejected by competitions API and collected through identity protected attributes.
2. Submissions/files are private, stored with signed URL access and validation.
3. Answer keys are never copied as canonical truth from task-bank; temporary adapter keys are locked launch snapshots only.
4. Anonymous checking hides participant identity by default.
5. Parent, teacher, helper, venue and checker access is scoped and auditable.
6. Public pages exclude withheld results and private venue/admin fields.
7. Document verification reveals only public-safe data.
8. Rate limits exist for registration, submission, public results and access claims.
9. Mass download, closed task access, score override, publication and document generation are audited.
10. Production participant data is not used outside prod.

Test coverage

Test layer	Must cover
Unit	lifecycle transitions, duplicate detection, policy checks, locks, scoring, ranking, award thresholds
Integration	individual registration, parent registration, teacher Learning Group registration, organization student registration, paid season, LMS activity binding, temporary activity adapter, results/documents, appeals/arbitration
E2E	student online tour, teacher group tour, open venue flow, multi-track second tour, admin publication flow
Security	cross-participant access, parent claim, teacher scope, helper scope, venue scope, checker assignment, hidden/withheld results, document verification
Resilience	LMS activity runtime unavailable, task-bank unavailable before lock, duplicate CRM events, document generation failure, late submissions, Learning Group update after snapshot, identity organization merge

Operational and support capabilities

Capability	Required outcome
Admin search	Find participant, registration, group, submission, result, document, venue, conduct application
Exports	Venue lists, participant lists, checking queues, results, documents, operational reports
Runbooks	Registration opening, tour opening, tour closing, checking, publication, document generation, rollback
Rehearsal	Full dry run on staging with realistic users, files, checks and documents
Monitoring	Dashboards for registrations, submissions, checking backlog, errors, document jobs, file uploads
Data migration	Explicit decision for Мир Олимп: archive, import tasks, import seasons/results, or keep current season outside new contour

Фаза 0. Competitions foundation

Цель

Подготовить минимальную платформу и каркас сервиса, чтобы competitions можно было разрабатывать, тестировать и выпускать без ручной инфраструктуры.

Объём

Направление	Что нужно для competitions
Монорепо	pnpm workspaces, competitions-api, competitions-web, общие packages
Backend baseline	NestJS service template, config, health, validation, error envelope
Frontend baseline	Next.js app template, auth guard, layouts, forms, error states
Data baseline	PostgreSQL, Prisma migrations, audit fields, outbox pattern
Events	NATS JetStream dev setup, event publisher, idempotent consumers
Permissions	Минимальный catalog для competitions и selected organization
Observability	Logs, traces, metrics, request id, audit trail
UI Kit minimum	Компоненты для таблиц, форм, статусов, модалок, stepper/wizard
CI	lint, typecheck, unit, integration, migration check, build
File storage	MinIO/S3 для submissions, documents, bulk uploads

Выход

• competitions-api поднимается локально и в CI.
• competitions-web открывает защищённый shell.
• Миграции накатываются на чистую БД.
• Есть базовый audit и structured logging.
• Есть способ хранить файлы работ и документов.

Gate

Нельзя начинать доменную разработку competitions, пока не работает skeleton API, skeleton web, migrations, auth stub/integration point, CI и file storage.

Gate 0. Migration decision — Мир Олимп

До старта доменной разработки нужно принять решение, как первый запуск относится к существующему контуру “Мир Олимп”.

Варианты:

Вариант	Смысл
new_season_only	первый сезон в новой системе начинается с нуля
archive_only	старые данные только архивируются
import_tasks	импортируются задачи, source refs, problem sets, activity templates или locked content snapshots
import_seasons_results	импортируются сезоны, участники, результаты
hybrid	часть старого остаётся снаружи, часть импортируется

Решение влияет на task source, LMS activity binding, импорт результатов, архив, документы и исторические публикации. Поздний epic миграции реализует выбранный путь, а не принимает это решение впервые перед launch hardening.

Фаза 1. Identity minimum

Цель

Дать competitions корректную идентификацию, организации и официальный контур учеников, не реализуя весь identity-домен.

Объём

Capability	Минимум
Users	user, profile basics, email/phone, password login
Sessions	Access token, refresh token, logout, session list
JWKS/OAuth	JWKS validation для services, service-to-service token для competitions
Roles	Глобальный admin минимум, organization roles owner, admin, member
Organization-lite	organization, membership, invitations, selected organization
Organization students	organization_student для official organization contour
Educator profile	Минимальная анкета преподавателя как trust/contact profile
Protected attributes	Официальные данные ребёнка/родителя для регистрации, с privacy guard
Actor context	Действие от себя, от имени ребёнка, в выбранной организации
Audit	Вход, смена прав, organization changes, protected data access

Что явно не входит

• Полный family-домен, кроме того, что нужно для регистрации ребёнка.
• Сложные organization teams и fine-grained grants, если они не нужны первому запуску.
• Полный OAuth consent UX для внешней экосистемы.
• Полная identity admin platform.
• Глобальная роль teacher.

Выход

• Участник, родитель, преподаватель, helper и admin могут войти.
• Преподаватель может выбрать организацию, если состоит в ней.
• Организация может добавлять organization_student.
• Competitions может ссылаться на organization_student, organization, organization_membership, educator_profile.
• Protected official data собирается через identity-owned механизм, а не хранится свободным текстом в competitions.

Gate

Фаза закрыта, когда competitions может:

1. Валидировать пользователя и actor context.
2. Проверить selected organization.
3. Получить список organization students.
4. Принять official registration data без нарушения ownership.
5. Аудировать доступ к protected attributes.

Фаза 2. Learning Workspace minimum

Цель

Дать competitions доступ к “моим ученикам / моим группам” без закрепления этого списка в competitions.

Объём

Capability	Минимум
Learning Group	learning_group с владельцем/assigned educator context
Participants	learning_group_participant с привязкой к student/person snapshot
Read API	Получить доступные группы и участников для выбранного преподавателя/организации
Handoff	Передать группу в competitions как season-specific snapshot
Activity contract	Минимальный контракт LMS activity/attempt/item/score для олимпиады или совместимого temporary adapter
Audit	Кто, когда и из какой группы создал competition snapshot
Permissions	lms.learning-groups.read, lms.learning-groups.handoff или эквивалент

Что явно не входит

• Курсы, уроки, progress, roadmap, attendance, календарь.
• LMS enrollments по CRM entitlements.
• Полные training journeys, progress и разборы олимпиад за пределами минимального activity/review contract.
• Полноценный кабинет ученика LMS.

Выход

• Преподаватель выбирает Learning Group.
• Competitions создаёт competition_group как snapshot на сезон/тур.
• Competitions может связать тур с LMS activity или temporary LMS-compatible activity adapter по согласованному контракту.
• Изменения в Learning Group после snapshot не переписывают исторические регистрации автоматически.
• “Мои ученики” в UI не читаются из competitions.

Gate

Нельзя запускать teacher/group scenarios в competitions, пока нет минимального Learning Workspace read/handoff API или явно согласованного временного ручного импорта с migration trigger.

Фаза 3. Competitions core

Цель

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

Объём

Блок	Что реализовать
Event	competition_event, базовые настройки, публикация
Season	Сезон, календарь, registration windows, result windows
Grade categories	Классы/возрастные категории без хардкода
Tour	Тур, start/end windows, visibility, delivery mode
Track	Зачёт/result track, отделённый от delivery mode
Policies	Registration policy, fee policy, official data policy, award policy, appeal policy
Admin UI	Создание и настройка события, сезона, тура, трека
Admin settings	Event types, subjects, delivery modes, award policies, document template bindings
Status model	Draft, published, registration open/closed, running, checking, results, archived
Audit	Все изменения настроек и политик

Выход

• Admin может создать олимпиаду с сезоном, турами и треками.
• Public/admin visibility управляется статусами.
• Нельзя открыть регистрацию без обязательных политик и дат.
• Все изменения критичных настроек аудируются.

Gate

Фаза закрыта, когда можно настроить первую олимпиаду end-to-end до состояния “готова к регистрации”.

Фаза 4. Registration, participants, access

Цель

Реализовать полный lifecycle регистрации участников: индивидуальная, родительская, организационная, teacher-led, участник без аккаунта, claim access.

Объём

Блок	Что реализовать
Registration	Two-step registration: pre-registration -> completion/approval
Participant	competition_participant, participant snapshot, identity links
Parent flow	Родитель регистрирует ребёнка, попытка открывается в child mode
Teacher flow	Преподаватель регистрирует учеников через selected organization и Learning Group snapshot
Organization flow	organization_student_id, organization snapshot, membership snapshot
Access claim	competition_access_claim для последующей привязки аккаунта
Official data	Protected attributes для official scenario: СНИЛС ребёнка, дата рождения ребёнка, email родителя, телефон родителя
Duplicate review	duplicate_hold, review queue, no silent merge по ФИО
Admission status	Допуск, ожидание данных, отклонение, отмена
Paid admission hook	Если сезон платный, ожидание CRM payment/entitlement signal перед approval
TourParticipation	Delivery mode и track на уровне конкретного участника
Notifications	Минимальный adapter: регистрация начата/не завершена, запрос official data, допуск

Выход

• Участник может зарегистрироваться сам или через родителя.
• Преподаватель может зарегистрировать группу без получения родительских прав.
• Участник без аккаунта может быть создан и позже привязан через claim.
• Official data не размазывается по competitions как свободные PII-поля.
• Teacher official flow может создать parent contact / pending parent invite, но не выдаёт учителю родительские права.

Gate

Фаза закрыта, когда registration acceptance покрывает индивидуальный, родительский и teacher/group сценарии.

Фаза 5. Teacher conduct, venues, materials

Цель

Поддержать организацию проведения олимпиады преподавателями и площадками.

Объём

Блок	Что реализовать
Teacher conduct application	“Провести Олимпиаду”, статусы submitted, approved, cancelled, completed
Teacher materials	Инструкции, объявления, постеры, списки участников, отчёты, благодарности
Approval policy	approval_required определяется policy, а submitted может быть достаточен для обычного первого тура
Helper access	Ограниченные helpers без глобальной роли teacher
Venue application	Заявка площадки, условия прибытия, capacity, accessibility notes
Public venue list/map	Публикация одобренных площадок
Venue selection	Выбор/смена площадки участником до закрытия окна
Capacity guard	Нельзя снизить capacity ниже активных назначений без admin process
Notifications	Напоминания преподавателю/площадке: заявка подана, скоро тур, нужно отправить ответы, нужно загрузить фотоотчёт
Audit	Доступ к материалам, изменения площадок, helper actions

Выход

• Преподаватель может подать заявку на проведение.
• После отправки заявки преподаватель попадает в operational contour проведения. В обычном первом туре статус submitted может быть достаточен для регистрации учеников и доступа к открытым материалам; ручной approval нужен только по policy: площадка, официальный финал, ранний доступ к закрытым материалам, риск-сценарии.
• Участники могут выбрать площадку, если политика сезона это разрешает.
• Площадка не публикует приватные admin-поля.

Gate

Фаза закрыта, когда первый тур можно провести с teacher-led и venue-assisted сценариями.

Фаза 6. LMS activity binding and competition task structure

Цель

Обеспечить для тура стабильную учебную активность, через которую участник выполняет задания, а competitions получает структуру задач и score snapshots для расчёта результатов.

Объём

Блок	Что реализовать
Activity binding	Связать tour/grade category/track с LMS activity или temporary adapter
Activity item map	Зафиксировать task number, max score, lms_activity_item_ref и class/category
Score contract	Описать, как LMS/runtime возвращает score by item и итоговый score
Competition mode	Запуск активности как соревновательной попытки с окнами тура и правилами допуска
Training mode	После завершения activity может быть опубликована как trainer/review mode
Temporary adapter	Если LMS runtime не готов, реализовать temporary LMS-compatible adapter по будущему контракту
Task-bank link	Task-bank даёт content source/version refs, но не runtime прохождения
Lock	Activity/task structure фиксируется до открытия тура

Минимальный LMS activity slice

Мы не строим полный LMS, но для олимпиады нужен минимальный execution slice:

Capability	Минимум для Олимпиады
Activity / lesson	контейнер активности тура
Activity item	задача внутри активности
Attempt	попытка участника или группы
Response	ответ на задачу
File response	файл, фото, скан, zip, если нужно
Checking result	результат проверки по activity item
Score	балл по задаче и итоговый балл активности
Activity mode	competition, training, review
Publication link	возможность открыть activity как тренажёр после завершения

Не входит в этот slice: полноценные курсы, roadmap, course progress, расписание занятий, CRM enrollments, каталог уроков, сложная учебная аналитика и полноценный LMS editor.

Temporary LMS-compatible activity adapter

Если LMS activity runtime не готов, допустим temporary adapter.

Правила adapter:

1. Реализуется только ради первого олимпиадного запуска.
2. Повторяет будущий контракт LMS activity.
3. Не становится task-bank.
4. Не становится полноценным LMS.
5. Не создаёт отдельную библиотеку задач в competitions.
6. Хранит только locked activity snapshot для конкретного тура.
7. Имеет migration trigger в LMS activity runtime.
8. Competitions всё равно работает через refs и score snapshots.

Выход

• Тур связан с LMS activity или temporary compatible adapter.
• Для каждого класса/категории зафиксированы количество задач, max score по задаче и item refs.
• Competitions не хранит канонический контент задач, raw answers, training attempts или LMS progress.
• Нельзя незаметно изменить activity/task structure после lock.

Gate

Фаза закрыта, когда первый тур имеет locked activity binding, preview, security review, test attempt и проверенный score by item contract.

Gate 6. Early Walking Skeleton: simple online olympiad

До расширения delivery и checking нужно пройти ранний вертикальный сценарий:

1. Admin создаёт простую Олимпиаду, сезон, тур и один класс.
2. Admin создаёт или выбирает LMS activity из 2-3 задач.
3. Competitions связывает тур с LMS activity.
4. Ученик проходит двухшаговую регистрацию.
5. Ученик открывает тур из карточки Олимпиады.
6. Ученик выполняет LMS activity в competition mode.
7. LMS activity возвращает score by item.
8. Competitions сохраняет immutable score snapshot.
9. Admin рассчитывает и финализирует результат.
10. Admin публикует личный результат.
11. Генерируется тестовый сертификат.
12. Ключевые действия попадают в audit.

Этот gate проверяет границы competitions и LMS, registration, participant identity, activity refs, score snapshots, publication, document и базовый UX ученика.

Фаза 7. Competition delivery through LMS activity runtime

Цель

Реализовать проведение тура и сдачу работ так, чтобы participant входит из competitions, а выполнение задания происходит в LMS activity runtime или temporary compatible adapter.

Объём

Блок	Что реализовать
Tour opening	Доступ по времени, track, participant status, venue/delivery rules
Participant launch	Создать или получить LMS activity attempt, передать participant context и открыть runtime
Participant workspace	Карточка тура в competitions, запуск/продолжение activity, status refs, work view по publication policy
Teacher-led delivery	Групповая отправка преподавателем/helper пишет в LMS activity attempt или temporary adapter с warning перед lock
Submission refs	competition_submission хранит competition-facing refs/status; raw answers остаются в LMS/runtime где возможно
Bulk upload	File/zip/image для финального тура через LMS/adapter file submissions без mandatory per-student binding в MVP
Late handling	Late upload marker и audit
Photo report	submitted, confirmed, unconfirmed, comment
Storage	Файлы в S3/MinIO, antivirus или manual scan policy
Notifications	Скоро тур, нужно отправить ответы, нужно загрузить фотоотчёт
Audit	Кто открыл, изменил, отправил, заблокировал работу

Выход

• Участник может начать/продолжить activity из карточки Олимпиады.
• Преподаватель может отправить группу там, где policy разрешает, через LMS runtime или compatible adapter.
• После lock работа неизменяема без admin override.
• Competitions хранит refs/status/snapshots, а не становится владельцем LMS attempts и training attempts.

Gate

Фаза закрыта, когда тестовый тур проходит от открытия до locked LMS/adapter attempts, competition-facing refs и score-ready status на реальных типах delivery.

Фаза 8. Checking, appeals, results

Цель

Реализовать проверку, апелляции, арбитраж, score snapshots, расчёт результатов, утверждение порогов и финализацию результатов.

Объём

Блок	Что реализовать
Checking integration	Получить checking status и score by item из LMS runtime или temporary adapter
Score snapshots	Сохранить immutable score snapshot для competitions: item refs, task number, max score, score, status
Checking workflow	Reviewer assignment, scoring, comments только для temporary adapter/manual/imported mode
Auto/manual checking	По activity/checking policy: auto where possible, manual where required
Suspicious work	Отдельный admin workflow, может withhold result
Appeals MVP	Только disagreement по result/check, не arbitration подозрительных работ
Result model	competition_result, score, rank, award status, ready for publication status
Award thresholds	Manual threshold approval before finalization/publication
Ranking	Отдельный расчёт по class/grade category/track
Recalculation	Amendment/recalculation после finalized только с reason и audit
Imported mode	Возможность imported checking/result mode для миграции или ручного сезона
Finalize	Финализация результата отдельно от personal/public publication
Audit	Проверка, score snapshot, пересчёт, finalize, appeal decisions

Выход

• Проверяющий может обработать работу.
• Результат считается воспроизводимо по locked activity structure и score snapshots.
• Спор результата и подозрительная работа не смешиваются.
• Результаты готовы к publication, но personal/public publication ещё не смешивается с finalize.

Gate

Фаза закрыта, когда полный набор attempts/submission refs проходит checking -> score snapshot -> result calculation -> threshold approval -> finalize.

Фаза 9. Publications, documents and archive

Цель

Сформировать publication, document и archive слой Олимпиады: личные результаты, публичные результаты, trainer links, дипломы, сертификаты, благодарности и архив сезона.

Объём

Блок	Что реализовать
Public competition pages	Временно в competitions или через storefront projection
Personal publication	Личные результаты, work publication и доступ участника/родителя/учителя
Public publication	Публичные результаты по class/track после finalized results и publication action
Trainer link publication	Публикация LMS trainer/review CTA после готовности lms_ref
Award documents	diploma_1, diploma_2, diploma_3, honorable mentions, certificates
Gratitude documents	Helpers, team, organization, venue
Document generation	Template, PDF/rendering, storage, versioning
Document access	Participant/parent/teacher/admin visibility
Verification	Public verification code with public-safe payload
Revoke/regenerate	Revoke preserves verification history; regenerate creates auditable version
Exports	Published results, participant lists, venue lists, document exports
Notifications	Результаты опубликованы, документ готов, площадка подтверждена/изменила статус
Publication audit	Кто и когда опубликовал, скачал, перевыпустил
Archive	Season archive, immutable historical records

Выход

• Участник получает результат и документ.
• Преподаватель/организация получает доступные благодарственные документы.
• Публичная страница не раскрывает withheld/private data.
• Сезон можно перевести в archive.

Gate

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

Фаза 10. Hardening and production launch

Цель

Подготовить competitions к реальному production-запуску первой олимпиады.

Объём

Направление	Проверка
Security	PII minimization, protected attributes, access control, rate limits, file upload safety
Load	Registration spikes, submission spikes, document generation queue
Recovery	Backup/restore, replay events, regenerate documents
Observability	Dashboards, alerts, error budgets, audit queries
Support	Admin tools для поиска участника, статуса, работы, документа
Data quality	Duplicate detection, organization merge behavior, registration consistency
Migration	Реализация уже выбранного пути по Миру Олимп: архив, импорт задач, импорт сезонов/результатов, hybrid или отдельное ведение текущего сезона
Runbooks	Opening tour, closing tour, manual override, rollback, incident response
Legal/privacy	Retention, consent, official data visibility, export/delete policy

Выход

• Есть release candidate первого олимпиадного сезона.
• Есть operational runbook.
• Есть support/admin процедуры.
• Есть staged rehearsal на dev/staging с полной имитацией сезона.

Gate

Production launch разрешён только после репетиции полного цикла: создание сезона -> регистрация -> teacher/venue flow -> activity binding -> открытие тура -> LMS/adapter attempt -> score snapshot -> checking -> appeals sample -> finalize -> publication -> documents -> archive.

Что не строим в первом этапе

Домен	Не входит
CRM	Полный lead/deal/order/invoice/payment/refund/payroll lifecycle
LMS	Полные курсы, roadmap, attendance, полноценный кабинет ученика, сложная учебная аналитика за пределами минимального activity runtime/adapter
Task-bank	Полный редактор, таксономия, LMS usage, diagnostics, program template editor; task-bank не становится runtime прохождения Олимпиады
Storefront	Полный public read-model всей экосистемы, catalog ownership, SEO всех направлений
Management	Dashboards, goals, diagnostics, recommendations, team planning
Identity	Полная family model, сложные teams/grants, полный external OAuth ecosystem

Migration triggers после первого запуска

Временное решение	Когда закрывать
Temporary LMS-compatible activity adapter	Когда LMS activity runtime поддерживает competition/training/review modes, attempts, responses, file responses, checking result и score by item
Temporary content snapshot	Когда task-bank поддерживает problem versions, answer policy, activity/problem-set snapshots, usage/source refs для LMS activity
Public pages inside competitions	Когда storefront read-model готов принимать competition publications
Competitions payment/admission status	Когда CRM order/payment/entitlement flow готов
Learning Workspace read-only slice	Когда полноценный LMS/Learning Workspace готов к sync events, activity runtime и training/review scenarios
Manual operational reports	Когда management ingestion и dashboards готовы
Simple notifications	Когда platform/identity notification runtime выделен полноценно

Общий acceptance первого этапа

Первый этап считается завершённым, когда:

1. Полная олимпиада проходит end-to-end в новом контуре.
2. Участник, родитель, преподаватель, helper, venue/admin и system admin имеют рабочие сценарии.
3. Регистрация поддерживает индивидуальный, родительский и organization/teacher flow.
4. Teacher conduct и venue flow работают для первого тура.
5. Activity/task structure locked до открытия тура.
6. LMS/adapter attempts и competition-facing submission refs неизменяемы после lock.
7. Проверка, score snapshots, результаты, appeals MVP и publication проходят по policy.
8. Документы формируются, хранятся и доступны по правам.
9. Все PII и official data имеют owner, retention и audit.
10. competition_group не используется как общий roster учеников.
11. Временные исключения имеют migration trigger.
12. Production runbook готов и проверен rehearsal-прогоном.

Открытые решения для обсуждения

Вопрос	Варианты	Влияние
LMS activity runtime	Минимальный LMS slice или temporary adapter	Самая важная развилка по границе delivery/checking
Task source первого запуска	Готовый task-bank или temporary content snapshot	Влияет на импорт задач, lock и будущую миграцию
Платность олимпиады	Бесплатно, ручной платёж, временный admission status, минимальный CRM payment	Определяет нужен ли CRM slice до запуска
Публичные страницы	В competitions временно или сразу через storefront-min	Определяет frontend scope и SEO
Learning Groups	Минимальный Learning Workspace slice или ручной импорт roster	Влияет на риск закрепления competition_group как roster
Official data	Какие поля обязательны для первого сезона	Влияет на identity protected attributes и privacy
Venue flow	Нужен ли в первом сезоне public venue selection	Может сильно расширить delivery scope
Appeals	Только result disagreement или больше	Влияет на checking workflow и support
Documents	Какие типы документов обязательны на первом запуске	Влияет на генератор и шаблоны
Мир Олимп	Новый сезон, архив, импорт задач, импорт результатов, hybrid	Влияет на task source, LMS binding, data migration, архив и документы

Следующие шаги

1. Утвердить, что этот документ заменяет прежнюю последовательную стратегию как план первого этапа.
2. Утвердить LMS activity runtime path: минимальный LMS slice или temporary LMS-compatible activity adapter.
3. Выбрать task source первого запуска: готовый task-bank или temporary content snapshot без runtime внутри competitions.
4. Определить платность первого сезона и необходимость CRM slice.
5. Зафиксировать минимальный набор identity protected attributes для official registrations.
6. Принять раннее решение по “Мир Олимп” до Phase 3.
7. Решить, нужен ли venue public selection в первом запуске.
8. Разбить phases 0-10 на milestones и backlog epics.
9. Перевести ключевые решения в ADR или domain docs, если они меняют целевую модель.