Competitions-first MVP launch plan

Зачем нужно

Документ фиксирует development slice для запуска первой полноценной олимпиады до готовности всей экосистемы. Он не меняет целевую архитектуру: identity остаётся владельцем организаций и доступа, task-bank остаётся владельцем канонических задач, LMS activity runtime остаётся владельцем выполнения заданий, CRM/storefront/management подключаются фазами.

Минимально обязательный foundation

До production-запуска олимпиады должны быть готовы:

• identity auth, users, sessions, JWKS/OAuth для service-to-service;
• identity organization-lite: organization, organization_membership, roles owner/admin/member, organization_invitations;
• organization_student для добавления учеников организацией;
• Learning Workspace / Learning Group read API для выбора групп преподавателя;
• permissions catalog keys для teacher mode, выбранной организации и competitions;
• competitions event/season/tour/track lifecycle;
• competitions participants, two-step registrations, Learning Group snapshots, activity bindings, competition-facing submission refs, score snapshots, results, publications and audit;
• minimal LMS activity runtime contract or temporary LMS-compatible activity adapter for competition delivery;
• official data package readiness flow through identity protected attributes for official registrations;
• teacher mode with selected organization, limited helpers and venue sublayer;
• teacher conduct applications and teacher materials for first-tour operations;
• venue applications, public venue list/map, venue selection and capacity guard;
• базовые notifications для регистрации, допуска, результатов и документов.

Временные исключения

Зависимость	MVP rule	Migration trigger
LMS activity runtime	Temporary LMS-compatible activity adapter разрешён только для первого запуска	LMS supports competition/training/review activity modes, attempts, responses, files, checking result and score by item
task-bank	Temporary content snapshot/source refs разрешены только внутри activity adapter; task-bank не является runtime	task-bank supports problem version, answer policy and usage/source refs for LMS activity
storefront	Public competition pages and result pages may be hosted by competitions	storefront public pages/read-model ready
CRM	payment_status allowed as competitions-owned admission/status field, not commercial source of truth	CRM order/payment/entitlement flow ready
Learning Workspace	Read-only Learning Group access is enough; competitions stores season snapshots only	full workspace ownership and sync events ready
LMS	Competition delivery uses minimal LMS activity contract or compatible adapter; training links can be simple external refs until full LMS trainer is ready	training/learning path and trainer attempts live in LMS
management	Not required for first olympiad release	operational dashboards and cross-domain metrics ready

Temporary activity adapter rules

• Temporary adapter is explicit and auditable: activity_binding.mode = 'temporary_adapter'.
• Adapter follows the future LMS activity contract: activity, activity item, attempt, response, file response, checking result, score by item.
• Adapter stores only locked activity snapshot for a concrete tour; it does not create a task library inside competitions.
• Content source refs may point to task-bank or a temporary content snapshot, but runtime execution stays LMS-compatible.
• Changing activity/task structure after lock requires a new version or admin override with audit reason.
• Adapter is migrated to LMS activity runtime as a post-MVP phase; historical results continue to use locked score snapshots.

Teacher/Learning Group flow

1. Teacher enters teacher mode and selects identity organization.
2. Learning Workspace returns available Learning Groups and members.
3. Competitions creates competition_group as season-specific snapshot/registration projection.
4. Competitions creates competition_participant records with organization_student_id, identity_organization_id, optional organization_membership_id, learning_group_id and member snapshots.
5. Registration creates season/tour participation.
6. Child or parent can later claim access through competition_access_claim.
7. Optional link to student_profile_id or identity_user_id happens after claim approval.

Automatic merge between organization_student, family student_profile and competition_participant is forbidden. Similar records go to review/claim flow.

Competitions must not expose competition_group as a general student roster. Any "my students" view comes from Learning Workspace / Learning Group.

Registration MVP rules

• Registration is two-step: pre-registration first, completion/approval second.
• Parent can register a child, but the olympiad attempt opens in child mode.
• Official data package appears only for an official scenario defined by season registration policy.
• Official data package includes child SNILS, child birth date, parent email and parent phone, and is collected through identity protected attributes.
• Teacher manual entry is allowed only through a permitted official flow and may create pending parent contact/invite without granting parent rights to the teacher.
• Free-text "teacher" is saved for display/contact context only and does not create an access link.

