3 Задача

docs/BUSINESS_LOGIC.md

@@ -343,6 +343,49 @@ constraint. При чтении API разворачивает периоды о
 
 ---
 
+### Пожелания преподавателей на семестр
+
+Преподаватель формирует набор пожеланий отдельно для каждого семестра. Интервальные записи
+привязаны к дню недели и паре базовой сетки времени, полная строгая недоступность — к
+конкретной дате семестра. Поддерживаются:
+
+- `HARD_UNAVAILABLE` — строго запрещённый интервал либо полностью недоступная дата;
+- `SOFT_PREFERRED` и `SOFT_UNWANTED` — предпочтительный и нежелательный интервалы;
+- `CONSECUTIVE` и `NO_GAPS` — пожелания к компактности расписания.
+
+Запись преподавателя сначала имеет статус `PENDING`. Кафедра может рассматривать только
+пожелания преподавателей, относившихся к ней в период семестра; учебный отдел и
+администратор работают со всеми записями. Ответственный сотрудник также может сразу создать
+согласованную запись. Отклонение требует комментария, а преподаватель может отозвать только
+собственную ожидающую запись.
+
+Только согласованные строгие ограничения влияют на валидацию. `ScheduleRuleService`
+проверяет каждую активную неделю нового или изменённого правила, а `ScheduleOverrideService`
+— фактическую дату результата разовой правки. Поэтому строгая недоступность одинаково
+учитывается конструктором правил, мастером замены и заявками преподавателей. Мягкие
+пожелания и компактность подсвечиваются в конструкторе, но не меняют опубликованное
+расписание автоматически.
+
+### Заявки преподавателей на изменение занятия
+
+Заявку можно создать только по собственному фактическому занятию, для которого ещё нет
+разовой правки. Поддерживаются перенос даты/времени (`MOVE`), смена аудитории
+(`CHANGE_CLASSROOM`) и отмена (`CANCEL`). Одновременно по одной паре допускается только одна
+заявка `PENDING`.
+
+До отправки интерфейс получает список ближайших учебных дат, временных слотов и аудиторий.
+Каждый вариант проходит `ScheduleOverrideService`: проверяются принадлежность семестру,
+календарный график групп, эффективная сетка времени, жизненный цикл ресурсов, пересечения
+преподавателя, аудитории, групп и подгрупп, подтверждённые отсутствия и строгая
+недоступность преподавателя. При создании заявки проверка выполняется повторно.
+
+Кафедра видит заявки своих преподавателей, но применять изменение вправе только
+`ADMIN` или `EDUCATION_OFFICE`. При одобрении в одной транзакции повторно проверяется и
+создаётся обычный `schedule_override`, его ID сохраняется в заявке, а в неизменяемую
+историю добавляется статус `APPROVED`. Отклонение требует комментария; преподаватель может
+отозвать только собственную ожидающую заявку. История содержит автора, время, статус и
+комментарий каждого перехода.
+
 ## Привязка преподаватель ↔ дисциплина
 
 Связь Many-to-Many через таблицу `teacher_subjects`: