Форматы проведения, ответы и сканы

Зачем нужно

Документ описывает, как участник проходит тур олимпиады, конкурса или другого соревнования через LMS activity runtime или temporary compatible adapter, как отправляет ответы, как загружаются фото и сканы работ, и как участник затем может посмотреть свою работу в личном кабинете.

В execution-контуре есть два базовых режима отправки работы:

• тестирование, где ответ может проверяться автоматически;
• письменная работа, где участник, преподаватель, помощник, площадка или администратор загружает фото, скан или файл решения.

Competitions не владеет полноценным runtime выполнения заданий. Он проверяет допуск, открывает LMS/adapter activity, хранит competition-facing refs/status, получает score by item и snapshots итоговые баллы.

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

Что входит

Документ фиксирует:

• различие между TourFormat, DeliveryMode, LMS/adapter Attempt и competition-facing SubmissionRef;
• онлайн-прохождение учеником;
• детский режим для ребёнка, зарегистрированного родителем;
• очное проведение через преподавателя и Learning Group snapshot;
• очное проведение на площадке;
• отправку ответов по группе в первом туре с lock;
• досылку новых учеников до окончания окна тура;
• тестовые ответы внутри LMS/runtime или temporary adapter;
• числовые и короткие текстовые ответы;
• выбор варианта ответа;
• загрузку файлов, фото и сканов;
• MVP-загрузку файлов, zip и изображений финала без обязательной привязки каждого файла к ученику;
• фотоотчёт со статусами submitted/confirmed/unconfirmed;
• роли, которые могут отправлять ответы и загружать работы;
• просмотр своей работы после отправки или проверки;
• статусы попытки, отправки и просмотра работы;
• требования к аудиту.

Что не входит

Документ не проектирует подробно:

• банк задач и внутреннюю структуру заданий;
• критерии проверки и работу жюри;
• полноценные апелляции;
• расчёт финального рейтинга;
• генерацию дипломов;
• UI-макеты;
• финальные API-контракты.

4. Главный принцип модели

Нельзя смешивать четыре уровня:

Уровень	Что означает	Пример
TourFormat	что сдаёт участник	тест, письменная работа, смешанный формат
DeliveryMode	где и через кого проходит тур	онлайн, у учителя, на площадке
ActivityAttempt	факт прохождения тура конкретным участником в LMS/runtime	попытка с таймером и событиями
SubmissionRef	competition-facing ссылка/статус отправленной работы	LMS attempt ref, adapter ref, accepted status
PhotoReport	отчёт о проведении	фото аудитории/площадки после тура

TourFormat описывает формат работы. DeliveryMode описывает контекст проведения. ActivityAttempt фиксирует прохождение в LMS/runtime. Competition SubmissionRef фиксирует ссылку, статус, lock и audit для соревновательного lifecycle.

5. Основные сущности

Сущность	Назначение
ActivityAttempt	LMS/adapter попытка прохождения тура участником
AttemptEvent	событие внутри попытки в runtime
SubmissionRef	competition-facing ссылка/статус работы
AnswerSubmission	структурированные ответы внутри LMS/runtime
AnswerItem	отдельный ответ на отдельное задание внутри LMS/runtime
FileSubmission	загруженный файл в LMS/adapter/storage policy
ScanSubmission	фото или скан письменной работы в LMS/adapter/storage policy
SubmissionActor	кто отправил работу
WorkReviewAccess	право участника смотреть свою работу
WorkReviewPublication	публикация работ для просмотра

6. Attempt

Attempt — факт прохождения конкретного тура конкретным участником в LMS activity runtime или temporary compatible adapter.

Attempt создаётся для TourParticipation, когда участник начинает прохождение или когда преподаватель, помощник, площадка или администратор фиксирует работу за участника. Competitions инициирует или получает этот attempt, но хранит только refs/status/snapshots.

Поле	Описание
id	уникальный идентификатор
tour_participation_id	участие в туре
tour_id	тур
student_record_id	запись ученика
delivery_mode	способ прохождения
tour_format	формат тура на момент попытки
started_by_user_id	кто начал попытку
started_at	дата и время начала
finished_at	дата и время завершения
duration_limit_minutes	ограничение по времени, если есть
status	статус попытки
technical_status	технический статус, если нужен

Статусы Attempt:

Статус	Значение
created	попытка создана
ready	попытка готова к началу
in_progress	участник проходит тур
submitted	работа отправлена
expired	время истекло
cancelled	попытка отменена
invalidated	попытка признана недействительной
locked	попытка заблокирована от изменений

Правила:

1. Attempt всегда связан с TourParticipation через competition-facing ref.
2. В большинстве олимпиад у участника должна быть одна основная попытка на тур.
3. Повторная попытка возможна только по специальному правилу или административному решению.
4. Завершённая и заблокированная Attempt не должна изменяться без аудита.
5. Таймер и ограничения берутся из TourWindow, Tour или специальных правил сезона.
6. Если регистрацию создал родитель, Attempt для олимпиадного прохождения должен открываться в child mode.

7. AttemptEvent

AttemptEvent фиксирует технические и пользовательские события внутри попытки.

Поле	Описание
id	уникальный идентификатор
attempt_id	попытка
event_type	тип события
actor_user_id	пользователь, если событие связано с действием пользователя
occurred_at	дата и время события
metadata	дополнительные данные

Типы событий:

Тип	Значение
started	попытка начата
answer_saved	ответ сохранён
file_uploaded	файл загружен
submission_submitted	работа отправлена
timer_expired	время истекло
autosave_failed	автосохранение не удалось
connection_lost	потеря соединения
connection_restored	соединение восстановлено
admin_unlocked	администратор разблокировал попытку
invalidated	попытка признана недействительной

Правила:

1. События не заменяют аудит, но могут использоваться как техническая история попытки.
2. События, влияющие на результат, должны также попадать в AuditLog.
3. AttemptEvent нужен для разбора технических инцидентов.

8. Submission

Submission — отправленная работа или набор ответов по Attempt в LMS/runtime. В competitions этому соответствует competition_submission как ref/status, а не raw answer container, если execution LMS-owned.

Поле	Описание
id	уникальный идентификатор
attempt_id	попытка
tour_participation_id	участие в туре
submitted_by_user_id	кто отправил
submission_actor_type	участник, родитель, преподаватель, помощник, площадка, администратор, система
submission_type	тестовые ответы, файлы, сканы, смешанная отправка
status	статус отправки
submitted_at	дата отправки
locked_at	дата блокировки от изменений
replaced_by_submission_id	новая версия, если работа заменена

Статусы Submission:

Статус	Значение
draft	работа сохраняется, но ещё не отправлена
submitted	работа отправлена
received	работа принята системой
processing	файлы обрабатываются
accepted	работа принята к проверке или расчёту
rejected	работа отклонена
replaced	работа заменена новой версией
locked	работа заблокирована от изменений

Правила:

1. Runtime Submission или competition-facing ref должны хранить, кто именно отправил работу.
2. Если преподаватель, помощник или площадка отправляет работу за ученика, это должно быть явно видно в данных и аудите.
3. Изменение отправленной работы после дедлайна требует правила или административного действия.
4. Замена работы не должна удалять старую версию без следа.
5. Для проверки используется актуальная принятая версия Submission в LMS/runtime или adapter.
6. Для первого тура group submit блокирует отправленные работы учеников после явного подтверждения.
7. Заблокированные работы нельзя редактировать, но новых учеников можно дослать до закрытия окна тура, если это разрешает season policy.

9. AnswerSubmission и AnswerItem

AnswerSubmission в этом разделе описывает runtime-side структуру LMS/adapter. В competitions остаётся только submission ref/status и score snapshots.

AnswerItem — отдельный ответ на отдельное задание в LMS/runtime. Competitions получает item score snapshots, а не raw answers.

Поле AnswerSubmission	Описание
id	уникальный идентификатор
submission_id	отправка
activity_binding_ref	ссылка на LMS activity или temporary adapter binding
auto_check_status	статус автоматической проверки
total_auto_score	сумма баллов автоматической проверки

Поле AnswerItem	Описание
id	уникальный идентификатор
answer_submission_id	набор ответов
activity_item_ref	LMS/adapter item ref
answer_type	тип ответа
selected_option_id	выбранный вариант, если есть
answer_value	введённое значение, если есть
normalized_answer_value	нормализованное значение для проверки
is_correct	результат автоматической проверки, если применимо
score	баллы за ответ
checked_at	дата проверки

Типы answer_type:

