Перейти к основному содержимому

Критерии готовности LMS

Зачем нужно​

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

Кто использует​

  • product;
  • education;
  • curriculum;
  • design;
  • frontend;
  • backend;
  • QA;
  • operations;
  • architecture.

Documentation gates​

Перед началом разработки должны быть согласованы:

Документация считается достаточной, если:

  • у каждой канонической сущности есть владелец;
  • все state transitions описаны;
  • API покрывает student, parent, teacher, methodist, operations и admin сценарии;
  • права доступа заданы не только ролями, но и контекстами;
  • события не содержат приватный payload;
  • тест-план покрывает state machines, integrations, security и E2E.

Границы домена​

Готово, если:

  • LMS не создаёт identity user и не хранит роли входа;
  • LMS не считает оплату и не принимает payment fact без CRM source;
  • task-bank остаётся владельцем задач, решений и checker;
  • storefront получает только публичные projections курсов;
  • management получает агрегаты и события, но не владеет учебными фактами;
  • progress LMS не смешан с roadmap mastery;
  • attendance не считается completion без явного evidence rule;
  • public roadmap projection не содержит PII, progress, attendance, purchases или private recommendations;
  • storefront не рассчитывает roadmap progress или completion;
  • topic completion создаётся только по rule или audited manual override;
  • entry_requirements и catchup не становятся admission/completion gate;
  • Learning Group не смешан с live group/session, enrollment или canonical student registry;
  • тренировочная попытка и разбор олимпиады не смешаны с competition submission/result.

Course и content versioning​

Готово, если:

  • можно создать course;
  • можно создать draft course version;
  • можно собрать дерево course, module, lesson, block;
  • структура допускает вложенность глубже course -> module -> lesson;
  • content block валидируется по типу;
  • task-bank references проверяются перед публикацией;
  • published version immutable;
  • новая правка опубликованного курса создаёт новую draft version;
  • enrollment привязан к конкретной course version;
  • retired version остаётся доступна текущим ученикам.

Enrollment и доступ​

Готово, если:

  • enrollment создаётся вручную или из CRM entitlement;
  • поддержаны состояния pending, active, paused, completed, revoked;
  • active открывает учебные действия;
  • paused закрывает новые действия, но не удаляет историю;
  • revoked закрывает доступ к контенту, но сохраняет progress, submissions и audit;
  • duplicate CRM webhook не создаёт duplicate enrollment;
  • student, parent, teacher и admin видят enrollment только по своим правилам доступа.

Learning Workspace​

Готово, если:

  • teacher mode требует выбор организации;
  • organization context валидируется через identity;
  • преподаватель видит общий список “мои ученики/мои группы” как Learning Groups;
  • Learning Group хранит participants как ссылки на student_profile_id;
  • LMS не создаёт отдельный canonical student list;
  • преподаватель может создать группу;
  • преподаватель может пригласить ученика или родителя через identity-backed invite;
  • преподаватель может назначить course, lesson, trainer, competition debrief или task-bank set группе;
  • assignment не заменяет LMS enrollment;
  • progress по группе строится только по разрешённым enrollments/course/node;
  • live course group/session не равны Learning Group.

Lessons и activities​

Готово, если:

  • ученик видит только открытые уроки;
  • locked lesson объясняет причину закрытия;
  • required и optional blocks различаются;
  • просмотр required block создаёт evidence;
  • activity можно начать, отправить, проверить и засчитать;
  • повторная попытка создаёт новую запись, а не перезаписывает старую;
  • task-bank activity не хранит answer key в LMS;
  • результат автопроверки task-bank обновляет attempt, evidence и progress.

Submissions и feedback​

Готово, если:

  • работа имеет состояния draft, submitted, in review, returned, accepted и reopened;
  • после submitted ученик не редактирует payload без reopen;
  • feedback содержит author, decision, score, rubric и visibility;
  • returned feedback виден ученику;
  • accepted feedback пересчитывает progress;
  • correction не стирает старый score и создаёт audit;
  • teacher видит только работы в assigned scope;
  • parent видит feedback ребёнка только по visibility policy.

Progress и evidence​

