много всего и тестовые данные

docs/ACADEMIC_CALENDAR.md

@@ -25,6 +25,11 @@
 
 Группа выбирает не код активности напрямую, а календарный график. Поэтому один график можно назначить нескольким группам.
 
+Список графиков в интерфейсе загружается страницами по 25 записей (также доступны 50 и 100),
+с серверным поиском и фильтром учебного года. В редакторах «Сетки» и «Дисциплины» график
+выбирается через поисковый комбобокс, который загружает до 20 результатов и выбранную запись.
+В V2 предусмотрены по 44 демонстрационных графика на 2025–2026, 2026–2027 и 2027–2028 годы.
+
 ## Коды активностей
 
 | Код | Значение | Обычные пары |
@@ -43,7 +48,8 @@
 | `*` | Праздничный или нерабочий день | Нет |
 | `=` | День вне учебного года или пустая ячейка графика | Нет |
 
-Технически разрешение генерации задаётся полем `academic_calendar_activity_types.allow_schedule`. В seed-данных `true` установлен только для `Т`.
+Технически разрешение генерации задаётся полем `academic_calendar_activity_types.allow_schedule`.
+В тестовых данных `V2__test_data.sql` значение `true` установлено только для `Т`.
 
 ## Правило генерации расписания
 

docs/API.md

@@ -597,6 +597,7 @@ GET /api/schedule?groupId=1&startDate=2026-04-27&endDate=2026-05-03
 | Метод | URL | Назначение |
 |-------|-----|------------|
 | `GET` | `/api/admin/academic-calendars` | Список графиков, фильтры `academicYearId`, `specialtyId`, `profileId` |
+| `GET` | `/api/admin/academic-calendars/page` | Страница графиков: `query`, `academicYearId`, `page`, `size` |
 | `GET` | `/api/admin/academic-calendars/options` | Асинхронный поиск совместимых графиков для комбобокса |
 | `GET` | `/api/admin/academic-calendars/{id}` | Один график |
 | `POST` | `/api/admin/academic-calendars` | Создать график |
@@ -624,6 +625,13 @@ GET /api/schedule?groupId=1&startDate=2026-04-27&endDate=2026-05-03
 название автоматически как `код специальности — профиль обучения — форма обучения — учебный год`.
 Отдельного пользовательского названия у календарного графика нет.
 
+`GET /api/admin/academic-calendars/page` возвращает `PageResponse` с полями
+`items`, `page`, `size`, `totalItems`, `totalPages`, `first`, `last`.
+Нумерация страниц начинается с 0, размер по умолчанию 25, сервер ограничивает его диапазоном 1–100.
+Поиск `query` без учёта регистра охватывает название графика, учебный год, код и название
+специальности, профиль и форму обучения. Сортировка: начало учебного года по убыванию,
+затем название и ID по возрастанию.
+
 `GET /api/admin/academic-calendars/options` принимает `query`, `academicYearId`,
 `specialtyId`, `profileId`, `studyFormId`, `selectedId` и `limit` (`1..50`). Поиск
 выполняется по составному названию, учебному году, коду/названию специальности, профилю и
@@ -718,11 +726,18 @@ CRUD доступен по:
 | Метод | URL | Назначение |
 |-------|-----|------------|
 | `GET` | `/api/admin/schedule-rules` | Список правил, фильтры `semesterId`, `groupId`, `versionId` |
+| `GET` | `/api/admin/schedule-rules/page` | Страница правил: обязательный `versionId`, параметры `query`, `page`, `size` |
 | `GET` | `/api/admin/schedule-rules/{id}` | Одно правило |
 | `POST` | `/api/admin/schedule-rules` | Создать правило |
 | `PUT` | `/api/admin/schedule-rules/{id}` | Обновить правило |
 | `DELETE` | `/api/admin/schedule-rules/{id}` | Архивировать правило |
 
+`GET /api/admin/schedule-rules/page` возвращает тот же формат `PageResponse`;
+`page` по умолчанию 0, `size` — 25 (ограничение 1–100). Правила выбранной версии,
+кроме архивных, сортируются по ID по убыванию. `query` ищет по названию дисциплины,
+названию группы или точному ID. Сначала БД выбирает страницу ID, затем загружаются
+группы и слоты только этих правил; пагинация не выполняется в памяти над полной коллекцией.
+
 `timeSlotId` должен ссылаться на базовый слот (`scopeApplyMode = DEFAULT`). Субботняя и ручные сетки не выбираются в правиле напрямую.
 
 Создание, изменение и архивирование правил разрешены внутри версии со статусом `PUBLISHED`

docs/BUSINESS_LOGIC.md

@@ -161,9 +161,9 @@ Bearer-токен проверяется на backend. Frontend-скрытие
 курса создаётся период `Т` от первой до последней даты учебного года включительно. Таким образом,
 дни обычных занятий доступны генератору сразу, а пользователь редактирует только исключения:
 сессию, каникулы, практику и другие активности. Редактирование реквизитов уже существующего
-графика не сбрасывает его периоды. Миграция `V2__backfill_default_theory_periods.sql` применяет
-такое заполнение к ранее созданным графикам только при полном отсутствии периодов; частично или
-полностью настроенные сетки она не изменяет.
+графика не сбрасывает его периоды. Та же логика сохранена внутри тестовой миграции
+`V2__test_data.sql`: после создания seed-графиков она добавляет период `Т` только графикам
+без единого периода; частично или полностью настроенные сетки не изменяются.
 
 Учебные годы и семестры изменяются через транзакционный `AcademicPeriodService`. Границы
 считаются включительными: разные учебные годы не могут иметь общую дату, а семестры не

docs/DATABASE.md

@@ -953,8 +953,8 @@ V1 создаёт GiST exclusion constraint `ex_academic_years_no_overlap` дл
 
 Пара `semester_id + version_number` уникальна. Частичный индекс
 `uq_schedule_versions_published_semester` запрещает более одной строки `PUBLISHED` на
-семестр. Начальная загрузка V1 создаёт опубликованную версию 1 для каждого семестра и
-привязывает к ней существующие seed-правила. Для семестров, создаваемых через API после
+семестр. Тестовая загрузка V2 создаёт опубликованную версию 1 для каждого seed-семестра и
+привязывает к ней тестовые правила. Для семестров, создаваемых через API после
 запуска, `AcademicPeriodService` в той же транзакции создаёт пустую опубликованную версию 1
 `Основное расписание` и две записи истории: создание и публикацию.
 
@@ -1177,10 +1177,15 @@ CHECK фиксирует допустимую форму каждого типа
 ### Правила работы
 
 1. Все миграции находятся в `backend/src/main/resources/db/migration/`
-2. Формат имени: `V{номер}__{описание}.sql` (напр. `V1__init.sql`, `V2__add_departments.sql`)
-3. **ЗАПРЕЩЕНО** изменять уже закоммиченные файлы миграций — это сломает контрольные суммы Flyway. Исключение допускается только по прямой просьбе пользователя и при полном сбросе tenant-БД.
-4. Flyway запускается **программно** при первом обращении к БД тенанта (`TenantConfigWatcher.initDatabaseForTenant()`)
-5. Настройка `baselineOnMigrate=true` — непустая БД без истории будет помечена baseline и
+2. Пока действует режим пересобираемого baseline, вся постоянная схема, функции, индексы,
+   триггеры и ограничения изменяются только в `V1__init.sql`.
+3. `V2__test_data.sql` содержит только тестовые/демонстрационные данные. Постоянный DDL в
+   ней запрещён; временные staging-таблицы должны удаляться до завершения миграции.
+4. `V3` и последующие миграции не создаются до отдельного решения владельца.
+5. Изменение V1/V2 меняет контрольные суммы Flyway и требует полного сброса затронутых
+   tenant-БД. Сброс выполняется только по прямой команде владельца.
+6. Flyway запускается **программно** при первом обращении к БД тенанта (`TenantConfigWatcher.initDatabaseForTenant()`)
+7. Настройка `baselineOnMigrate=true` — непустая БД без истории будет помечена baseline и
    `V1` не выполнится; поэтому текущую консолидированную V1 применяют только к полностью
    пустой tenant-схеме
 
@@ -1188,19 +1193,46 @@ CHECK фиксирует допустимую форму каждого типа
 
 | Файл | Описание |
 |------|----------|
-| `V1__init.sql` | Полная baseline-схема: справочники, роли, refresh-сессии JWT, PostgreSQL rate limit и аудит входа, lifecycle-поля, история кафедр, календарные графики, динамическое расписание, версии/черновики и аудит публикаций, точечные изменения, отсутствия и журнал замен, пожелания преподавателей, заявки на изменение занятий и их история, seed, CHECK/UNIQUE/GiST-ограничения, конкурентно безопасные триггеры и комментарии |
-| `V2__backfill_default_theory_periods.sql` | Добавляет периоды `Т` на весь учебный год для каждого курса только в полностью пустых календарных графиках; уже настроенные графики не изменяет |
+| `V1__init.sql` | Полная schema-only baseline: таблицы, связи, refresh-сессии JWT, PostgreSQL rate limit и аудит входа, lifecycle-поля, календарные графики, динамическое расписание, версии/черновики и аудит публикаций, точечные изменения, отсутствия, пожелания и заявки преподавателей, CHECK/UNIQUE/GiST-ограничения, конкурентно безопасные триггеры и комментарии. Постоянных доменных данных нет |
+| `V2__test_data.sql` | Единый тестовый seed: прежние демонстрационные записи V1, справочники и полный набор связанных нагрузочных данных. Здесь же после создания графиков сохранена логика прежней V2: период `Т` на весь год добавляется каждому курсу только полностью пустого графика |
 
 ### Этап разработки
 
