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

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

Решено — «Вопрос 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); пересмотреть, если фреймворк когда-нибудь станет источником открытых данных для внешних систем.

⚠ Технический долг, зафиксирован явно: 91 значение sourcePath в discipline-program-twin.full-template.json — в dot-notation (curriculum.discipline.name), не в JSON Pointer (/curriculum/discipline/name). Формат объявлен как целевой для новых полей; массовая миграция существующих 91 значения — отдельная задача (см. открытые вопросы).

Изменено — УК/ОПК ≠ ПК; составные ключи компетенции/индикатора (§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, не в теле карточки)¶

Контент-слой (лекции, задания, кейсы) — модель связи «РПД → контент».
ДПП на основе профстандарта — отдельная карточка, норма-основание не ФГОС.
КУГ и расписание — операционные представления; где граница с D04.
Автоподбор кандидатов на перезачёт по матрице совпадения дисциплин (сейчас ручной).
Миграция 91 значения sourcePath в discipline-program-twin.full-template.json из dot-notation в JSON Pointer — механическая, но требует построчной проверки (не автоматизировать слепой заменой точек на слэши — возможны коллизии).
Заполнить relationLink.links хотя бы одним реальным примером связи РПД ↔ ФГОС (например, диапазон з.е. из ФГОС ↔ производное поле «Итого в ЗЕ» РПД) — механизм существует, но ни разу не использован на живых данных.

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

Контент-слой УМД (учебно-методические материалы из РПД).
ДПП (дополнительные профессиональные программы).
Версионирование с ветвлением (несколько профилей внутри направления).
Интеграция матрицы компетенций с аккредитационными показателями (D02).