Тип	Описание
single_choice	выбор одного варианта
multiple_choice	выбор нескольких вариантов, если будет включено
numeric	числовой ответ
short_text	короткий текстовый ответ
external	ответ во внешней системе или по внешнему правилу

Правила:

1. В первой версии обязательны single_choice, numeric и short_text.
2. Вариант ответа может содержать текст, число или изображение.
3. Multiple choice можно заложить как расширение, даже если он не входит в первую реализацию.
4. Нормализация числовых и текстовых ответов должна быть явно описана в правилах проверки.
5. AnswerItem может быть проверен автоматически, вручную или через смешанную схему.

10. FileSubmission и ScanSubmission

FileSubmission — загруженный файл работы.

ScanSubmission — специализация или пометка файла как фото или скана письменной работы.

Поле	Описание
id	уникальный идентификатор
submission_id	отправка
uploaded_by_user_id	кто загрузил файл
file_type	фото, PDF, скан, архив, другой файл
original_filename	исходное имя файла
storage_file_id	ссылка на хранилище
participant_id	участник, если файл привязан к конкретному ученику
is_late	файл загружен после основного окна
late_reason	причина поздней загрузки
page_count	число страниц, если известно
processing_status	статус обработки
checksum	контрольная сумма, если используется
uploaded_at	дата загрузки

Статусы processing_status:

Статус	Значение
uploaded	файл загружен
virus_checking	идёт проверка безопасности
processing	идёт обработка
ready	файл готов к просмотру и проверке
failed	обработка не удалась
rejected	файл отклонён

Правила:

1. Система должна поддерживать фото и PDF-сканы письменных работ.
2. Файлы могут загружать ученик, преподаватель, помощник, площадка или администратор, если это разрешено правилами тура.
3. Каждая загрузка должна иметь автора и время загрузки.
4. Повторная загрузка после дедлайна требует отдельного правила.
5. Проверяющий должен работать с принятой версией файла.
6. Участник должен иметь возможность увидеть свою работу, если открыта публикация просмотра работы.
7. Для финального тура MVP допускает загрузку файлов, zip и изображений без обязательной привязки каждого файла к ученику.
8. Поздняя загрузка должна быть помечена is_late и отражена в аудите.

11. Кто может отправлять ответы и загружать работы

Актор	Что может отправлять
Ученик	свои тестовые ответы, файлы и сканы, если это разрешено форматом тура
Родитель	может зарегистрировать и дозаполнить данные ребёнка; отправка за ребёнка только если регламент явно разрешает
Преподаватель	ответы и сканы учеников своего CompetitionGroup snapshot при очном проведении
Помощник	только выданные действия: answers entry или file upload
Административный подслой	материалы по нескольким snapshots, если роль это разрешает
Площадочный подслой	работы участников, назначенных на площадку
Администратор «Систематики»	может загрузить, заменить или исправить работу с аудитом
Система	может автоматически отправить черновик при истечении времени, если так настроено

Правила:

1. У каждого Submission должен быть submission_actor_type.
2. Отправка за участника не должна выглядеть как отправка самим участником.
3. Права на отправку зависят от TourParticipation, DeliveryMode, роли пользователя и окна проведения.
4. После публикации результатов изменение Submission должно быть запрещено или требовать специального административного процесса.

12. Онлайн-прохождение учеником

Сценарий:

1. Ученик входит в личный кабинет.
2. Система проверяет TourParticipation, допуск, окно проведения и выбранный DeliveryMode.
3. Ученик открывает тур.
4. Competitions создаёт или получает LMS/adapter ActivityAttempt.
5. Запускается таймер, если он предусмотрен.
6. Ученик заполняет ответы или загружает файлы.
7. Система сохраняет черновики или промежуточные ответы.
8. Ученик отправляет работу.
9. Runtime submission получает статус submitted или accepted.
10. Competitions сохраняет submission/attempt refs и status snapshot.
11. Attempt блокируется от дальнейших изменений.

Правила:

1. Ученик не может начать тур вне разрешённого окна.
2. Если время истекло, система должна применить правило тура: автоотправка, блокировка или специальная обработка.
3. Повторный вход в тур должен восстанавливать текущую LMS/adapter Attempt, если она ещё активна.
4. Технические сбои должны фиксироваться в AttemptEvent.

13. Очное проведение через преподавателя

Сценарий:

1. Преподаватель выбирает организацию.
2. Если сезон требует операционный контроль, преподаватель подаёт TeacherConductApplication на проведение тура.
3. После submitted или approved согласно policy преподаватель выбирает Learning Group и CompetitionGroup snapshot.
4. Система выдаёт материалы только в разрешённое окно тура.
5. Преподаватель проводит тур очно в разрешённый период.
6. После проведения преподаватель открывает список участников snapshot.
7. Для каждого ученика преподаватель или помощник вносит ответы или загружает сканы.
8. Перед пакетной отправкой UI показывает предупреждение: число отправляемых учеников, пустые ответы и необратимость lock.
9. Система создаёт LMS/adapter Attempt и Submission за участника или использует заранее созданные записи.
10. В runtime submission и competition-facing refs фиксируется, что отправитель — преподаватель или помощник.
11. Результаты после проверки или автопроверки возвращаются как score by item и snapshots в competitions.

Правила:

1. Преподаватель может отправлять работы только по ученикам своих Learning Groups/CompetitionGroup snapshots, если нет расширенной роли.
2. Преподавательская отправка должна быть аудируемой.
3. Внутри одной группы часть учеников может проходить онлайн самостоятельно, а часть — очно через преподавателя.
4. Преподаватель не должен иметь возможность изменить работу после блокировки без специального права.
5. В первом туре уже отправленные ученики lock, но новых учеников можно дослать до окончания окна, если policy разрешает.
6. TeacherConductApplication не заменяет регистрацию учеников и не создаёт участников автоматически.
7. Фотоотчёт может ссылаться на заявку на проведение, CompetitionGroup snapshot и/или площадку.

14. Очное проведение на площадке

Сценарий:

1. Участник выбирает площадку или назначается администратором.
2. Площадочный подслой получает список участников.
3. Участник приходит на очный тур.
4. Площадка отмечает явку, если этот процесс включён.
5. После проведения площадка загружает работы или передаёт их администратору.
6. Для каждого участника создаётся или обновляется LMS/adapter Submission и competition-facing ref.
7. Работы уходят на проверку.

Правила:

1. Площадочный подслой видит только участников, назначенных на неё.
2. Площадка может загружать работы только для своих назначенных участников.
3. Если организация совмещает свои группы и открытую площадку, внешние участники отделяются от своих учеников.
4. Загрузка работ площадкой должна быть аудируемой.

15. Смешанный формат тура

Смешанный формат означает, что в одном туре могут быть и структурированные ответы, и файлы или сканы.

Примеры:

• участник отвечает на тестовые вопросы и прикладывает решение;
• часть задач проверяется автоматически, часть вручную;
• преподаватель вносит ответы по тестовой части и загружает сканы письменной части.

Правила:

1. LMS/adapter Submission может содержать AnswerSubmission и FileSubmission одновременно.
2. Статусы автоматической и ручной проверки должны храниться отдельно.
3. Финальный балл не должен считаться завершённым, пока не обработаны все обязательные части.

16. Финальный тур и пакетная загрузка MVP

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

Для MVP допустима пакетная загрузка файлов, zip и изображений:

• преподавателем;
• помощником с file_upload;
• площадочным подслоем;
• администратором «Систематики».

Правила:

1. Привязка файла к ученику желательна, но не обязательна для MVP.
2. Если файл загружен после окна, сохраняются is_late, причина и actor.
3. Пакетная загрузка не должна автоматически создавать баллы без проверки.
4. Разбор пакета и привязка к участникам может быть административным post-processing шагом.

17. PhotoReport

PhotoReport фиксирует фотоотчёт преподавателя или площадки после проведения.

Поле	Описание
id	уникальный идентификатор
tour_id	тур
venue_id	площадка, если применимо
competition_group_id	snapshot, если отчёт по группе
teacher_conduct_application_id	заявка преподавателя на проведение, если применимо
submitted_by_user_id	кто отправил
file_refs	ссылки на загруженные фото
status	submitted, confirmed, unconfirmed
comment	комментарий проверяющего

Правила:

1. submitted означает, что отчёт отправлен.
2. confirmed означает, что отчёт принят.
3. unconfirmed требует комментарий.
4. Фотоотчёт не меняет результат участника.
5. Фотоотчёт может использоваться для операционного статуса проведения и благодарственных писем.

18. WorkReviewPublication