-Исторические разработческие миграции V2–V7, а затем повторно созданные V2 с отсутствиями
-и мастером замены и V3 с пожеланиями и заявками преподавателей по прямому решению владельца
-проекта объединены в baseline `V1`. После фиксации baseline новые изменения оформляются
-отдельными инкрементальными миграциями; первой стала `V2__backfill_default_theory_periods.sql`.
-Интервальное хранение активностей и правильная нумерация недель календарного графика входят
-непосредственно в V1.
-Существующая tenant-БД с уже применённой V1 получает V2 без изменения контрольной суммы
-baseline. Для развёртывания V1 с нуля по-прежнему требуется пустая tenant-схема.
+Исторические разработческие изменения объединены в schema-only baseline `V1`. По решению
+владельца проект временно не наращивает цепочку миграций: изменения постоянной схемы вносятся
+в V1, а V2 полностью зарезервирована под тестовый набор. Такой режим рассчитан на пересоздание
+tenant-БД с нуля и несовместим с сохранением прежних контрольных сумм V1/V2.
+
+`V2__test_data.sql` применяется общим `TenantDatabaseMigrationService` без разделения по
+Spring-профилям, поэтому сейчас тестовый набор попадёт в каждый новый tenant, включая
+production. Это сознательное ограничение текущего режима разработки; перед production-релизом
+V2 необходимо сделать условной или исключить из production locations.
+
+### Объём тестового набора V2
+
+На чистой схеме V2 создаёт детерминированный связанный набор:
+
+| Сущности | Количество |
+|----------|-----------:|
+| Кафедры / специальности / профили | 41 / 42 / 42 |
+| Пользователи / преподаватели | 155 / 151 |
+| Группы / подгруппы | 202 / 404 |
+| Дисциплины / связи преподаватель–дисциплина / разрешённые типы занятий | 229 / 844 / 2532 |
+| Аудитории / связи с оборудованием | 80 / 174 |
+| Календарные графики / периоды / дисциплины графиков / назначения групп | 132 / 576 / 3456 / 202 |
+| Версии / события истории | 8 / 16 |
+| Правила / связи с группами / слоты / лабораторные подгруппы | 610 / 611 / 610 / 202 |
+| Пожелания / отсутствия / комментарии к дисциплинам | 60 / 20 / 40 |
+
+Учебные годы: 2024–2025, 2025–2026, 2026–2027 и 2027–2028. Для трёх последних
+создаётся одинаковый набор из 44 графиков направлений с периодами теоретического обучения
+и дисциплинами по семестрам. Назначения существующих групп сохраняются на 2025–2026 год.
+
+Из 202 групп две (`ИВТ-21-1`, `ИБ-41м`) перенесены из прежней V1, ещё 200 созданы по
+шифрам направлений ЮЗГУ. Источниками названий служат публичные страницы структуры,
+приёмной кампании и перечней дисциплин ЮЗГУ; ФИО 150 массовых преподавателей синтетические
+и имеют непубликуемый случайный пароль. Доступны для ручного входа только документированные
+исторические demo-аккаунты.
 
 ### Полный сброс БД (локально)
 

docs/DEVELOPMENT.md

