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

Обзор домена

Зачем нужно​

Домен банк-задач отвечает за каноническое хранение учебных задач и связанных с ними сущностей:

  • самих задач;
  • таксономии задач;
  • подборок и наборов;
  • методических шаблонов задачных активностей;
  • программ и треков из таких активностей;
  • зафиксированных snapshots для внешних доменов;
  • использования задач в разных контурах;
  • низкоуровневых попыток проверки, если ответ проходит через task-bank API;
  • normalized check results и problem-level evidence.

В терминах Миролимпа / MeraLink этот домен является системой управления задачным контентом и методическими шаблонами задачных активностей. Миролимп не вводится как отдельный technical domain: он является продуктовой и предметной реализацией task-bank.

Для платформы «Систематика» этот домен критичен, потому что позволяет видеть не только факт прохождения урока или темы, но и какие именно задачи ребёнок решал, решал ли успешно и какого они были типа и сложности.

Текущее состояние​

Сейчас в платформе уже существует отдельная система Мир Олимп, которая используется для хранения и управления олимпиадными задачами. По целевой модели она должна стать основой более широкого task bank, который будет использоваться не только в олимпиадном контуре, но и:

  • в кружках;
  • в курсах;
  • в домашних заданиях;
  • в диагностике;
  • в олимпиадах и турнирах;
  • в открытом публичном каталоге задач;
  • в тренажёрах и разборах олимпиад;
  • в программах и треках, например в 32-занятных курсоподобных последовательностях;
  • в будущих персональных рекомендациях.

Исторический фокус Миролимпа — математика и олимпиадные задачи. Target model должен сразу поддерживать мультипредметность: математику сейчас, физику следующим предметом и дальнейшие предметные области через subject-specific taxonomy, source hierarchy, answer schemas and checking.

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

В домен входят:

  • каноническая задача;
  • версии задачи и её формулировок;
  • решение, подсказки и разбор;
  • таксономия: темы, теги, сложность, типы, навыки, источники;
  • наборы задач;
  • шаблоны активностей: занятия, домашки, тренажёры, диагностики, разборы и дизайны олимпиадных туров;
  • программы и треки как последовательности activity templates;
  • public catalog metadata и public-safe projection fields;
  • locked content export snapshots;
  • связи использования задачи в уроках, домашках, олимпиадах, диагностике и занятиях;
  • low-level problem attempts и answer checks;
  • problem-level evidence.

В домен не входят:

  • канонические темы дорожной карты как учебные цели;
  • структура LMS-курса;
  • расписание занятий и посещаемость;
  • Learning Workspace: «мои ученики», «мои группы», assignments, training attempts и review sessions;
  • lesson/course/training instances, roster, enrollment, schedule и progress;
  • олимпиадные registrations, submissions, results и publication;
  • public storefront rendering, SEO delivery, lead capture и marketing analytics;
  • продуктовая упаковка;
  • итоговые рекомендации, цели семьи и диагностика — это management по ADR-027.

Ключевые принципы​

  1. Задача — first-class сущность.
    Платформа должна знать не только, что ученик “был на занятии”, но и какие конкретно задачи решал.

  2. Задача не равна теме.
    Тема дорожной карты — это учебная цель. Задача — атомарный учебный объект, который может быть evidence по теме, но не подменяет её.

  3. Задача не принадлежит одному сценарию использования.
    Одна и та же задача может использоваться:

    • в олимпиаде;
    • на занятии;
    • в домашнем задании;
    • в уроке LMS;
    • в диагностике.

  4. Использование задачи должно моделироваться явно.
    Нужна отдельная сущность problem_usage, а не implicit-связи по названиям файлов и уроков.

  5. Проверка и бизнес-попытка разделены. Task-bank может хранить problem_attempt и answer_check для воспроизводимости проверки, но LMS владеет lms_activity_attempt/learning_training_attempt, а competitions владеет competition_submission/competition_result.

  6. Task bank должен быть пригоден и для учебной аналитики, и для персонализации.
    Это не только склад контента, но и источник signals о сильных и слабых сторонах ученика.

  7. Templates и instances разделены.
    activity_template и program_template живут в task-bank. lesson_instance, course_instance, training_session, competition_submission и competition_result живут в доменах проведения.

  8. Внешние домены получают locked snapshots.
    LMS, competitions, storefront и management не должны зависеть от mutable drafts или будущих правок задач, подборок и templates.