WorkReviewPublication описывает, когда участник может посмотреть свою работу.

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

Поле	Описание
id	уникальный идентификатор
competition_season_id	сезон
tour_id	тур
result_track_id	зачёт, если правило отличается по зачётам
opens_at	когда открывается просмотр
closes_at	когда закрывается просмотр, если закрывается
visible_materials	что показывать
status	статус публикации просмотра

Возможные visible_materials:

Материал	Описание
submitted_answers	отправленные тестовые ответы
uploaded_scans	загруженные фото и сканы
auto_scores	баллы автоматической проверки
final_scores	финальные баллы
checker_comments	комментарии проверяющего, если разрешено
criteria	критерии проверки, если разрешено

Статусы:

Статус	Значение
draft	правило просмотра готовится
scheduled	публикация запланирована
open	просмотр открыт
closed	просмотр закрыт
cancelled	публикация отменена

Правила:

1. Просмотр работы не равен публикации публичных результатов.
2. Участник может видеть только свою работу.
3. Родитель видит работу ребёнка по правилам семейного доступа.
4. Преподаватель может видеть работы учеников своего CompetitionGroup snapshot, если это разрешено ролью и настройками сезона.
5. Площадка не должна автоматически видеть работы после загрузки, если это не требуется процессом.

19. WorkReviewAccess

WorkReviewAccess фиксирует право конкретного акторского контекста смотреть работу.

Поле	Описание
id	уникальный идентификатор
submission_id	работа
student_record_id	ученик
actor_type	ученик, родитель, преподаватель, помощник, площадочный подслой, администратор
actor_user_id	пользователь, если применимо
access_context	личный, семейный, преподавательский, helper, площадочный, административный
granted_reason	причина выдачи доступа
starts_at	начало доступа
ends_at	конец доступа, если есть
status	статус доступа

Правила:

1. Доступ к работе должен выводиться из правил, но может фиксироваться явно для аудита.
2. Ученик, получивший аккаунт после загрузки работы учителем, должен получить доступ к своей работе.
3. Доступ учителя зависит от группы, сезона и роли.
4. Доступ администратора должен быть аудируемым.

20. Статусная модель: отправка работы

Состояние	Значение
attempt_ready	попытка готова
attempt_in_progress	попытка идёт
draft_saved	черновик сохранён
submitted	работа отправлена
received	работа получена системой
processing	файлы или ответы обрабатываются
accepted	работа принята
locked	работа заблокирована от изменений
sent_to_checking	работа отправлена на проверку в LMS/runtime или adapter
scored	score by item получен и snapshot сохранён
review_open	просмотр работы открыт

21. Требования к аудиту

Аудироваться должны:

• начало LMS/adapter Attempt;
• отправка Submission или competition-facing ref;
• сохранение или изменение ответа после отправки;
• загрузка файла;
• замена файла;
• удаление или отклонение файла;
• пакетная отправка ответов по группе и подтверждение warning;
• отправка работы преподавателем или помощником за ученика;
• отправка работы площадкой за участника;
• поздняя загрузка файлов/zip/изображений;
• отправка и проверка фотоотчёта;
• ручная разблокировка LMS/adapter Attempt;
• изменение Submission после дедлайна;
• изменение ResultTrack после отправки работы;
• открытие просмотра работы;
• ручное предоставление доступа к работе;
• скачивание работы администратором, если это требуется политикой безопасности.

22. Доменные события

Событие	Когда возникает
ActivityAttemptCreated	создана LMS/adapter попытка
ActivityAttemptStarted	попытка начата
AnswerSaved	ответ сохранён
FileUploaded	файл загружен
SubmissionSubmitted	работа отправлена
GroupSubmissionSubmitted	ответы по группе отправлены
LateFilesUploaded	поздние файлы загружены
SubmissionAccepted	работа принята runtime
SubmissionRejected	работа отклонена
SubmissionLocked	работа заблокирована
ActivityAttemptExpired	время попытки истекло
WorkReviewPublished	просмотр работы открыт
WorkReviewAccessGranted	доступ к работе выдан
WorkReviewAccessRevoked	доступ к работе отозван
PhotoReportSubmitted	фотоотчёт отправлен
PhotoReportReviewed	фотоотчёт подтверждён или не подтверждён
TeacherConductApplicationSubmitted	преподаватель подал заявку на проведение
TeacherConductApplicationApproved	заявка на проведение одобрена