Готово, если:

  • lesson progress считается отдельно от course progress;
  • progress snapshot привязан к enrollment и course version;
  • evidence хранит source, payload summary и timestamp;
  • completion rules поддерживают required blocks, required activities, score threshold и manual check;
  • course completion фиксирует итоговый snapshot;
  • imported external progress хранит external source и external id;
  • конфликт внешнего и внутреннего progress не перезаписывается silently;
  • progress можно пересчитать идемпотентно.

Workbooks и projects​

Готово, если:

  • тетрадь принадлежит конкретному enrollment;
  • autosave создаёт revisions;
  • submitted revision фиксируется;
  • преподаватель комментирует конкретную revision;
  • проект имеет milestones и artifacts;
  • project milestone можно отправить и принять;
  • workbook и project могут влиять на completion через rule;
  • доступ ученика, родителя и преподавателя проверяется по контексту.

Calendar и booking​

Готово, если:

  • слот можно показать в timezone пользователя;
  • запись проверяет entitlement или active enrollment;
  • capacity проверяется транзакционно;
  • hold имеет TTL;
  • cancellation сохраняет actor и reason;
  • перенос сохраняет историю;
  • overbooking невозможен при конкурентных запросах;
  • booking events публикуются один раз.

Teacher tools и chat​

Готово, если:

  • кабинет преподавателя открывается в selected organization context;
  • teacher dashboard показывает Learning Groups, participants и assignments;
  • teacher assignment задаёт область видимости преподавателя;
  • review queue показывает только assigned submissions;
  • замена преподавателя закрывает старый assignment и создаёт новый;
  • учебный чат всегда связан с course, lesson, enrollment, project или booking;
  • сообщение доступно только участникам и разрешённым family/teacher contexts;
  • chat event не содержит body сообщения;
  • закрытый чат становится readonly и сохраняет историю.

Integrations​

Готово, если:

  • CRM webhook активирует, паузит и отзывает enrollment;
  • task-bank check result обновляет attempt и progress;
  • task-bank assignments через Learning Workspace не копируют canonical problem в LMS;
  • competitions training/debrief publication может быть назначена как LMS/training material;
  • training attempt не обновляет competition result/ranking;
  • identity family changes инвалидируют family access;
  • external LMS import создаёт sync record;
  • notifications получают только безопасный payload;
  • management получает события и агрегаты без приватных ответов ученика;
  • все webhooks проверяют signature, timestamp, replay window и idempotency.

Security​

Готово, если:

  • direct object reference к чужому enrollment возвращает отказ;
  • parent не видит ребёнка после потери family relation;
  • teacher не видит unassigned student;
  • teacher не видит group progress только из-за Learning Group membership;
  • teacher не управляет Learning Group вне выбранной организации;
  • methodist не получает student answers через content permissions;
  • operations не читает submission/chat без audited access;
  • service webhook без signature отклоняется;
  • admin private read требует reason и пишет audit;
  • published version нельзя изменить через content API;
  • chat attachments валидируются по типу, размеру и storage policy.

Observability​

Готово, если есть:

  • structured logs для state transitions;
  • audit search по actor и target;
  • metrics для event publish/consume;
  • dead-letter visibility;
  • alert на failed CRM webhook;
  • alert на failed task-bank result handling;
  • alert на external sync conflicts;
  • метрики progress recalculation latency;
  • trace correlation через request id или correlation id.

MVP acceptance​

MVP LMS считается принятым, если работают сценарии:

  • methodist создаёт draft course, добавляет уроки и публикует version;
  • CRM entitlement создаёт active enrollment;
  • teacher creates Learning Group, invites participant and assigns lesson/trainer;
  • student открывает курс, проходит урок и сдаёт работу;
  • student opens competition debrief/trainer as LMS learning material;
  • task-bank result или teacher feedback засчитывает activity;
  • training attempt updates LMS evidence/progress and does not change competition result;
  • progress обновляется и виден ученику;
  • parent видит progress своего ребёнка;
  • teacher видит очередь проверки и даёт feedback;
  • revoked enrollment закрывает доступ без потери истории;
  • admin видит audit и sync status;
  • тесты из test-plan.md проходят для включённых MVP-модулей.