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

Критерии готовности банка заданий

Зачем нужно​

Документ фиксирует признаки готовности банка заданий как канонического источника задач для экосистемы.

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

  • education;
  • task-bank team;
  • engineering;
  • QA;
  • product.

Сценарии​

  • проверить готовность модели задач;
  • принять MVP банка заданий;
  • согласовать интеграции с LMS и олимпиадами;
  • проверить импорт и версионирование.

Правила​

  • Банк заданий владеет канонической задачей, версиями, вариантами, ответами и решениями.
  • Банк заданий владеет activity templates, program templates and content export snapshots.
  • Банк заданий владеет checking rules, answer checks и low-level problem evidence.
  • Учебные attempts/review принадлежат LMS/Learning Workspace; олимпиадные submissions/results принадлежат competitions.
  • Опубликованные задачи и закрытые ответы должны иметь управляемую видимость.

Интеграции​

  • LMS — учебные задания;
  • competitions — задания туров;
  • LMS/Learning Workspace — тренажёры и разборы;
  • management diagnostics — подборки;
  • storefront — публичные примеры;
  • storefront — public catalog projection;
  • management — аналитика.

Безопасность​

Закрытые задачи, ответы и решения доступны только ролям и сценариям, которым это разрешено.

Готовность​

  • задача имеет каноническую запись;
  • таксономия работает;
  • варианты и версии не теряют связь с оригиналом;
  • ответы и решения управляются;
  • задачи можно использовать в LMS и олимпиадах;
  • activity template можно экспортировать в LMS/competitions snapshot;
  • program template можно экспортировать в LMS snapshot;
  • public catalog projection не раскрывает закрытые данные;
  • low-level checks не смешиваются с LMS training attempts и competition results;
  • импорт из старых источников трассируется;
  • права на закрытые материалы проверяются.

Детальные критерии​

Документация​

  • границы домена описаны в scope.md;
  • модель данных описывает problem, version, statement, solution, hint, answer schema, checking rule, taxonomy, set, variant, usage, attempt, check и evidence;
  • модель данных описывает subject, problem relation, publication profile, activity template, program template и content export snapshot;
  • схема БД содержит immutable versions, usage registry, raw attempts, checks, evidence и audit;
  • все основные сущности имеют статусные модели;
  • API разделяет authoring, public/context read, service usage, attempts и checking;
  • DTO и validation описаны для problem version, answer schema, checking rule, usage, attempt, check и evidence;
  • матрица прав покрывает solution/key visibility и manual override;
  • тест-план покрывает versions, checking, security и integrations.
  • новый ADR фиксирует Миролимп/MeraLink как product implementation of task-bank, not separate domain.

Задачи и версии​

  • problem имеет стабильный id/code;
  • published version immutable;
  • новая редакция условия создаёт новую version;
  • attempt всегда ссылается на конкретную problem version;
  • old attempts воспроизводят старую statement и checking context;
  • retired version остаётся доступной для history.

Answer schema и checking​

  • answer schema валидируется перед публикацией;
  • checking rule задан или явно требуется manual rubric;
  • answer key отделён от public statement;
  • auto check детерминирован или явно помечен как external/non-deterministic;
  • manual review имеет rubric snapshot;
  • override требует permission, actor и reason;
  • scoring rule хранит max score и partial credit.

Таксономия​

  • taxonomy nodes имеют type, key, title и status;
  • problem может иметь несколько taxonomy links с весом;
  • public task имеет primary topic;
  • source hierarchy and license/publication policy described;
  • topic/skill/type/source/level различаются;
  • bulk taxonomy changes аудируются;
  • missing taxonomy блокирует публикацию или создаёт явный warning по policy.

Подборки, варианты и usage​

  • published problem set имеет items;
  • problem set item хранит version policy или конкретную version;
  • variant сохраняет связь с original problem;
  • duplicate, analog, parameterized variant, set variant, similar and prerequisite have distinct semantics;
  • prerequisite graph rejects cycles;
  • usage хранит context domain, context type, context id и scoring snapshot;
  • content export snapshot groups set/activity/program export;
  • locked snapshot immutable;
  • locked usage нельзя менять без audit;
  • closed competition usage не раскрывается публично.

Attempts, checks и evidence​

  • submitted attempt immutable для ученика;
  • duplicate submit/check обрабатывается идемпотентно;
  • failed check не теряет attempt;
  • checked result создаёт normalized evidence;
  • attempt namespace различает LMS training, LMS activity и competition submission context;
  • evidence не трактуется как mastery;
  • raw answer не публикуется в событиях.

Безопасность​

  • student не читает answer key;
  • hidden solution не доступен до release;
  • teacher видит solution только в назначенном context;
  • checker видит key/rubric только для assigned review или service scope;
  • чтение закрытого solution/key аудируется;
  • export закрытых задач требует permission;
  • public storefront не получает closed competition tasks без publish rule.
  • public catalog не получает hidden answer key, teacher notes, hidden rubric or embargoed source.
  • service scopes distinguish public projection, snapshot read, answer schema and answer key access.

Интеграции​

  • LMS создаёт usage и check requests через service scope, а training attempts хранит у себя;
  • LMS imports activity/program snapshots but owns lesson/course instances, assignments, attempts and progress;
  • competitions создаёт locked usage/snapshot и получает checking results, а submissions/results хранит у себя;
  • storefront получает только public-safe projection;
  • management читает aggregate evidence без raw answers;
  • identity используется для actor/user refs и permissions;
  • retry команд не создаёт дублей.

UI​

  • каталог задач фильтруется по subject, status, taxonomy, difficulty, usage и checking readiness;
  • редактор version показывает publish checklist;
  • solution/key editors скрыты без permission;
  • usage registry показывает внешние контексты;
  • activity template editor supports sections/items/roles/policies;
  • program template editor supports tracks, modules, 32 activities and replacements;
  • export snapshot screen shows payload hash, status and sensitive-field exclusions;
  • public catalog preview shows canonical URL and allowed fields only;
  • relation graph distinguishes relation types and blocks prerequisite cycles;
  • manual review queue поддерживает assignment, rubric decision и override;
  • evidence analytics не раскрывает raw answers.

MVP acceptance​

MVP task-bank можно принимать, если работают:

  1. problem + version + immutable publish;
  2. statement/assets + answer schema + answer key;
  3. checking rule для хотя бы exact/numeric/manual типов;
  4. taxonomy nodes and links;
  5. problem sets;
  6. activity template with sections/items;
  7. content export snapshot for LMS or competitions;
  8. usage registry для LMS или competitions;
  9. low-level problem attempts, submit/check и evidence;
  10. solution/key visibility gates;
  11. manual review или documented manual stub;
  12. public catalog projection without hidden keys;
  13. tests из test-plan.md для versions, checking, visibility, snapshots и integrations.

Создать занятие кружка​

  1. Создать activity_template.
  2. Разбить на sections: warmup, main, homework, reserve.
  3. Добавить problem versions with roles.
  4. Экспортировать locked snapshot в LMS.
  5. LMS создаёт lesson instance and assignments у себя.

Создать программу 32 занятий​

  1. Создать program_template.
  2. Добавить tracks.
  3. Добавить 32 activity templates в track.
  4. Экспортировать program snapshot в LMS.
  5. LMS создаёт course plan and schedule separately.

Создать олимпиадную подборку​

  1. Создать problems and published versions.
  2. Создать problem set или activity template type competition_round.
  3. Назначить roles: main, reserve, tie-breaker, sample.
  4. Создать locked snapshot для competitions.
  5. Competitions создаёт tour, participants, submissions and results у себя.

Превратить олимпиаду в тренажёр​

  1. Competition snapshot remains immutable.
  2. Создаётся отдельный training problem set/activity template или public/training projection.
  3. LMS создаёт training context.
  4. Competition submissions не смешиваются с LMS attempts.

Опубликовать задачу в каталоге​

  1. Problem version published.
  2. Public profile ready/published.
  3. Primary topic exists.
  4. Source publication allowed.
  5. Projection excludes hidden answer key unless policy allows.
  6. Canonical URL is /tasks/<taskId>.