CHANGELOG — D06 УМД и контент

[Не выпущено]

Добавлено — каскад компонентов ДПП (§1.16) и Инвариант 21

Закрыт открытый вопрос «параллельные «Учебный план ДПП» и «ФОС ДПП» не специфицированы». Перед проектированием структура ДПП сверена по приказу №266, пп. 10–20 (зеркало rulaws.ru; ⚠ номера пунктов сверить с publication.pravo.gov.ru): структура программы (п. 11) — цель, планируемые результаты, учебный план, КУГ, рабочие программы, организационно-педагогические условия, формы аттестации, оценочные и методические материалы; з.е. допустимы, но их число задаёт ОО (п. 11); стажировка (п. 12); модульный принцип и ИУП (п. 13); КУГ задаёт период обучения (п. 15); зачёт результатов (п. 17); итоговая аттестация в форме, определяемой ОО (п. 19); удостоверение / диплом / справка (п. 20).

Ключевое решение — параллельных сущностей нет. Набор элементов п. 11 совпадает с ОПОП, поэтому учебный план, строки, РПД, ФОС, ПК, индикаторы и версия-манифест у ДПП общие. Это сформулировано общим правилом — Инвариант 21: сестринская сущность заводится, когда различается форма поля (так было с osnovanie, Инвариант 20); если совпадает структура, а меняются значения или держатель, сущность общая (как в Инварианте 14).

Изменения в модели: - §1.2 «Версия ОПОП» — общая «Версия программы»: opop_id заменён на programma: {tip: opop | dpp, id}. - Ключ ПК и индикатора versiya_opop_id переименован в versiya_programmy_id (§1.6, §1.8–1.10, Инвариант 15, ERD, GUIDE). Ключ встречался только внутри D06, в standards/ его нет. - §1.3: новое поле edinica_obyoma (ze / ak_chas); dolya_variativnoy для ДПП не применяется. - §1.4: таблица значений для строки плана ДПП (period — этап, не семестр; chast — «—»). - §1.5: в tip добавлены стажировка и итоговая_аттестация (ИА ДПП — не ГИА). - §1.7: «оценочные материалы» в ДПП — тот же ФОС, отличие только в термине. - §1.8: ПК в ДПП может опираться на квалификационные требования, не только на профстандарт. - §1.9: индикатор ДПП с proishozhdenie: фгос — только для переподготовки. - §1.11: уровень программа покрывает и ИА ДПП. - Инвариант 4: сверка объёма ДПП — с obyom_chasov, а не с ФГОС.

⚠ Технический долг: - Сущность на ERD по-прежнему называется OPOP_Version: на неё ссылается D05 (Nabor }o--|| OPOP_Version). Переименовывать нужно вместе с D05, отдельной правкой. - Имена obyom_ze / trudoyomkost_ze исторические: число хранится в единице edinica_obyoma. Значение edinica_obyoma для СПО не зафиксировано.

Изначальный драфт: Claude Opus 5.5, нормативка требует проверки.

Добавлено — ДПП как сестринская сущность ОПОП (§1.16)

Закрыт открытый вопрос «ДПП на основе профстандарта — отдельная карточка, норма-основание не ФГОС». Перед проектированием сверено по первоисточникам (legalacts.ru, pravo.ppt.ru — Приказ Минобрнауки от 24.03.2025 № 266, зарегистрирован в Минюсте 22.04.2025 № 81928):

• Приказ действует с 01.09.2025 до 01.09.2031, заменил приказ № 499 — целиком, без отдельной более поздней даты для отдельных пунктов.
• Самокоррекция: ранее в карточке (§1.6 «Вариант ДПО», сноска §1.1) стояла пометка «для профпереподготовки — с 01.03.2026». Проверка не подтвердила эту дату нигде в тексте приказа — исправлено на 01.09.2025 во всех местах, включая processes/D06-P03.md.
• П. 9 (профпереподготовка): основание — квалификационные требования + профстандарты + требования соответствующих ФГОС СПО/ВО к результатам освоения (не вся структура/объём ФГОС, только результаты).
• П. 7 (обе разновидности ДПП): содержание учитывает профстандарты и квалификационные требования — общее правило, без ФГОС-довеска.
• П. 10: при наличии примерной/типовой ДПП, утверждённой уполномоченным федеральным органом, — разработка обязана ей соответствовать, не просто учитывать как одну из рекомендаций.
• П. 18: минимальный объём — 16 часов (повышение квалификации), 250 часов (профессиональная переподготовка).

