Перейти к содержанию

CHANGELOG — D04 Образовательная деятельность

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

Переработано — 5 фактов формы контроля, двухфазность, разведение механизмов

Третий заход из четырёх по перестройке модели событий (после PR #13 D06 и PR #14 D14). D04 обогащён концепциями из Дидактикон Блок III §8, §11, §13, §14 и academic-concept v1.4 §4.

Обновления в entities.md:

§1.1 Учебное событие: - Добавлены ссылки planned_event_id (D06.§1.12) и slot_id (D14.§1.3) — учебное событие реализует норму D06 в контексте слота D14 - Инвариант «состав события — пересечение × снимок» (доклад §4): состав слота × assignment_mode формы контроля - Инвариант «один главный педагог на событии» (Дидактикон §2.12)

§1.2 Обязательство: - Атрибут forma_kontrolya_id → ссылка на D06.§1.11 (норма); D04 не хранит определений - Атрибут фаза: открыто / готово / сдано / оценено (двухфазность форм из Дидактикон §8) - Разведение «Пересдача формы» (авто, без approval) vs «Отработка пропуска» (approval-based, отдельный флоу)

§1.3 Пять фактов формы контроля — новый раздел: - Цепочка assignment → launch → attempt → submission → evaluation (+ pickup для pre_event-бонусов) из Дидактикон Блок III §13 - Каждый факт — отдельная неизменяемая запись - Принудительное завершение inline-форм при переходе слота D14 в «завершено»

§1.4 Assignment group — новая сущность: - Группа взаимозаменяемых вариантов одной формы контроля (Дидактикон §11.5) - Инвариант «одно активное обязательство на студента в рамках группы вариантов»

§1.5 Запись: сохранена; уточнено её место относительно 5 фактов (это evaluation, спроецированная на уровень обязательства для БРС и агрегации).

§1.6 Ведомость: без изменений.

§1.7 Педагогический бонус — новая сущность: - Отдельный механизм вне пакета и вне ФОС (Дидактикон §14) - Педагог даёт баллы с указанием причины, лимит — учётная политика - Не порождает обязательств у студента; учитывается в БРС наравне с формами

§1.8 Академическая задолженность: расширена до трёх видов (доклад §5) с указанием, что это одна мета-механика (событие → обязательство → запись), но события у каждой свои: дисциплинарная (учебные события внутри дисциплины), академическая (события уровня программы), финансовая (административные события D09).

§2.3 Жизненный цикл двухфазности — новый раздел: - открыто → готово → сдано → оценено с бинарным принятием - Отработка пропуска — отдельный approval-based флоу (не 5 фактов)

§3 Инварианты: 10 → 16 - 12: Один главный педагог - 13: Пересдача формы ≠ Отработка пропуска - 14: Assignment group — одно активное обязательство - 15: Педагогический бонус — вне цикла формы контроля - 16: Форма контроля как норма — в D06 (D04 не хранит определений)

§4 Контракты: добавлен явный контракт «D06 → D04: форма контроля как норма» (разведение нормы и факта).

§5 ERD: переработан — добавлены Assignment, Launch, Attempt, Submission, Evaluation, Assignment_Group, Pedagogicheskiy_Bonus; связи с D06 (PlannedEvent, FormaKontrolya) и D14 (Slot).

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

Добавлено

  • D04-P03: Практика — от направления до закрытия элемента траектории. Нормативное основание: ФЗ-273 ст. 13.1, Приказ Минобрнауки/Минпросвещения от 05.08.2020 № 885/390. Изначальный AI-драфт: Claude (Sonnet 4.6), нормативные ссылки верифицированы.
  • best-practices/academic-pitch-for-deans.md — доклад-сценарий для деканов и УМО «Академический контур: как взять задолженности под контроль». Аудитория: не разработчики, а сотрудники ОО. AI-драфт: Claude (Opus 4.8), автор: @iMironRU.

Зафиксировано в entities.md

  • Инвариант 10: рейтинг — условие допуска к аттестации, но не юридический блок. Система сигнализирует, не запрещает. ⚠ Требует юридической проверки.
  • Статус [Запланировано] перенесён в D14 (расписание): D04 начинается с [Началось], инициируется из D14. Добавлен контракт D14 → D04 в §4.
  • Контракт D06/D14 → D04 уточнён (после переработки D14, PR D14 slots): запланированное событие живёт в D06 (§1.12), развёртка на слот — в D14 (§1.3); один слот может покрывать 1..N событий D06. При переходе слота в «идёт» D14 создаёт учебные события D04 — по одному на каждое запланированное событие D06. §2.1 и §4 переформулированы.

Зафиксировано в GUIDE.md

  • Раздел «Два слоя понятия «событие»»: разведена терминология «учебное событие» (D04) vs «документное событие» (административный слой D05/D09), чтобы не было путаницы при интеграции с внешними концепциями.

Проанализированные источники (не коммитятся)

  • concept_main.md.pdf v2.0 — концепция учётной системы учебно-организационного отдела (1С/БСП, рабочая гипотеза). Сверка: большинство принципов совпадают с D04. Выявленные пробелы — в дорожной карте ниже.
  • dokladakademicheskiykontur.md — доклад для деканов; перенесён в best-practices.

Открытые вопросы (дополнено по итогам сверки)

  1. Контракт D09 — гранулярность и момент актуализации оказанного объёма; для КЦП — реперы без фиксированных дат.
  2. Перезачёт — ручное подтверждение для первой версии; автоподбор отложен. Алгоритм: система предлагает кандидатов по совпадению названия + трудоёмкости; решение принимает сотрудник, оформляется ведомостью типа «Перезачёт».
  3. Суффиксы зачёток — предыдущая_зачетка_id, max+1; триггер «смена ФИО».
  4. Событие-отмена — кто вправе, отмена vs перенос.
  5. Корректирующая ведомость — выборка, подпись, обратимость.
  6. Валидация свидетельства практики — защита от подлога (регламент).
  7. Инвариант «рейтинг не блок» — юридическое основание (ФЗ-273); ⚠ верифицировать до перевода в review.

0.1.0 — 2026-06-01

Первая версия домена D04 (академический контур, срез «реализация учебного процесса»):

  • Введена центральная абстракция Учебное событие — генератор обязательств с тремя частными случаями: занятие, день практики, аттестационное событие.
  • Модель данных: учебное событие, обязательство, запись, форма контроля, ведомость, учётная политика; ERD (mermaid); инварианты.
  • Процессы: D04-P01 (событие → обязательства → записи) и D04-P02 (возникновение и ликвидация академической задолженности).
  • Дисциплинарный контроль (посещаемость, отработки, выговор как триггер → D05).
  • БРС подан как одна из политик оценивания, не ядро.
  • Темпоральные режимы: черновой состав → буфер → факт; закрытие модуля снимком.
  • Контракт D04↔D05: снимок периодов-исключений для таймера задолженности.
  • Контракт D04→D09: журнал = оказанный объём для платных; для КЦП — контингент+ведомости.
  • Нормативная база: ФЗ-273 ч. 5 ст. 58 (лимит попыток/срок задолженности ⚠ сверить), ФЗ-273 ст. 43 / ТК РФ ст. 192 (дисциплинарное взыскание ⚠ сверить).
  • Изначальный концепт: 4 версии (1.0→1.4), три раунда внешней рецензии. Изначальный AI-драфт: Claude (Opus 4.8); адаптация и интеграция: Claude (Sonnet 4.6). Нормативные ссылки требуют ручной проверки перед переводом в review.
  • Автор: @iMironRU

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

  1. Контракт D09 — гранулярность и момент актуализации оказанного объёма; для КЦП — реперы без фиксированных дат.
  2. Перезачёт — ручное подтверждение для первой версии; автоподбор отложен.
  3. Суффиксы зачёток — предыдущая_зачетка_id, max+1; триггер «смена ФИО».
  4. Событие-отмена — кто вправе, отмена vs перенос.
  5. Корректирующая ведомость — выборка, подпись, обратимость.
  6. Валидация свидетельства практики — защита от подлога (регламент).

Дорожная карта (future work, не реализовывать в этом вкладе)

  • Компетенции — два слоя. Измерение сформированности опирается на ядро (агрегат форм контроля). Планирование (компетенция из стандарта → матрица покрытия) — отдельный контур планирования, не надстройка над событием. Не смешивать.
  • ГИА (ГЭК, ВКР).
  • Учебный план как сущность — сейчас в entities.md подразумевается, не описан явно. Атрибуты: уровень, направление, форма, финансирование; фиксируется при первом зачислении по нему, не меняется; к одной ОП — один план на каждый год набора.
  • Траектория как сущность (v2.0 концепции: элемент траектории, выбор в вариативной части, рабочая программа, результат прохождения). Ключевой момент: выбор в вариативной части фиксируется документом до начала периода.
  • Рабочая программа как сущность (контейнер контрольных точек, шкала рейтинга, порог допуска; привязана к учебному плану, фиксируется вместе с ним). Сейчас в entities.md есть FORMA_KONTROLYA — это атомарная единица, не контейнер.
  • Группы: два принципиально разных вида. Административная группа (фиксированный состав, меняется документом) vs именованный отбор (правило, вычисляется в момент создания журнала занятия). Это архитектурное решение для расписания; сейчас в D05 group_id — одно поле.
  • Жизненный цикл рабочей программы + смена учебного плана.
  • Нетиповые сценарии и нетиповые задолженности (без ведомости).
  • Процесс перезачёта (D04-P04 или D05-P05) — алгоритм подбора кандидатов, решение сотрудника, ведомость типа «Перезачёт».
  • Аналитический слой.
  • Ролевая модель преподавателей.
  • Академическая мобильность.
  • Расписание как отдельная сущность (сейчас не описана ни в D04, ни в D05; именованные отборы и административные группы ссылаются на расписание, которого нет).
  • Приложение к диплому — формирование из совокупности зачёток обучающегося; сейчас только упомянуто в GUIDE.md как «витрина → приложение к диплому».
  • Формирование приложения к диплому — процесс выпуска.