@@ -251,18 +251,18 @@ public class AbsenceController {
 
 ### Правила
 
-1. **Никогда** не изменяйте уже закоммиченные файлы миграций без прямой просьбы пользователя
-2. Имя файла: `V{номер}__{описание}.sql` (два подчёркивания!)
-3. Нумерация строго инкрементальная: `V1`, `V2`, `V3`, ...
-4. После добавления — перезапустите backend для применения
+1. До отдельного решения владельца вся постоянная схема изменяется только в `V1__init.sql`
+2. `V2__test_data.sql` предназначена исключительно для тестовых и демонстрационных данных;
+   постоянный DDL в ней запрещён
+3. Не создавайте `V3` и следующие миграции, пока владелец не отменит режим пересобираемого baseline
+4. Любое изменение V1/V2 требует полного сброса затронутых tenant-БД из-за checksum mismatch
+5. Не сбрасывайте tenant-БД без прямой команды владельца
 
-Изменение `V1__init.sql` допустимо только как осознанное исключение на этапе разработки. Для уже применённой `V1` требуется полный сброс tenant-схем или удаление истории Flyway перед запуском backend, иначе будет checksum mismatch.
-
-`V1__init.sql` зафиксирован как baseline: по прямому решению владельца в него объединено
-содержимое прежних разработческих V2–V7, а также таблицы отсутствий, решений по заменам,
-пожеланий и заявок преподавателей. Новые изменения существующих tenant-БД оформляются только
-отдельными инкрементальными миграциями. Текущая `V2__backfill_default_theory_periods.sql`
-заполняет кодом `Т` полностью пустые календарные графики и не изменяет V1.
+`V1__init.sql` содержит только структуру: таблицы, функции, триггеры, индексы, ограничения
+и комментарии. `V2__test_data.sql` содержит все прежние seed-записи, большой связанный набор
+и заполнение периодов `Т` для полностью пустых календарных графиков. Такое разделение позволяет
+отдельно проверить schema-only V1, но обе миграции по-прежнему автоматически применяются ко
+всем tenant-БД.
 
 ### Применение
 
@@ -270,6 +270,10 @@ public class AbsenceController {
 # Локально — сброс и повтор всех миграций
 docker compose down -v && docker compose up -d
 
+# Интеграционная проверка V1/V2 на PostgreSQL через Testcontainers
+cd backend
+mvn -Dtest='com.magistr.app.migration.*IntegrationTest' test
+
 # Продакшн — применить к существующим тенантам
 kubectl rollout restart deployment backend -n magistr
 ```

docs/DYNAMIC_SCHEDULE_IMPLEMENTATION.md

@@ -4,13 +4,17 @@
 
 ## Статус
 
-Новая модель является базовой схемой проекта и создаётся в `backend/src/main/resources/db/migration/V1__init.sql`. Раздельные часы и недели начала по типам занятий уже включены в эту базовую схему; применение рассчитано на полный сброс БД.
+Новая модель является базовой схемой проекта и создаётся в
+`backend/src/main/resources/db/migration/V1__init.sql`. Раздельные часы и недели начала по
+типам занятий уже включены в schema-only baseline, а все демонстрационные записи загружаются
+отдельно из `V2__test_data.sql`. Применение рассчитано на полный сброс БД.
 
 Старый ручной слой занятий удалён. Динамическое расписание строится из правил `schedule_rules`, слотов `schedule_rule_slots` и календарного учебного графика группы.
 
 ## База данных
 
-`V1__init.sql` создаёт и заполняет:
+`V1__init.sql` создаёт структуру следующих таблиц, а `V2__test_data.sql` заполняет их
+связанным тестовым набором:
 
 | Таблица | Назначение |
 |---------|------------|

docs/README.md

@@ -65,6 +65,11 @@ Caddy использует локальный корневой сертифик
 | `admin` | `admin` | Администратор |
 | `Тестовый преподаватель` | `1234567890` | Преподаватель |
 
+Эти и остальные прежние демонстрационные записи загружаются миграцией
+`V2__test_data.sql`. Она также создаёт 200 дополнительных групп, 150 синтетических
+преподавателей и связанные дисциплины, аудитории, календари и правила расписания.
+Пароли массовых преподавателей генерируются случайно и не предназначены для входа.
+
 ### Полезные команды
 
 ```bash

docs/SCHEDULE_PROPOSAL.md

@@ -37,7 +37,8 @@
 2. Для группы находится назначенный календарный учебный график.
 3. По году начала обучения вычисляется текущий курс группы.
 4. По курсу и дате находится код активности.
-5. Обычные пары генерируются только для кода, где `allow_schedule = true`; в seed-данных это `Т`.
+5. Обычные пары генерируются только для кода, где `allow_schedule = true`; в тестовых данных
+   `V2__test_data.sql` это `Т`.
 6. Для разрешённого дня выбираются активные правила и слоты.
 7. Лимит часов считается только по реально проведённым занятиям; для лабораторных подгрупп счётчик ведётся отдельно по каждой подгруппе.
 

docs/SCHEDULE_TASKS.md

@@ -27,7 +27,8 @@
 ## Проверочный сценарий
 
 1. Полностью сбросить локальную БД.
-2. Запустить приложение и применить `V1__init.sql`.
+2. Запустить приложение и применить schema-only `V1__init.sql`, затем тестовый набор
+   `V2__test_data.sql`.
 3. Создать профиль специальности.
 4. Создать календарный график и заполнить дневную сетку.
 5. Назначить график группе.