исправление багов

docs/DATABASE.md

@@ -709,6 +709,10 @@ Seed создаёт `Базовая сетка` (`DEFAULT`) и `Субботня
 
 `ScheduleRule` использует собственные поля жизненного цикла `status`, `valid_from` и `valid_to`: архивированное правило или правило вне периода действия не участвует в генерации расписания. В отличие от справочников на `LifecycleEntity`, таблица не содержит `active_from`/`active_to`, поэтому состояние правила проверяется по `valid_*`.
 
+Миграция V4 требует, чтобы лимиты лекций, лабораторных и практик были кратны двум.
+Неотрицательность каждого лимита и положительная сумма уже закреплены ограничениями V1;
+нули допустимы только как лимиты неиспользуемых типов занятия.
+
 #### `schedule_rule_groups` — Группы правила
 | Колонка | Тип | Описание |
 |---------|-----|----------|
@@ -734,6 +738,11 @@ Seed создаёт `Базовая сетка` (`DEFAULT`) и `Субботня
 | `locked_at` | TIMESTAMP | Когда выполнено закрепление |
 | `lock_comment` | TEXT | Комментарий к закреплению |
 
+V4 добавляет `uq_schedule_rule_slots_exact_payload`: в одном правиле нельзя повторить
+одинаковые день, чётность, базовый временной слот, преподавателя, аудиторию, тип и формат
+занятия. Более широкие ресурсные пересечения и семантика подгрупп проверяются сервисом,
+поскольку зависят от нескольких таблиц и фактических активных недель.
+
 #### `schedule_rule_slot_subgroups` — Подгруппы лабораторного слота
 | Колонка | Тип | Описание |
 |---------|-----|----------|
@@ -757,7 +766,16 @@ Seed создаёт `Базовая сетка` (`DEFAULT`) и `Субботня
 | `created_by` | BIGINT FK → users | Автор изменения |
 | `created_at` | TIMESTAMP | Дата создания |
 
-Ограничение `uq_schedule_overrides_slot_date` не позволяет создать две разные правки для одной и той же пары.
+Ограничение `uq_schedule_overrides_slot_date` не позволяет создать две разные правки для
+одной и той же пары. Миграция V3 добавляет структурные инварианты:
+
+- `CANCEL` не содержит новых ресурсов;
+- `MOVE` содержит новый временной слот или аудиторию;
+- `REPLACE` содержит нового преподавателя, аудиторию или формат;
+- `new_lesson_format` равен `Очно`, `Онлайн` либо `NULL`.
+
+Фактическое существование пары, реальность изменения и ресурсные конфликты зависят от
+календаря конкретной даты и проверяются транзакционным сервисом, а не SQL CHECK.
 
 ---
 
@@ -771,23 +789,30 @@ Seed создаёт `Базовая сетка` (`DEFAULT`) и `Субботня
 4. Flyway запускается **программно** при первом обращении к БД тенанта (`TenantConfigWatcher.initDatabaseForTenant()`)
 5. Настройка `baselineOnMigrate=true` — если в БД уже есть данные, Flyway начнёт с baseline
 
-> Текущая правка `V1__init.sql` является осознанным исключением по прямой просьбе пользователя: файл обновлён как новая базовая схема, а применение предполагает полный сброс tenant-БД без переноса старых Flyway checksum.
-
 ### Текущие миграции
 
 | Файл | Описание |
 |------|----------|
 | `V1__init.sql` | Инициализация: справочники, роли, refresh-сессии JWT, lifecycle-поля, история кафедр преподавателей, заявки кафедр на создание преподавателей, комментарии дисциплин, календарные учебные графики, привязки дисциплин к графикам по семестрам, динамическое расписание, версии/закрепления правил, точечные изменения расписания, тестовые правила, триггеры, комментарии |
+| `V2__subgroups_active_unique_name.sql` | Уникальность имени среди активных подгрупп одной группы |
+| `V3__schedule_override_invariants.sql` | Матрица payload и допустимый формат точечных изменений расписания |
+| `V4__schedule_rule_even_hours.sql` | Чётность лимитов академических часов и уникальность точного payload слота правила |
 
 ### Накатывание на существующих тенантов
 
-Для применения новой базовой схемы к уже существующим тенантам нужен полный сброс БД. Перезапуск backend без сброса не изменит уже применённую `V1__init.sql`.
+V2–V4 накатываются на существующие tenant-БД без изменения контрольных сумм V1–V3.
+Перед добавлением ограничений V3 считает нарушения `CANCEL`, `MOVE`, `REPLACE` и формата.
+Если найдены legacy-строки, миграция полностью откатывается и сообщает только количества
+нарушений. Оператор должен исправить бизнес-данные tenant-БД и повторить миграцию;
+автоматическое удаление или переписывание overrides не выполняется.
+
+Перед ограничениями V4 отдельно считаются нечётные лимиты лекций, лабораторных и практик,
+а также группы точных дублей слотов. Любое нарушение останавливает V4 с русским сообщением;
+ограничения не остаются частично применёнными и legacy-данные автоматически не меняются.
 
 ```bash
-# Kubernetes
-kubectl rollout restart deployment backend -n magistr
-
-# Docker Compose (локально)
+# После исправления legacy-данных перезапустите backend,
+# чтобы TenantConfigWatcher повторил Flyway migrate для tenant-БД.
 docker compose restart backend
 ```