Ключевое архитектурное решение — ДПП не встраивается в ОПОП через nullable fgos_id, а становится сестринской сущностью (§1.16), потому что различие глубже источника нормы: собственная ось vid (повышение_квалификации / профессиональная_переподготовка, не значение uroven рядом с «бакалавриат»), собственные минимумы объёма в часах (не з.е.), обычно отсутствующая квалификация. Ключевое поле — osnovanie: составной объект (квалтребования + профстандарт? + результаты ФГОС только для переподготовки), а не одна ссылка, как fgos_id у ОПОП — п. 9 требует учитывать несколько источников одновременно, не выбирать один. Это структурное отличие от прежнего решения по УК/ОПК vs ПК (Инвариант 14) — там структура полей совпадала и различался только держатель; здесь различается сама форма поля.

Новый инвариант 20 (§3). Не сделано намеренно (см. §1.16, «Не входит в объём этой правки»): параллельные «Учебный план ДПП» и «ФОС ДПП» — закрывался вопрос нормы-основания, не весь каскад компонентов ОПОП для ДПП.

⚠ Открытый остаток: приказ №266 использует термины «примерная ДПП» и «типовая ДПП» рядом (п. 10), не давая ни одному определения — не установлено, разные ли это документа. Зафиксировано как открытый вопрос, не додумано.

Изначальный драфт: Claude Sonnet 5 (проверка первоисточников через веб-поиск + проектирование карточки в диалоге).

Добавлено — контент-слой: Материал (§1.15)

Закрыт открытый вопрос «Контент-слой (лекции, задания, кейсы) — модель связи «РПД → контент»», числившийся с самого первого проектирования домена («Архитектурное решение», ниже: «учебно-методический контент... = контент-слой, наполняется позже»). Источник — не новый разбор, а формализация уже решённого в трёх заархивированных материалах (lesson-package-concept.md, concept-eios.md, didakticon-block3-event-lifecycle.md), не сведённых ранее в entities.md.

Материал (§1.15) — новая сущность: scope (дисциплина/пакет), privyazka (РПД+тема либо Пакет §1.13), visibility_gate (4 уровня: enrolled/pre_event/during_event/teacher_unlocked), is_fos, content_ref. D06 хранит только привязку, не сам контент (принцип из concept-eios.md: «контент — лист, не структура») — файл/курс лежит статикой на хостинге или в LRS-плеере, вне домена. Пакет.materials (§1.13) уточнён: теперь явная ссылка на Материал со scope: пакет, не произвольный список URL.

Перенесена как норма (не факт) готовая матрица из didakticon-block3 — «состояние события × регистрация → видимые уровни материалов»; состояние и регистрация сами по себе факты D04, но правило, что из них видно, — норма D06.

Решение по SCORM/cmi5 (по вопросу пользователя в разговоре, не по источникам изначально): SCORM исключён как целевой формат нового контента. Атомарная единица D06 — занятие (Пакет), а не курс; SCORM в реальных инструментах авторинга почти всегда экспортируется одним пакетом на весь курс, что ломает эту атомарность. Принято правило сосуществования уже намеченное в concept-eios.md (строка 61), но не выделенное явно: легаси из авторинг-тулзов — SCORM, scope: дисциплина, привязка одним куском; новый контент — мелко, scope: пакет, без обязательной привязки к конкретному протоколу. Поле format в схеме — необязательная подсказка плееру (cmi5/scorm/static), не часть контракта нормы; протокол воспроизведения — граница с D12/реализацией.

Инвариант: is_fos = true ⟹ visibility_gate = enrolled — оценочные материалы нельзя спрятать за более поздний гейт.

GUIDE.md: обновлена формулировка границы D06↔D04 (была «наполняется позже» — теперь ссылка на §1.15), добавлены 3 типовые ошибки (материал как встроенный контент вместо ссылки; новый контент через SCORM «как положено»; ФОС за поздним visibility_gate).

Изначальный драфт: Claude Sonnet 5 (формализация трёх архивных источников + решение по SCORM/cmi5, выработанное в диалоге).

Решено — технический долг: миграция sourcePath в JSON Pointer + живой пример relationLink

Оба пункта были в «Открытые вопросы» (пп. 5–6) с прошлого раунда правок РПД-Двойника.

Миграция sourcePath. Перед миграцией пересчитано заново: не 91, а 76 значений sourcePath в discipline-program-twin.full-template.json были в dot-notation (91 — цифра из другого места, «91 реквизит» шаблона в целом, по ошибке скопирована в описание этого долга; исправлено). Не мигрировано слепой заменой точек на слэши — сперва выгружены и проверены все 61 уникальных значения на предмет коллизий, которых опасался прошлый CHANGELOG. Коллизия нашлась ровно там, где ожидалась: 6 значений используют собственную нотацию [] для «на каждый элемент массива» (classroomFund.rooms[].address, content.thematicPlan.periods[].modules[].topics[]) — JSON Pointer (RFC 6901) такого понятия не знает вообще: адресует одну конкретную позицию, не «любой элемент». Наивная замена точек на слэши с отбрасыванием [] превратила бы rooms[].address в /rooms/address — синтаксически валидный указатель, но означающий уже «у rooms есть поле address», а не «у каждой комнаты в rooms есть поле address» — тихая потеря смысла.

Решение — не изобретать свою нотацию, взять готовую из JSON Schema. sourcePath адресует не «сырой» экземпляр данных, а канонический источник (sourceType: curriculum/classroomFund/... — сам по себе категория, не документ), который по всему нашему стеку описывается через JSON Schema; в JSON Schema форма «что лежит в каждом элементе массива» — это ключевое слово items. Поэтому X[].Y → /X/items/Y, X[].Y[].Z → /X/items/Y/items/Z: валидный JSON Pointer (никакого расширения спецификации), с точным сохранением исходного смысла «на элемент массива», не выдуманный с нуля, а переиспользующий понятие, которое уже везде вокруг есть. Итог — 76 замен, после — jsonschema.FormatChecker() даёт 0 ошибок на всём файле (было решено и подтверждено проверкой, не просто «должно быть похоже на pointer»).

Живой пример relationLink. relations.links был пуст с момента появления самого поля — механизм существовал только как контракт схемы, ни разу не использован на реальных данных. Добавлена первая связь: собственное поле Двойника totalCredits (итоговая трудоёмкость дисциплины в з.е.) → standards/fgos/data/FGOS-VO-44.03.04-2017.json#/program/volume_credits (реальный файл, реальное поле, значение 240 — проверено чтением файла, не предположено). relationType: dependsOn, не derivedFrom — трудоёмкость одной дисциплины не копирует общий объём программы, а ограничена им (компонент суммы, не её копия); comment явно поясняет разницу, чтобы не завести привычку путать «производное значение» и «значение, зависимое от ограничения» под одним типом связи.

Изменено — вариативность строки плана: электив/факультатив/профмодуль СПО (§1.4, §1.6, §1.11, §1.12)

Продолжение разбора inbox/2026-07-06-univercon-fgos-rp-konspekt.md — раздел про «вид вариативности» (3 значения вместо 2 у chast). Разобрано через призму учебного события (итоговая аттестация по строке плана) и проверено на реальных сценариях: корзина выбора (иностранный язык, элективы физической культуры), факультатив, профессиональный модуль СПО (несколько МДК → один квалификационный экзамен), Блок 3 аспирантуры.

Найден и устранён конфликт с прежним инвариантом «1 РПД : 1 строка плана» (§1.6). Строка-корзина (например, «Иностранный язык» с выбором английский/немецкий/французский) требует нескольких по-настоящему независимых РПД (разное содержание, разный преподаватель), а не одной. Решение: строка остаётся одна (иначе трудоёмкость варианта задваивается в сумме против ФГОС), РПД получает собственный явный disciplina_id; 1..N РПД на строку, N > 1 только при новом vid_variativnosti = электив.

Новые поля строки плана (§1.4): vid_variativnosti (фиксированная / электив / факультатив — ось согласия обучающегося, ортогональна chast) и uchityvaetsya_v_obyome (bool — исключает факультативы и элективы физической культуры из суммы, сверяемой с объёмом ФГОС, Инвариант 4). Оба — хранимые, не вычисляемые: план обязывает раньше, чем дописаны РПД-варианты (тот же временной порядок, что у trudoyomkost_ze).

promezhutochnaya_forma_id перенесён со строки (§1.4) на РПД (§1.6). На строке поле не могло представить несколько разных форм контроля у нескольких РПД одновременно. Перенос на РПД одним и тем же механизмом объясняет оба разобранных сценария: - электив — у N РПД одной строки по умолчанию N разных форм → N независимых событий; - профмодуль СПО — у РПД разных строк (МДК + практики) намеренно одна и та же форма → одно общее событие, закрывающее все обязательства разом. Отдельная сущность «Профессиональный модуль» не заводится — совпадения ссылки достаточно.

Исправлена реальная внутренняя нестыковка в §1.11. istochnik формы контроля относил уровень «дисциплина» (промежуточная аттестация) к РПД — то есть буквально утверждал, что тип контроля (экзамен/зачёт) решает кафедра. Это противоречило уже написанному в §1.6 («РПД не владеет формами контроля — она их проецирует») и реальному порядку согласования (тип задаёт план/УМО при утверждении, не автор РПД). Дисциплина перенесена в корзину УП; заодно переименовано uroven: модуль → тематический_модуль (снята коллизия с профессиональным модулем СПО, у которого нет собственного уровня формы контроля).

§1.5: добавлено пятое значение tip — научные_исследования (Блок 3 аспирантуры: строка плана без тематического плана занятий, РПД проецируется без раздела «Тематический план»).

Новые инварианты 16–19 (§3): электив — 1..N РПД, не N строк; профмодуль — расшаренный promezhutochnaya_forma_id, не контейнер; vid_variativnosti — хранимое, не вычисляемое; блоки печатной формы плана (Б1.О/Б1.В/ФТД/…) — вычисляемый вид группировкой по tip×chast×uchityvaetsya_v_obyome, кроме профмодуля.

⚠ Регуляторика, требующая сверки: норма «не менее 328 академических часов, не переводятся в з.е.» для элективов физической культуры и спорта — общее знание о ФГОС 3++, не проверено построчно по тексту конкретного стандарта. Приказ Минобрнауки № 266 от 24.03.2025 (заменил № 499 с 01.09.2025) как основание для ДПО — факт замены подтверждён веб-поиском, точная формулировка про условия/результаты ФГОС СПО/ВО с 01.03.2026 (упомянутая в §1.6 «Вариант ДПО») — не подтверждена первоисточником. Статус аспирантуры (готовится пилотный переход на трёхуровневую систему базовое/специализированное высшее + аспирантура, правила пилота на 17 вузов утверждены Правительством 19.06.2026) — в активном движении, uroven в §1.6 пока не тронут намеренно.

Изначальный драфт: Claude Sonnet 5 (веб-исследование регуляторной базы + архитектурный разбор с человеком в режиме диалога, без готового решения на входе). Нормативка помечена ⚠ выше и требует проверки человеком перед переводом домена в review.

Решено — «Вопрос 2» конспекта (common-ярус) закрыт без новой архитектуры

По итогам разбора inbox/2026-07-06-univercon-fgos-rp-konspekt.md, раздел K («Где живёт метамодель — в D06 или в common?»): новый слой строить не нужно. Проверка на фактах показала, что предложенные примитивы уже реализованы в standards/rpd/schema/discipline-program-twin.schema.json, влитом в предыдущем PR, просто под другими именами:

Предложение конспекта	Уже есть в РПД-схеме
6 типов полей (DSL)	fieldSource (sourceType/fillMode/sourcePath)
satisfies(kind, strength)	validationRule (type: range/crossField/..., severity: info/warning/error/critical)
Связь между документами (fgos↔rpd)	relationLink (from/to/relationType), явно описан как «связи Двойника с ФГОС»

relationLink.links в эталонном шаблоне пока пуст — механизм существует, но ни разу не заполнен реальной связью. Отдельно рассмотрен вопрос про SHACL (W3C-стандарт именно под задачу satisfies) — не принят: SHACL работает над RDF-графами, весь наш стек — чистый JSON Schema; адаптация означала бы непропорциональный сдвиг ради одной пары документов. Наш validationRule — по сути SHACL, упрощённый до чистого JSON под реальный масштаб задачи.

Принято одно точечное улучшение — адресация как JSON Pointer (RFC 6901). Проверены реальные форматы: fieldSource.sourcePath и relationLink.from/to были объявлены как свободная строка без формата. Добавлены format: json-pointer (для sourcePath) и format: uri-reference (для from/to, поддержка ссылок на внешние файлы вида standards/fgos/data/FGOS-VO-...json#/...) — используем существующий IETF-стандарт вместо изобретения своей нотации. JSON-LD (W3C, более тяжёлый вариант с внешней совместимостью) рассмотрен и отложен — нет текущей потребности во внешних потребителях наших данных как связанных (linked data); пересмотреть, если фреймворк когда-нибудь станет источником открытых данных для внешних систем.

⚠ Технический долг, зафиксирован явно (решено — см. запись выше в «[Не выпущено]»): 76 значений sourcePath (не 91 — эта цифра по ошибке скопирована из другого счётчика, «91 реквизит» шаблона; сверено пересчётом, исправлено при закрытии долга) в discipline-program-twin.full-template.json были в dot-notation (curriculum.discipline.name), не в JSON Pointer.

Изменено — УК/ОПК ≠ ПК; составные ключи компетенции/индикатора (§1.8, §1.9)

Продолжение разбора inbox/2026-07-06-univercon-fgos-rp-konspekt.md («Вопрос 1» — составные ключи (document_id, код) вместо синтетического UUID). При проверке реальных данных ФГОС (standards/fgos/data/FGOS-VO-44.03.04-2017.json) обнаружено, что поле indicators внутри компетенций документа всегда пусто — это подтверждает то, что уже было записано в нашем же §1.9 («определяется в ОПОП»), но раньше не было формализовано архитектурно.

§1.8 Компетенция расщеплена по природе, а не описана одной таблицей: - УК/ОПК не хранятся в D06 — адресуются напрямую естественной двойкой (fgos_id, kod) прямо в JSON стандарта. Копирования нет — единственный источник правды остаётся в standards/fgos/. - ПК — хранимая D06-сущность с естественным ключом (versiya_opop_id, kod) (не UUID) и полем proishozhdenie (ссылка на трудовую функцию профстандарта).

§1.9 Индикатор — всегда хранимая сущность, естественный ключ (versiya_opop_id, kod). Введён дискриминированный атрибут proishozhdenie (не часть ключа): tip: фгос → {fgos_id, put:[kod_kompetencii]}, tip: пк → {kod_pk} в той же версии ОПОП.

§1.10 Дескриптор — уточнена ссылка indikator_id (теперь на составной естественный ключ индикатора) и обновлена заметка про агрегацию матрицы под новую схему происхождения.

Новые инварианты 14–15: УК/ОПК не хранятся локально; индикатор всегда в ОПОП, никогда в документе нормы.

ERD (§5): Competency/Indicator получили явные атрибуты естественных ключей; добавлена внешняя сцепка Indicator.proishozhdenie → standards/fgos.Competency.

GUIDE.md: раздел «Компетенции: откуда берутся» переписан под расщепление УК/ОПК vs ПК; добавлены 2 типовые ошибки (копировать УК/ОПК локально; искать индикатор в документе ФГОС).

Не входит в этот вклад (отдельные решения конспекта, не приняты): - common-ярус: примитив связи satisfies (range/subset/threshold-tier, hard/soft/absent) — где ему жить в структуре репозитория - «Вид вариативности» (3 значения вместо 2 в §1.4) - Сущность «график (периоды)» на уровне учебного плана

Изначальный AI-драфт: Claude (Sonnet 5).

Изменено — матрица компетенций стала вычисляемым видом (§1.10)

По итогам разбора inbox/2026-07-06-univercon-fgos-rp-konspekt.md — архитектурное решение автора: матрица компетенций хранится не как отдельная M:N-таблица, а собирается агрегацией дескрипторов результата освоения.

• §1.10 переименован: «Матрица компетенций» → «Дескриптор результата освоения (РПД)». Это реальная хранимая сущность внутри РПД (§1.6): разработчик вручную формулирует, что дисциплина обещает по конкретному индикатору (tekst, vklad: формирует/контролирует).
• Матрица компетенций теперь описана как вычисляемый вид внутри §1.10 — агрегация дескрипторов всех РПД версии ОПОП, не хранилище.
• Дескриптор — единственная точка входа в норму (новый инвариант 13): карточка занятия и ФОС ссылаются на дескриптор РПД, не на индикатор ФГОС напрямую. Перевыпуск редакции стандарта не требует правки ссылок во всех потребителях.
• Инвариант 5 переформулирован под дескрипторы вместо матрицы.
• ERD (§5): Indicator }o--o{ StudyPlanLine заменён на WorkProgram ||--o{ Descriptor }o--|| Indicator; добавлена сущность Descriptor; примечание, что матрица не показана как ERD-сущность (это view).
• GUIDE.md: раздел «Компетенции: откуда берутся» переписан под дескрипторы; добавлены 2 типовые ошибки (хранить матрицу как M:N-таблицу; ссылаться на индикатор напрямую, минуя дескриптор).

Источник: inbox/2026-07-06-univercon-fgos-rp-konspekt.md, раздел M («Каталог требований стандарта» vs «Рабочие связи РП» — два разных списка, не смешивать) и раздел K (дескриптор как хаб для satisfies-связи, вопрос 3).

Не входит в этот вклад (отдельные решения, ещё не приняты): - Составные ключи компетенции/индикатора (document_id, код) вместо простого UUID - common-ярус: примитив связи satisfies (range/subset/threshold-tier, hard/soft/absent) — где ему жить в структуре репозитория, не решено - «Вид вариативности» (3 значения вместо 2 в §1.4) — отдельная доработка - Сущность «график (периоды)» на уровне учебного плана — отдельная доработка

Изначальный AI-драфт: Claude (Sonnet 5).

Добавлено — РПД как Двойник (§1.6 расширен, standards/rpd/, D06-P03)

Комплект из inbox (2026-07-06-eduframework-rpd.zip) — расширяет минимальный набросок РПД до полноценной модели с машиночитаемым контрактом.

• §1.6 Рабочая программа дисциплины (заменяет прежний тощий вариант из 4 строк): полная структура — derived-поля из строки УП, разделы содержания, жизненный цикл, 6 инвариантов, варианты СПО/ДПО, ссылка на JSON-Двойник.
• standards/rpd/schema/discipline-program-twin.schema.json — JSON Schema 2020-12, контракт Двойника РПД, v0.2.0. $id исправлен на aplicon-ru (был iMironRU в исходном комплекте).
• standards/rpd/data/discipline-program-twin.full-template.json — эталонный шаблон, 91 реквизит, профили по 8 направлениям (ДО/СПО/бакалавриат/специалитет/ магистратура/ординатура/аспирантура/ДПО). Схема валидна, 0 ошибок на шаблоне (проверено локально перед вливанием).
• data-model/rpd-fields.md — технический реестр реквизитов (генерируется из fieldRegistry, не редактируется вручную).
• data-model/rpd-fields-guide.md — памятка методисту (тоже генерируется). Исправлена терминология: «студент» → «обучающийся» (правило CLAUDE.md).
• processes/D06-P03.md — процесс разработки/проверки/печати РПД, включая альтернативный сценарий «обратное восстановление» из Word/PDF/XLSX/HTML. Нормативные ссылки (ФЗ-273 ст. 2, ст. 13, ст. 76) помечены ⚠ — требуют сверки человеком (в исходном комплекте были без маркера ⚠, только прозой).
• best-practices/rpd-forms-print/ — референс слоёв forms/print/ reverseImport; явно разведена норма (стандарт) и реализация (best-practice).

Правки при интеграции (сверх правок автора комплекта): - Нумерация раздела — §1.6, а не §1.5 как в исходном MANIFEST (у нас §1.5 уже занято «Дисциплина/модуль/практика»); все внутренние ссылки в best-practice и процессе поправлены. - derived-поле «формы контроля» явно связано с §1.11 (Форма контроля как норма, введена в этом же раунде доработки D06) — в исходном комплекте ссылалось только на «Строку учебного плана» без учёта трёхосевой модели. - Добавлен раздел в GUIDE.md «РПД как Двойник — норма vs реализация форм» + типовая ошибка «Проекции реестра РПД редактируются вручную» — по нашей устоявшейся практике всегда сопровождать новую сущность разделом в GUIDE.

Не входит в этот вклад (следующий шаг, отмечено автором комплекта): - tools/validate-rpd.py — валидация standards/rpd/data/* схемой в CI + проверка, что rpd-fields.md/rpd-fields-guide.md пересобраны из реестра.

Изначальный AI-драфт: Claude (Sonnet 5); нормативные ссылки требуют ручной проверки перед переводом в review.

Добавлено — план учебных событий на уровне нормы (§1.11–§1.14)

По итогам разбора экосистемы Univerkon/Дидактикон и доклада «Цифровая инфраструктура вуза» (см. inbox/2026-07-06-*) — план учебных событий поднят с уровня D14 (расписание) на уровень D06 (норма). Ключевое положение доклада §4:

«Расписание не создаёт события — оно их разворачивает.»

Новые сущности:

• §1.11 Форма контроля (как норма) — единая сущность, наследует academic-concept v1.4 §3.2. Три оси из Дидактикон Блок III (role_in_rating, assignment_mode, time_model). Уровень: занятие / тема / модуль / дисциплина / программа.
• §1.12 Запланированное учебное событие — родовое понятие, генератор обязательств, зафиксированный на уровне плана. Виды: занятие / модульный_контроль / экзамен / зачёт / курсовая / день_практики / ГИА. Источник — РПД (внутри дисциплины) или строка УП (уровень программы).
• §1.13 Пакет занятия — манифест-«картридж» (аналогия из §7 доклада). Стейтлесс, атомарен, переиспользуем; три источника данных (base + overlay + runtime).
• §1.14 Gate — первоклассная сущность-шлюз (entry-test / consent / briefing / readiness / form / attendance). Тексты версионируются; факт прохождения хранится в D04.

Обновлено:

• §1.4 Строка учебного плана — атрибут forma_kontrolya (enum) заменён на ссылку promezhutochnaya_forma_id → §1.11.
• §3 Инварианты — добавлены 9–12: план в двух местах (РПД + УП), форма контроля как норма (не факт), пакет стейтлесс, расписание не создаёт события.
• §4 Контракты: расширен D06↔D04 (разведение нормы и факта); добавлены D06→D14 (расписание разворачивает план) и D06→D05 (траектория читает план).
• §5 ERD — добавлены PlannedEvent, FormaKontrolya, Package, Gate.

Источники: academic-concept-v1.4.pdf §3-§4, lesson-package-concept.md, didakticon-block3-event-lifecycle.md, doklad-digital-infrastructure.pdf §4.

⚠ Не сделано в этом заходе (будут отдельные PR): - Переработка D14 под новую модель (слот расписания → 1..N событий D06) - Перенос форм контроля D04 → ссылки на §1.11 - Уточнение траектории D05 как вычисляемого представления УП+РПД - Формы контроля как факт (D04) — 5 фактов, двухфазность

Изначальный AI-драфт: Claude (Opus 4.7).

0.1.0 — 2026-06-02

Первая версия домена D06 — норма-ось академического контура (срез «ОПОП и компоненты»):

• Введена ОПОП как корень-комплект (манифест) со ссылками на версии компонентов; собственного содержания почти не несёт — задаёт идентичность.
• Версионирование только вперёд, только по изменению (не по календарю). Год набора — привязка когорты к версии (в D05), не сама версия.
• Модель данных: ОПОП, Версия ОПОП, Учебный план, Строка плана, Дисциплина/модуль/практика, РПД, ФОС, Компетенция, Индикатор, Матрица компетенций; жизненные циклы, инварианты, ERD.
• Процессы: D06-P01 (разработка и утверждение ОПОП), D06-P02 (актуализация нормы — новая версия).
• Компетенции и матрица покрытия включены (слой планирования открыт).
• Контракты: D06↔D02 (границы лицензии), D06↔standards/fgos (импорт УК/ОПК и объёма), D06→D05 (пин Набора к версии), D06↔D04 (чтение структуры как источника обязательств).
• Нормативная база: ФЗ-273 ст. 2, 11, 12, 13, 17, 76 — ⚠ требуют ручной проверки редакций перед переводом в review.
• Изначальный AI-драфт data-model: Claude (Opus 4.8); адаптация, карточка домена и процессы: Claude (Sonnet 4.6).
• Автор: @iMironRU

Архитектурное решение (зафиксировано в проектной сессии)

• Норма-ось целиком в D06, не в D04. Основание: D06 = «УМД и контент» по названию; ФЗ-273 ст. 2 определяет ОПОП как единый комплекс документов — разрывать его между доменами неестественно. D04 остаётся контуром реализации (что произошло), D06 — норма (чему и как).
• РПД = норма-слой (D06); учебно-методический контент, рождающийся из РПД, = контент-слой (тоже D06, отдельный слой, наполняется позже).

Открытые вопросы (в issues, не в теле карточки)

1. КУГ и расписание — операционные представления; где граница с D04. Уточнено: для ДПП КУГ — обязательный элемент структуры программы и единственный носитель календаря (приказ №266, пп. 11, 15), то есть как минимум документ КУГ входит в норму D06, а не только в операционный контур.
2. Автоподбор кандидатов на перезачёт по матрице совпадения дисциплин (сейчас ручной).
3. Тип B вариативности («пул с накопительным объёмом» — «не менее X з.е. суммарно» из списка дисциплин, в отличие от корзины «ровно 1 из N») — разобран отдельно, архитектурно легче корзины (каждая дисциплина уже полноценная строка), но требует сущности «Пул выбора» (целевой объём + список строк). Не реализован в этом раунде — только корзина (Тип A).
4. Сверить построчно по тексту актуального ФГОС 3++ норму об элективах физической культуры и спорта (328 академических часов, вне объёма программы) — сейчас в §1.4/Инварианте 4 общее знание, не цитата НПА.
5. Новое. Термины «примерная ДПП» и «типовая ДПП» (приказ №266, п. 10) — не различены первоисточником; не установлено, разные ли это документа или один под двумя названиями (§1.16).
6. ~~ДПП: параллельные «Учебный план ДПП» и «ФОС ДПП» не специфицированы.~~ Закрыт — каскад компонентов ДПП (§1.16), параллельных сущностей нет (Инвариант 21).
7. Статус аспирантуры и uroven в §1.6 — следить за пилотным переходом на трёхуровневую систему (базовое высшее / специализированное высшее / аспирантура как отдельный уровень профобразования, пилот на 17 вузов до 2030 года, правила утверждены Правительством 19.06.2026). Пока не трогать enum — распространяется поэтапно, не на все ОО сразу.
8. «Индивидуальный план работы аспиранта» (тема диссертации, показатели результативности) — вероятно, продолжение D05 «Траектория» (персональная развёртка) плюс новое поле, не новая сущность D06. Не проработано.

Дорожная карта (future work)

• Календарный учебный график как сущность (для ДПП — обязательный компонент программы).
• Переименование OPOP_Version → «Версия программы» вместе с D05.
• Версионирование с ветвлением (несколько профилей внутри направления).
• Интеграция матрицы компетенций с аккредитационными показателями (D02).