Состояния LMS

Зачем нужно

Состояния LMS управляют публикацией контента, доступом ученика, сдачей работ, progress, записью на слоты и учебной коммуникацией. Любой переход должен быть проверяемым, аудируемым и воспроизводимым.

Общие требования

• Запрещены неявные переходы через прямой update статуса.
• Переход должен иметь actor, timestamp, reason или source event.
• Переход, который меняет учебное состояние, публикует событие.
• Invalid transition возвращает 409 conflict.
• Idempotency key обязателен для команд, которые могут быть повторены клиентом или webhook.

Course

draft -> review -> published -> archived
draft -> archived
review -> draft
review -> archived

Правила

Переход	Кто может	Проверки
draft -> review	методист	есть структура, нет пустых обязательных блоков
review -> draft	методист, reviewer	указана причина возврата
review -> published	lms.courses.publish	version валидна, нет битых references
published -> archived	admin	нет новых продаж или есть migration plan
draft -> archived	автор, admin	нет active enrollments

После публикации редактирование course version запрещено.

Course version

draft -> review -> published -> retired
review -> draft
draft -> retired

Инварианты

• У course может быть несколько published versions.
• У course может быть не более одного active draft, если продуктовый процесс не требует parallel drafts.
• Published version immutable.
• Retired version не выдаётся новым enrollments, но доступна ученикам, которые уже учатся по ней.

Публикация

Публикация должна:

1. проверить дерево на циклы;
2. проверить типы и схемы content blocks;
3. проверить task-bank references;
4. рассчитать content_hash;
5. поставить published_at;
6. создать audit;
7. опубликовать lms.course_version.published.

Enrollment

pending -> active -> paused -> active -> completed
pending -> revoked
active -> revoked
paused -> revoked
completed -> revoked

Правила

Переход	Источник	Эффект
pending -> active	CRM entitlement, manual admin, migration	открывает доступ
active -> paused	CRM pause, manual admin	закрывает новые учебные действия
paused -> active	CRM resume, manual admin	возвращает доступ
active -> completed	progress engine	фиксирует completion snapshot
`pending	active	paused -> revoked`
completed -> revoked	refund, abuse, admin	скрывает доступ к контенту, история остаётся

Запрещено

• удалять enrollment с history;
• переводить revoked -> active без нового audit reason;
• менять course_version_id без migration record;
• считать completed, если required activity не выполнены.

Lesson progress

not_started -> in_progress -> completed
in_progress -> needs_review -> completed
completed -> needs_review
needs_review -> in_progress

Правила

• not_started -> in_progress происходит при первом meaningful event: open lesson, view required block, start attempt.
• in_progress -> completed требует completion rule конкретного node.
• needs_review используется, если progress зависит от teacher check.
• Возврат из completed допустим только при изменении published rules через migration или при отмене feedback с audit.

Topic progress

not_started -> available -> in_progress -> ready_for_completion -> completed
not_started -> gap
available -> gap
gap -> in_progress
in_progress -> needs_review -> ready_for_completion
ready_for_completion -> needs_review
completed -> enrichment
enrichment -> completed

Правила

• topic_progress относится к student_profile и roadmap_topic.
• available означает, что тема доступна как следующий или возможный шаг.
• gap означает, что topic нужен для входа или догона, но не является запретом на покупку или enrollment.
• ready_for_completion означает, что evidence собрано, но completion rule ещё не применено.
• completed не возвращается в in_progress из-за повторного прохождения темы другим pathway или track.
• Повторное прохождение после completion создаёт topic_enrichment и новое evidence, но не открывает тему обратно.
• enrichment не влияет на core completion и может использоваться для углубления, олимпиадного слоя или дополнительной практики.

Topic completion

draft -> approved
draft -> rejected
approved -> corrected

Правила

• Completion не сводится к XP, attendance или одному score.
• MVP может использовать бинарное решение approved/rejected, но rule version обязателен.
• Correction создаёт новую запись или correction record и не стирает исходное решение.
• Manual override требует actor, permission, reason, evidence refs, old state, new state и audit record.
• Attendance, lesson completion, homework, task-bank result, diagnostic или competition result могут быть evidence, но не создают completion напрямую без rule.

Session

planned -> confirmed -> in_progress -> completed
planned -> cancelled
confirmed -> cancelled
confirmed -> rescheduled -> confirmed
confirmed -> missed
in_progress -> completed

Правила

• planned создаётся расписанием или ручным действием координатора.
• confirmed означает, что время, преподаватель, группа/ученик и room зафиксированы.
• rescheduled требует ссылку на новую session или session_change.
• Замена преподавателя/room фиксируется через session_change, а не перезаписью session без истории.
• completed не означает mastery и не списывает entitlement напрямую.

Attendance

expected -> present
expected -> absent
expected -> late
expected -> excused_absence
expected -> cancelled
absent -> makeup_planned -> makeup_completed
late -> present

Правила

• Attendance фиксирует факт участия в session и не равен topic_completion.
• excused_absence может породить makeup, но не делает session completed за ученика.
• makeup_planned и makeup_completed относятся к компенсации attendance, а не к изменению исходной session.
• cancelled используется, когда attendance больше не ожидается из-за отмены session или ошибочно созданной записи.

Makeup assignment

planned -> scheduled -> completed
planned -> cancelled
scheduled -> cancelled

Правила

• Makeup связывает исходную session и replacement session, если replacement уже известен.
• Отмена или перенос session не являются makeup assignment сами по себе.
• Completion makeup может стать evidence для attendance/progress только по явной policy.

Activity attempt

started -> submitted -> checking -> checked -> accepted
checked -> returned
submitted -> accepted
submitted -> returned
started -> cancelled
returned -> started

Правила

Состояние	Значение
started	ученик начал попытку
submitted	ответ отправлен и больше не редактируется
checking	идёт автопроверка или ручная проверка
checked	результат получен, но решение ещё не применено
accepted	activity засчитана
returned	нужна доработка или не засчитано
cancelled	попытка отменена системой или admin

Повторная попытка создаёт новую запись с новым attempt_no, а не перезаписывает старую.

Submission

draft -> submitted -> in_review -> accepted
in_review -> returned -> reopened -> submitted
submitted -> in_review
submitted -> accepted
submitted -> returned

Правила

• draft может редактировать только владелец или сервис autosave.
• После submitted ученик не меняет payload.
• returned должен иметь feedback visible to student.
• accepted пересчитывает progress.
• reopened требует reason и audit.

Feedback

Feedback не удаляется физически. Для исправлений создаётся новая версия feedback или correction record.

draft -> published -> corrected
published -> hidden
hidden -> published

Правила

• Published feedback может изменить progress.
• Hidden feedback не виден ученику, но остаётся в audit.
• Correction не стирает старый score.

Workbook

active -> submitted -> reviewed
reviewed -> active
active -> archived
submitted -> active

Правила

• Autosave создаёт revisions.
• submitted фиксирует revision.
• Преподаватель комментирует конкретную revision.
• Возврат к active открывает новую revision, не меняя отправленную.

Course project

not_started -> active -> submitted -> in_review -> completed
in_review -> returned -> active
active -> paused -> active
active -> cancelled

Правила

• Milestone completion может быть обязательным для course completion.
• Project artifact не удаляется после завершения enrollment.
• cancelled требует reason.

Booking slot

available -> held -> booked -> completed
booked -> cancelled
held -> available
available -> cancelled
booked -> missed

Правила

• held имеет TTL.
• booked проверяет capacity в транзакции.
• cancelled сохраняет actor и reason.
• missed не является автоматическим academic failure, но может быть evidence.

Chat thread

open -> readonly -> closed -> archived
open -> closed
readonly -> open

Правила

• В open участники могут писать по правам.
• В readonly можно читать, но нельзя писать.
• В closed история доступна по политике хранения.
• В archived thread скрыт из активных списков, но доступен для audit roles.

External sync record

queued -> running -> succeeded
running -> failed -> queued
succeeded -> reconciled
succeeded -> conflicted -> reconciled

Правила

• Повторный sync должен быть idempotent.
• Conflict не перезаписывает внутренний progress без отдельного решения.
• reconciled публикует событие только при изменении внутреннего факта.

Ошибки переходов

Ошибка	HTTP	Пример
invalid transition	409	completed -> active без reopen command
missing permission	403	ученик пытается проверить submission
stale version	409	публикация draft с устаревшим revision
broken reference	422	task-bank problem не найден
entitlement missing	403	попытка открыть курс без active enrollment

Тестовые требования

Для каждой state machine должны быть unit-тесты:

• все разрешённые переходы;
• все запрещённые переходы;
• idempotent repeat;
• audit creation;
• event emission;
• permission checks;
• race condition для booking и submission.