Teacher conduct and materials MVP rules

• Teacher conduct application is a separate “Провести Олимпиаду” flow and does not replace student registration.
• MVP statuses for conduct application: submitted, approved, cancelled, completed; draft, needs_changes and rejected may be added without changing the model.
• approval_required is policy-based. In an ordinary first tour, submitted may be enough for registration actions and open materials.
• approved is required only for policy scenarios: closed material early access, official final, open venue or risk/admin review.
• После submitted или approved согласно policy преподаватель всё равно выбирает Learning Group, создаёт competition_group snapshot и регистрирует учеников.
• Teacher materials cover poster/banner, announcement text, teacher/student/parent instructions, tour materials, participant list, report template, photo report, result news and gratitude documents.
• Teacher materials open by season/tour status, visibility and availability window; closed material access is audited.

Delivery MVP rules

• First tour supports group answer submission by teacher/helper with explicit warning before lock.
• First-tour teacher-led delivery is linked to teacher conduct application when the teacher submitted one.
• Student and teacher delivery write to LMS activity runtime or temporary compatible adapter.
• Competitions stores submission/attempt refs, status and score snapshots; raw answers live in LMS/runtime where possible.
• Submitted students are locked; new students can be sent before tour close when season policy allows it.
• Final tour materials open by time window, even if final is the only tour.
• Final MVP accepts file/zip/image uploads without mandatory per-student binding; late upload is marked and audited.
• Photo report status is submitted, confirmed or unconfirmed with comment and may reference venue, competition group or teacher conduct application.

Venue MVP rules

• Venue application is required before public venue selection.
• Venue application includes participant-facing arrival conditions: entrance rules, required documents, guardian policy, shoe/food/water rules, arrival time, accessibility notes and public comment.
• Printing/scanning capabilities and admin internal comment are private/admin fields and are not sent to storefront public projections.
• Approved venues can be published as list, map or both.
• Participants can choose/change venue until selection closes or an admin rule applies.
• Capacity cannot be reduced below current active assignments without admin process.

Result and document MVP rules

• Checking may run in LMS activity runtime or temporary adapter.
• Competitions consumes score by item and stores immutable score snapshots.
• MVP appeals cover result/check disagreement only.
• Suspicious work arbitration is a separate admin workflow and can withhold a result.
• Award thresholds can use percentage-oriented guidelines, but publication requires manual approval.
• Result finalization is separate from personal/public publication.
• Award statuses use the detailed list: diploma_1, diploma_2, diploma_3, honorable_mention_1, honorable_mention_2, participation_certificate, no_award.
• Results are published by class and track; withheld results are excluded.
• Documents use the common document contour, including gratitude letters for helpers, team, organization and venue.

Minimal notification adapter

Полноценный notification domain не блокирует первый запуск, но competitions должен публиковать минимальные triggers раньше launch hardening:

• registration started / registration incomplete;
• missing official data package;
• upcoming tour;
• teacher conduct application submitted;
• teacher/group answer submission reminder;
• photo report reminder;
• results published;
• document ready;
• venue confirmed or venue status changed.

Organization merge behavior

On identity.organization.merged:

• historical participants, submissions, results and documents remain unchanged;
• new registrations use primary identity_organization_id;
• existing competition_organization snapshots remain historical records;
• admin may explicitly relink season projection if the season is still active;
• published results and documents are not regenerated solely because of organization merge.

Out of scope for first launch

• full task-bank editor;
• full LMS training journeys and progress outside the minimal activity runtime/adapter;
• management dashboards;
• full CRM lifecycle;
• storefront as canonical public read-model;
• complex organization teams and fine-grained grants beyond required organization roles.
• per-file mandatory student matching for final-tour MVP bulk uploads.

Exit criteria

The MVP exception is closed when:

• competition delivery uses LMS activity runtime instead of temporary adapter;
• temporary content snapshots from launch seasons are migrated to task-bank or archived with traceability;
• competition results remain reproducible through locked activity structure and score snapshots;
• public pages are served through storefront read-model;
• paid seasons use CRM entitlement/payment events;
• Learning Workspace remains canonical owner of groups and rosters;
• LMS/storefront own training experience and public pages;
• development-order can return to the full ecosystem sequence without MVP exceptions.