CHANGELOG — D14 Расписание и планирование учебного процесса¶

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

Переработано — слот расписания вместо «запланированного занятия»¶

Существенная переработка entities.md и README/GUIDE по итогам разбора экосистемы Univerkon/Дидактикон + доклада «Цифровая инфраструктура вуза» §4:

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

Ключевое: запланированные учебные события подняты на уровень D06 (см. D06 §1.12 после PR #13). D14 теперь оперирует слотами, каждый из которых покрывает 1..N запланированных событий D06.

§1.3 «Запланированное занятие» → «Слот расписания». Что изменилось: - Атрибуты дисциплина, тип, форма_контроля убраны — они принадлежат запланированному событию D06, на которое ссылается слот - Добавлен атрибут события — список ссылок на D06.PlannedEvent (1..N) - Добавлен атрибут вид_слота (занятие / экзамен / зачёт / пересдача / отработка / день_практики / консультация / ГИА) - Ключевая формулировка: слот подставляет runtime-контекст (дата, время, аудитория, преподаватель); события подставляют норму

§1.4 Регистрация на слоте — новая сущность. Из Дидактикон Блок III §5: процесс аутентификации присутствия. Статусы: pending / confirmed / rejected. Регистрация — уровня слота, не события: одна отметка покрывает все события внутри.

§2 Жизненный цикл — существенно расширен: - Для видов «занятие / экзамен / зачёт / пересдача / отработка / консультация / ГИА» — 6 состояний Дидактикон (запланировано → регистрация → регистрация_закрыта → идёт → завершено + перенесено) - Для вида «день практики» — упрощённый цикл (запланировано → идёт → завершено + перенесено); регистрация как процесс не применяется, свидетель — база

§3 Инварианты — 8 инвариантов вместо 4: - «Расписание разворачивает план, не создаёт события» - «Один слот → 1..N запланированных событий D06» - «Регистрация — процесс уровня слота, не события» - «День практики без окна регистрации» - Существующие 4 сохранены

§4 Контракты — переработаны: - D14 ← D06: план учебных событий → слоты (главный контракт, был отсутствующий) - D14 → D04: при переходе слота в «идёт» — создание учебных событий D04 для каждого события D06, привязанного к слоту (был по-другому)

§5 ERD — заменены сущности; добавлены Registratsiya и связи с D06.PlannedEvent

README¶

Переписан целиком: - Раздел «Зачем выделен» дополнен цитатой доклада §4 - Раздел «Что входит» переписан: слот вместо запланированного занятия; регистрация; учебный период - Раздел «Что не входит» дополнен: план учебных событий — D06 - Раздел «Ключевые архитектурные решения» переработан: - Термин «слот» и обоснование (не только занятие, но и экзамен, пересдача, ...) - Один слот → 1..N учебных событий D06 - Регистрация — процесс уровня слота

GUIDE¶

Переписан целиком: - Таблица D14 vs D06 vs D04 расширена - Раздел про регистрацию как процесс уровня слота — новый - Типовые ошибки: «заводить события в D14», «регистрация на каждое событие», плюс сохранённые ошибки про именованный отбор

Изменено (синхронизация с новой моделью D05)¶

Терминология «административные группы D05» заменена на явные ссылки D05.Группа + D05.Членство в группе (M:N во времени) — по итогам мёржа PR #3 (D06 норма-ось), который переработал модель D05.
Убран атрибут тип из именованного отбора — теперь выводится из типов ссылочных D05.Группа (основная / подгруппа / поток / элективная). D05 уже владеет типизацией групп; дублировать в D14 не нужно.
Уточнено «Соотношение с D05.Группа» в entities.md §1.2: именованный отбор — правило поверх одной или нескольких групп D05, а не альтернативная сущность.
Контракт D14 ← D05 переименован из «административные группы» в «группы и членство» с указанием, что читается срез на дату применения правила.
README.md: раздел «Ключевое архитектурное решение» переформулирован через Членство в группе; сняты упоминания «студент → группа, меняется документом» (плоская модель).
GUIDE.md: раздел «Именованный отбор: сущность, не запрос» переписан на «правило поверх D05.Группа»; добавлена типовая ошибка «дублировать D05.Группа именованным отбором».

Открытые вопросы¶

Формат передачи нагрузки в D07. Агрегат нагрузки вычисляется из расписания D14. Открыт вопрос: момент и протокол передачи в D07 (по запросу / событием при изменении расписания / периодически).
Внеплановое занятие. Учебное событие без запланированного занятия D14 — нетиповой сценарий. Нужен процесс: кто инициирует, какой документ-основание, как влияет на нагрузку.
Аудиторный фонд. Аудитория упомянута как атрибут занятия, но как сущность не описана. Управление аудиторным фондом — возможно, отдельный процесс в D14 или смежный домен.
Конфликты расписания. Проверка на пересечения (преподаватель / аудитория / группа в одно время) — алгоритм валидации при создании/изменении занятия.
Копирование расписания на следующий период. Типовая операция в ОО; нужен процесс.
Индивидуальный учебный план (ИУП). Обучающийся на ИУП может иметь нестандартный именованный отбор; взаимодействие с D05 (статус IUP_GRANT) не описано.

Дорожная карта¶

D14-P01: Составление расписания на период (планирование)
D14-P02: Ведение именованных отборов (поток, подгруппа, электив)
D14-P03: Передача нагрузки в D07
Расширенная модель данных: аудиторный фонд, конфликты, ИУП

0.1.0 — 2026-06-26¶

Первая версия карточки домена D14; домен выделен из обсуждения архитектуры D04. Причина выделения: расписание — планирующий слой с двумя потребителями (D04 и D07), не может принадлежать ни одному из них.
Введены ключевые сущности: учебный период, именованный отбор, запланированное занятие, нагрузка ППС (агрегат).
Зафиксировано ключевое архитектурное решение: именованный отбор хранит правило, не состав; состав вычисляется при создании журнала D04 и замораживается там.
Исправлен D04 entities.md: статус [Запланировано] перенесён в D14; добавлен контракт D14 → D04.
AI-драфт: Claude (Opus 4.8); автор: @iMironRU.