23. Админские требования

Администратор должен иметь возможность:

• найти LMS/adapter Attempt участника по competition-facing ref;
• посмотреть статус Attempt и SubmissionRef;
• увидеть, кто отправил работу;
• увидеть историю загрузок и замен файлов;
• увидеть поздние пакетные загрузки и файлы без привязки к участнику;
• разблокировать LMS/adapter Attempt при наличии права;
• заменить или отклонить файл с аудитом;
• открыть или закрыть просмотр работ;
• выдать или отозвать доступ к просмотру работы;
• выгрузить список участников с отсутствующими работами;
• увидеть технические события попытки.

24. Права доступа

Право	Назначение
attempt.start	начать попытку
attempt.view	посмотреть попытку
attempt.unlock	разблокировать попытку
submission.create	создать отправку
submission.submit_own	отправить свою работу
submission.submit_for_group_student	отправить работу за ученика CompetitionGroup snapshot
submission.submit_group_batch	отправить ответы по группе с lock
submission.submit_for_venue_participant	отправить работу за участника площадки
submission.bulk_files_upload	загрузить файлы/zip/изображения пакетом
submission.replace	заменить отправленную работу
submission.lock	заблокировать работу
photo_report.submit	отправить фотоотчёт
photo_report.review	подтвердить или не подтвердить фотоотчёт
work_review.publish	открыть просмотр работ
work_review.view_own	смотреть свою работу
work_review.view_child	смотреть работу ребёнка
work_review.view_group_student	смотреть работу ученика группы
work_review.admin_view	административный просмотр работы

25. Нестандартные случаи

Ситуация	Требуемое поведение
Участник потерял соединение во время онлайн-тура	фиксируется runtime AttemptEvent; попытка восстанавливается, если окно и таймер позволяют
Время истекло, а работа не отправлена	применяется правило тура: автоотправка, блокировка или специальный статус
Преподаватель или помощник отправил ответы не за того ученика	нужна административная корректировка с аудитом
Площадка загрузила нечитаемый скан	файл получает статус rejected или needs_reupload, если такой статус будет добавлен
Ученик получил аккаунт после загрузки скана учителем	ученик должен получить доступ к своей работе после связывания записи
Работа заменена после дедлайна	требуется право, причина и аудит
Финальный zip не привязан к ученикам	файл принимается в MVP, но остаётся в очереди post-processing
Фотоотчёт не подтверждён	нужен комментарий и возможность повторной отправки
Преподаватель досылает нового ученика до закрытия первого тура	разрешено только для ещё не отправленного участника и при policy allow late add
Преподаватель пытается отправить ответы без обязательной заявки на проведение	действие блокируется до approved заявки или admin override
Submission содержит тест и скан	финальная проверка ждёт обработки обеих частей в LMS/runtime или adapter
Участник пытается открыть работу до публикации просмотра	доступ запрещён
Родитель видит работу ребёнка	доступ определяется семейной группой и настройками публикации

Готовность

1. Добавить LMS/adapter ActivityAttempt contract со статусами.
2. Добавить AttemptEvent contract.
3. Добавить competition-facing SubmissionRef.
4. Добавить модели AnswerSubmission и AnswerItem в LMS/runtime или adapter.
5. Добавить модели FileSubmission и ScanSubmission в LMS/runtime или adapter.
6. Добавить поддержку submission_actor_type.
7. Добавить права отправки работы за себя, ученика CompetitionGroup snapshot и участника площадки.
8. Добавить group batch submit с warning, lock и late-add policy.
9. Добавить MVP bulk upload файлов/zip/изображений.
10. Добавить TeacherConductApplication для teacher-led первого тура.
11. Добавить PhotoReport со статусами submitted/confirmed/unconfirmed и связью с заявкой/группой/площадкой.
12. Добавить аудит отправки, замены, поздней загрузки и блокировки работы.
13. Добавить модель WorkReviewPublication.
14. Добавить модель WorkReviewAccess.
15. Добавить административный просмотр попыток, отправок и файлов.
16. Добавить базовые проверки дедлайна, таймера и окна проведения.

26. Статус документа

Документ является первой версией модели форматов проведения, ответов, файлов, сканов и просмотра работы. Следующий рекомендуемый документ: результаты, зачёты и публикация.