Почему этот домен стратегически важен​

Без task bank система знает только:

  • какие уроки были открыты;
  • какие темы были помечены как пройденные;
  • какие занятия посещались.

С task bank система получает намного более точную модель:

  • какие типы задач ребёнок уже решал;
  • какого уровня сложности;
  • в каких темах он стабильно успешен;
  • где есть пробел между формальным completion темы и фактическим mastery.

Целевая роль домена​

В целевой архитектуре банк-задач должен стать самостоятельным доменом и сервисом, который:

  • владеет каноническими задачами;
  • владеет problem sets, activity templates and program templates;
  • обслуживает олимпиадный, учебный, тренировочный и публичный контур;
  • отдаёт problem versions, sets and locked snapshots в LMS live delivery, competitions, storefront, management diagnostics и LMS roadmap;
  • принимает ответы для проверки и возвращает normalized check results;
  • хранит low-level problem evidence без подмены учебных или олимпиадных результатов.

Карта документов​

  • scope.md — акторы, зоны ответственности, соседние домены и запреты.
  • mirolimp-content-core.md — связь Миролимпа/MeraLink с task-bank, templates vs instances, snapshots и public catalog projection.
  • data-model.md — канонические сущности: problems, versions, answer schema, checking, taxonomy, usage, attempts, evidence.
  • database-schema.md — PostgreSQL DDL, immutable versions, checking rules, attempts, evidence и audit.
  • state-machines.md — lifecycle задач, версий, подборок, usage, attempts, checks и manual review.
  • api-map.md — endpoints, permissions, service scopes и error codes.
  • api-contracts.md — DTO, validation и response schemas.
  • permissions-matrix.md — endpoint/action → permission → visibility → audit.
  • events.md — входящие команды, исходящие события, payloads, идемпотентность и retention.
  • integrations.md — связи с новым слоем integrations/*.md.
  • user-flows.md — сценарии публикации, usage, attempts и checking.
  • screen-spec.md — экраны редактора, каталога, usage, checking, review и evidence.
  • security.md — visibility задач, решений, answer keys и service tokens.
  • test-plan.md — unit, integration, e2e, security, checking и data quality tests.
  • features/problems.md — каноническая модель задачи, версий, решений, попыток и evidence.
  • features/taxonomy.md — таксономия задач.
  • features/variants.md — параметризованные и set-варианты.
  • features/relations.md — duplicate, analog, variant, similar, prerequisite and same-method relations.
  • features/solutions.md — решения, разборы и подсказки.
  • features/answers-checking.md — проверка ответов.
  • features/activity-templates.md — шаблоны занятий, домашек, тренажёров, диагностик и туров.
  • features/program-templates.md — программы, треки и последовательности activity templates.
  • features/public-catalog.md — публичный каталог как projection поверх task-bank.
  • features/usage.md — использование задач в соседних доменах.
  • features/admin.md — администрирование.
  • integrations.md — связи с LMS, competitions и аналитикой.
  • acceptance.md — критерии готовности.

Канон документов​

Каждый домен целевой модели ведётся в 15-файловом каноне: overview.md, scope.md, data-model.md, database-schema.md, state-machines.md, api-map.md, api-contracts.md, permissions-matrix.md, events.md, integrations.md, user-flows.md, screen-spec.md, security.md, test-plan.md, acceptance.md, а детальные возможности лежат в features/*.md.