Идеи

2026-08-05 23:31:48 +03:00
parent 840554c223
commit 8f8ce0240b
2 changed files with 587 additions and 0 deletions
--- a/docs/FEATURE_IDEAS.md
+++ b/docs/FEATURE_IDEAS.md
@@ -0,0 +1,586 @@
+# Идеи развития проекта Magistr
+
+Документ содержит продуктовые предложения для дальнейшего развития системы управления
+университетским расписанием. Это не утверждённые требования и не техническая спецификация:
+каждое направление перед реализацией требует отдельного согласования границ, ролей,
+контрактов API и модели данных.
+
+## Текущее состояние проекта
+
+Основное ядро системы уже реализовано и не требует повторного создания в новых модулях:
+
+- динамическое расписание строится из правил, календарных учебных графиков и временных
+  слотов, а не хранится как набор отдельных занятий на каждую дату;
+- правила поддерживают лекции, практики, лабораторные работы, потоки, подгруппы,
+  чётность недель и лимиты академических часов;
+- при сохранении правил проверяются конфликты преподавателей, аудиторий, групп и подгрупп;
+- учебный отдел может отменять, переносить и заменять отдельные занятия через точечные
+  изменения расписания;
+- доступны поиск расписаний, проверка конфликтов, отчёты по нагрузке и поиск свободных
+  аудиторий;
+- существуют отдельные кабинеты администратора, учебного отдела, кафедры, преподавателя
+  и студента;
+- данные университетов изолированы мультитенантной архитектурой.
+
+Подробное описание текущих возможностей приведено в
+[бизнес-логике](BUSINESS_LOGIC.md), [REST API](API.md),
+[документации frontend](FRONTEND.md) и
+[концепции динамического расписания](SCHEDULE_PROPOSAL.md).
+
+Новые функции ниже должны расширять это ядро и по возможности повторно использовать
+`ScheduleGeneratorService`, `ScheduleQueryService`, проверки конфликтов, механизм
+`schedule_overrides` и существующую ролевую модель.
+
+## Сравнение направлений
+
+Оценки являются относительными:
+
+- **S** — локальное улучшение без нового крупного бизнес-процесса;
+- **M** — новая модель, API и пользовательский экран;
+- **L** — сквозной модуль, сложный алгоритм или изменение жизненного цикла расписания.
+
+| Направление | Польза | Сложность | Демонстрационный эффект | Повторное использование текущего ядра |
+|-------------|:------:|:---------:|:-----------------------:|:-------------------------------------:|
+| Отсутствия и мастер замены | 5/5 | M–L | 5/5 | Высокое |
+| Версии и публикация расписания | 5/5 | M–L | 5/5 | Высокое |
+| Пожелания и заявки преподавателей | 4/5 | M | 4/5 | Высокое |
+| Центр уведомлений | 5/5 | M | 4/5 | Среднее |
+| Привязка студента к группе | 4/5 | M | 3/5 | Высокое |
+| Подписка через ICS | 4/5 | S–M | 4/5 | Высокое |
+| Импорт графика из Excel | 4/5 | M | 4/5 | Высокое |
+| Анализ качества и автооптимизатор | 5/5 | L | 5/5 | Высокое |
+| Расписание экзаменационной сессии | 5/5 | L | 5/5 | Среднее |
+
+## 1. Отсутствия преподавателей и мастер замены
+
+### Проблема и пользователи
+
+Болезнь, командировка или другое временное отсутствие преподавателя затрагивает сразу
+несколько занятий. Сейчас учебному отделу нужно самостоятельно найти эти занятия, проверить
+доступность ресурсов и создать каждое точечное изменение. Функция нужна учебному отделу,
+кафедрам и преподавателям.
+
+Регистрация отсутствий и мастер разрешения инцидентов уже обозначены как планируемые
+бизнес-правила в [BUSINESS_LOGIC.md](BUSINESS_LOGIC.md), но отдельной модели и рабочего
+сценария пока нет. Существующая Red Zone уже выявляет конфликты сформированного расписания;
+новизна этого направления заключается в реестре причин, массовом поиске затронутых занятий
+и управляемом подборе решений.
+
+### Пользовательский сценарий
+
+1. Ответственный сотрудник указывает преподавателя, период отсутствия и причину.
+2. Система строит список всех затронутых занятий в этом периоде.
+3. Для каждого занятия показываются возможные решения:
+   - назначить свободного преподавателя, который может вести дисциплину и тип занятия;
+   - перенести занятие на ближайшее допустимое время;
+   - подобрать другую свободную аудиторию;
+   - отменить занятие, если перенос или замена невозможны.
+4. Пользователь проверяет предложения и подтверждает только выбранные действия.
+5. Система создаёт обычные `schedule_overrides`, поэтому итоговое расписание продолжает
+   формироваться единым существующим механизмом.
+
+### Минимальная версия
+
+- реестр отсутствий с преподавателем, периодом, причиной и статусом;
+- поиск затронутых занятий через текущий генератор расписания;
+- подбор свободных квалифицированных преподавателей;
+- проверка времени, аудитории, групп и подгрупп существующим механизмом конфликтов;
+- групповое подтверждение предложений с созданием переносов, замен или отмен;
+- журнал принятых и отклонённых решений.
+
+### Связь с текущей системой
+
+Модуль может использовать привязки «преподаватель ↔ дисциплина», поддерживаемые типы
+занятий, `ScheduleQueryService`, отчёты нагрузки, поиск свободных аудиторий и
+`ScheduleOverrideService`. Временное отсутствие не должно переписывать базовые правила
+семестра: изменения остаются точечными и обратимыми.
+
+### Дальнейшее развитие
+
+- автоматическая рассылка уведомлений затронутым группам и преподавателям;
+- пакетная обработка нескольких одновременных отсутствий;
+- ранжирование вариантов по числу переносов, окнам и дополнительной нагрузке;
+- делегирование регистрации отсутствия самому преподавателю с подтверждением кафедры;
+- статистика причин и среднего времени разрешения инцидентов.
+
+**Ожидаемый результат:** сокращение ручной работы и времени реакции на изменения.
+**Сложность:** M–L. **Демонстрационный эффект:** очень высокий, поскольку сценарий
+показывает работу генератора, проверок и точечных изменений как единой системы.
+
+## 2. Черновики, версии, публикация и аудит расписания
+
+### Проблема и пользователи
+
+Изменение активного правила сейчас сразу влияет на следующий запрос расписания. При большой
+переработке семестра это создаёт риск показать студентам и преподавателям промежуточное
+состояние. Учебному отделу нужен безопасный цикл «подготовить — проверить — опубликовать».
+
+В таблице `schedule_rules` уже предусмотрены поля `version_group_id`, `change_reason`,
+`created_by` и `created_at`, которые можно использовать как основу, но полноценный жизненный
+цикл версий пока не реализован.
+
+### Пользовательский сценарий
+
+1. Пользователь создаёт черновик расписания для выбранного семестра.
+2. Все изменения правил применяются только к черновику и не видны обычным пользователям.
+3. Перед публикацией система проверяет конфликты и показывает сравнение с текущей версией:
+   добавленные, удалённые и изменённые занятия.
+4. Ответственный сотрудник указывает причину и публикует версию одной операцией.
+5. Студенты и преподаватели начинают видеть только полностью опубликованный вариант.
+6. При необходимости администратор может восстановить предыдущую опубликованную версию.
+
+### Минимальная версия
+
+- статусы версии: черновик, опубликована, архивирована;
+- одна активная опубликованная версия на семестр;
+- автор, время создания, причина изменения и история публикаций;
+- проверка всего черновика перед публикацией;
+- понятный diff на уровне правил и сформированных занятий;
+- атомарная публикация без промежуточного состояния;
+- возврат к предыдущей опубликованной версии.
+
+### Связь с текущей системой
+
+Текущая динамическая генерация сохраняется, но получает явный контекст версии. Конструктор
+правил работает с черновиком, а кабинеты просмотра — с опубликованной версией. Точечные
+изменения можно вести отдельным аудитом либо включать в пакет публикации в зависимости от
+будущих продуктовых требований.
+
+### Дальнейшее развитие
+
+- согласование черновика несколькими ролями;
+- комментарии и замечания к версии;
+- публикация по кафедрам или учебным потокам;
+- запланированная публикация в указанное время;
+- цифровое подтверждение и неизменяемый журнал действий.
+
+**Ожидаемый результат:** предсказуемое расписание для конечных пользователей и безопасная
+работа учебного отдела. **Сложность:** M–L. **Демонстрационный эффект:** высокий за счёт
+наглядного сравнения и управляемой публикации.
+
+## 3. Пожелания преподавателей и заявки на перенос
+
+### Проблема и пользователи
+
+Кабинет преподавателя сейчас предназначен только для просмотра недельного расписания.
+Пожелания о времени и запросы на изменение обычно передаются вне системы, после чего
+учебному отделу приходится вручную переносить данные и проверять их актуальность.
+
+### Пользовательский сценарий
+
+1. Преподаватель отмечает предпочтительные и нежелательные временные интервалы, а также
+   даты полной недоступности.
+2. Кафедра или учебный отдел проверяет и утверждает ограничения на семестр.
+3. Утверждённые данные подсвечиваются в конструкторе правил и учитываются мастером замены.
+4. Для уже опубликованного занятия преподаватель может отправить отдельную заявку на
+   перенос, замену аудитории или отмену.
+5. Учебный отдел получает заявку вместе с результатом предварительной проверки конфликтов
+   и принимает либо отклоняет её с комментарием.
+
+### Минимальная версия
+
+- календарь доступности преподавателя на семестр;
+- разделение строгой недоступности и мягких пожеланий;
+- заявка, статус, комментарий и история решения;
+- предварительный поиск допустимых слотов для выбранного занятия;
+- применение одобренной заявки через существующий механизм overrides;
+- уведомление преподавателя о результате.
+
+### Связь с текущей системой
+
+Используются кабинет преподавателя, данные семестров и сеток времени, привязки
+преподавателей к дисциплинам, проверка конфликтов и `ScheduleOverrideService`. Пожелания
+могут стать входными данными для будущего оптимизатора, но не должны автоматически менять
+опубликованное расписание.
+
+### Дальнейшее развитие
+
+- ограничения на максимальное число пар в день;
+- предпочтения по корпусам и аудиториям;
+- пожелания «пары подряд» или «без окон»;
+- массовое копирование предпочтений из прошлого семестра;
+- автоматическое ранжирование заявок по срочности и влиянию.
+
+**Ожидаемый результат:** формализованная коммуникация между преподавателем, кафедрой и
+учебным отделом. **Сложность:** M. **Демонстрационный эффект:** высокий.
+
+## 4. Центр уведомлений
+
+### Проблема и пользователи
+
+Даже корректно внесённое изменение бесполезно, если преподаватель или студенты узнают о нём
+слишком поздно. Системе нужен единый способ сообщать об отменах, переносах, заменах и
+публикации нового расписания.
+
+### Пользовательский сценарий
+
+1. После подтверждённого изменения система определяет затронутых пользователей.
+2. В центре уведомлений появляется сообщение с понятным сравнением «было / стало».
+3. Пользователь открывает сообщение, переходит к нужной неделе и отмечает его прочитанным.
+4. В настройках можно включить или отключить дополнительные каналы для разных типов
+   событий.
+
+### Минимальная версия
+
+- внутренний центр уведомлений;
+- события: публикация версии, перенос, отмена, замена преподавателя или аудитории;
+- адресация преподавателю и связанным с группой студентам;
+- статусы «новое / прочитано»;
+- ссылка на изменённое занятие и данные до/после;
+- надёжная очередь формирования уведомлений после успешной транзакции изменения.
+
+Внутренний центр следует реализовать первым. Почта, Web Push и Telegram требуют внешней
+конфигурации, управления согласиями и отдельной политики повторных отправок.
+
+### Связь с текущей системой
+
+Источниками событий становятся `schedule_overrides` и публикация версии расписания.
+Персональные студенческие уведомления зависят от реализации связи пользователя с группой и
+подгруппой. Для технических метрик доставки можно использовать существующую систему
+логирования и OpenTelemetry.
+
+### Дальнейшее развитие
+
+- Web Push для браузеров и мобильных устройств;
+- почтовые и Telegram-уведомления;
+- ежедневная сводка вместо отдельных сообщений;
+- повторное напоминание о срочной отмене;
+- журнал доставки и пользовательские настройки каналов.
+
+**Ожидаемый результат:** снижение числа пропущенных изменений. **Сложность:** M.
+**Демонстрационный эффект:** высокий, особенно вместе с мастером замены.
+
+## 5. Привязка студента к группе и подгруппе
+
+### Проблема и пользователи
+
+Студент сейчас выбирает любую группу вручную, а выбранный идентификатор сохраняется только
+в `localStorage.studentGroupId`. У системы нет персонального контекста студента, поэтому
+нельзя надёжно показать его подгруппу или адресовать ему уведомления.
+
+### Пользовательский сценарий
+
+1. Администратор создаёт студента и назначает ему группу и при необходимости лабораторную
+   подгруппу.
+2. После входа студент сразу попадает в раздел «Моё расписание».
+3. Расписание автоматически фильтруется по его группе и подгруппе.
+4. При переводе сохраняется история принадлежности, чтобы прошлое расписание оставалось
+   корректным.
+
+### Минимальная версия
+
+- связь пользователя с учебной группой и опциональной подгруппой;
+- редактирование связи в административном интерфейсе;
+- выдача группы и подгруппы в профиле текущего пользователя;
+- автоматическая загрузка личного расписания без `localStorage` как источника истины;
+- проверка соответствия подгруппы выбранной группе;
+- безопасное поведение для студента, которому группа ещё не назначена.
+
+### Связь с текущей системой
+
+Используются существующие `User`, `StudentGroup`, `Subgroup`, авторизация и студенческий
+кабинет. Динамический генератор уже умеет фильтровать лабораторные занятия по подгруппам,
+поэтому новая связь завершает пользовательский сценарий без создания второго механизма
+расписания.
+
+### Дальнейшее развитие
+
+- история переводов между группами;
+- индивидуальные элективные дисциплины;
+- староста и дополнительные роли внутри группы;
+- персональные экзамены и уведомления;
+- импорт состава групп из внешней информационной системы.
+
+**Ожидаемый результат:** настоящий персональный кабинет студента и основа для адресных
+сервисов. **Сложность:** M. **Демонстрационный эффект:** средний, продуктовая ценность —
+высокая.
+
+## 6. Персональная подписка на расписание через ICS
+
+### Проблема и пользователи
+
+Преподаватели и студенты вынуждены открывать отдельный сайт, чтобы проверить расписание.
+Подписка на календарь позволит видеть актуальные занятия в Google Calendar, Apple Calendar,
+Outlook, Яндекс Календаре и других совместимых приложениях.
+
+Формат следует строить на открытом стандарте
+[iCalendar RFC 5545](https://www.rfc-editor.org/info/rfc5545/).
+
+### Пользовательский сценарий
+
+1. Пользователь открывает раздел интеграций и создаёт персональную ссылку.
+2. Ссылка добавляется в календарное приложение напрямую или через QR-код.
+3. Приложение периодически обновляет календарь, получая актуальные занятия с учётом
+   переносов, замен и отмен.
+4. Пользователь может отозвать ссылку и создать новую.
+
+### Минимальная версия
+
+- read-only ICS-feed для преподавателя и учебной группы;
+- персональный непрогнозируемый токен вместо JWT в URL;
+- стабильный `UID` события, корректные дата, время, часовой пояс и место;
+- отражение актуальных overrides;
+- отзыв и ротация токена;
+- кнопка копирования ссылки и краткая инструкция подключения.
+
+### Связь с текущей системой
+
+Feed формируется через `ScheduleQueryService` и не хранит отдельную копию расписания.
+Преподавательский календарь можно реализовать сразу, а персональный студенческий вариант
+становится полноценным после привязки студента к группе и подгруппе. При внедрении версий
+feed должен отдавать только опубликованное расписание. Текущий API ограничивает один запрос
+расписания диапазоном в 120 дней, поэтому подписке понадобится ограниченное скользящее окно
+либо внутренняя генерация последовательных диапазонов вместо безграничного запроса на весь
+период обучения.
+
+### Дальнейшее развитие
+
+- отдельные календари экзаменов и консультаций;
+- подписки для аудиторий и кафедр;
+- экспорт выбранного диапазона отдельным `.ics`-файлом;
+- дополнительные напоминания через `VALARM`;
+- интеграция через CalDAV при появлении соответствующей потребности.
+
+**Ожидаемый результат:** расписание становится частью привычного календаря пользователя.
+**Сложность:** S–M. **Демонстрационный эффект:** высокий при относительно небольшом объёме
+работ.
+
+## 7. Импорт календарного учебного графика из Excel
+
+### Проблема и пользователи
+
+Календарные графики обычно существуют в виде Excel-таблиц с кодами `Т`, `Э`, `К`, `У`,
+`П` и другими активностями. Сейчас администратор переносит эти данные в дневную сетку
+вручную. В [ACADEMIC_CALENDAR.md](ACADEMIC_CALENDAR.md) прямо указано, что Excel-импорт в
+первой реализации не предусмотрен.
+
+### Пользовательский сценарий
+
+1. Администратор скачивает утверждённый шаблон или выбирает существующий XLSX-файл.
+2. Система распознаёт лист, курсы, недели, дни и коды активностей.
+3. Перед сохранением показывается предварительная сетка и список ошибок с адресами ячеек.
+4. Пользователь исправляет файл либо подтверждает корректный результат.
+5. Данные применяются атомарно через текущий сервис полной замены сетки.
+
+### Минимальная версия
+
+- один документированный XLSX-шаблон;
+- импорт одного календарного графика;
+- распознавание курсов, дат и известных кодов активностей;
+- режим предварительной проверки без записи;
+- понятные ошибки с номером листа и ячейки;
+- запрет частичного сохранения при любой ошибке;
+- итоговое применение через `AcademicCalendarGridService`.
+
+### Связь с текущей системой
+
+Импорт должен преобразовывать Excel в существующий дневной REST-контракт, а не создавать
+параллельную модель хранения. Все проверки дат, учебного года, ISO-недель, уникальности и
+кодов активностей остаются в `AcademicCalendarGridService`.
+
+### Дальнейшее развитие
+
+- сопоставление колонок для нескольких распространённых шаблонов;
+- экспорт текущего графика обратно в XLSX;
+- импорт дисциплин и учебных планов;
+- сравнение файла с сохранённым графиком до применения;
+- пакетная загрузка нескольких профилей и форм обучения.
+
+**Ожидаемый результат:** заметное сокращение ручного заполнения и ошибок ввода.
+**Сложность:** M. **Демонстрационный эффект:** высокий благодаря наглядному предпросмотру.
+
+## 8. Анализ качества и автоматическая оптимизация расписания
+
+### Проблема и пользователи
+
+Текущее расписание может быть формально корректным, но неудобным: большие окна, перегруженные
+дни, неравномерная нагрузка, слишком крупная аудитория для небольшой группы или игнорирование
+пожеланий преподавателя. Существующая проверка конфликтов отвечает на вопрос «можно ли
+сохранить», но не оценивает качество допустимого варианта.
+
+### Рекомендуемое разделение на этапы
+
+#### Этап 1. Анализатор качества
+
+- рассчитывает окна групп и преподавателей;
+- показывает равномерность занятий по дням;
+- сравнивает вместимость аудитории с численностью групп;
+- учитывает пожелания и недоступность преподавателей;
+- выявляет чрезмерную дневную нагрузку;
+- формирует объяснимую итоговую оценку и список проблем.
+
+#### Этап 2. Помощник перестановок
+
+- предлагает несколько свободных слотов или аудиторий для выбранной проблемы;
+- показывает, какие показатели улучшатся или ухудшатся;
+- применяет вариант только после подтверждения пользователя;
+- сохраняет ручные закрепления, которые оптимизатор не имеет права менять.
+
+#### Этап 3. Полный оптимизатор
+
+- строит один или несколько вариантов расписания для выбранного семестра;
+- соблюдает все строгие ограничения;
+- минимизирует штрафы мягких ограничений;
+- сохраняет результат как черновик, а не публикует автоматически.
+
+### Минимальная версия
+
+Практичнее начать не с полного solver, а с анализатора и локальных рекомендаций для одного
+конфликтного или неудобного занятия. Такой MVP позволяет проверить метрики качества,
+интерфейс объяснений и производительность на реальных данных.
+
+Red Zone уже выявляет накладки и превышение вместимости, а вкладка загруженности показывает
+занятые и свободные слоты. Новый анализатор не должен дублировать эти экраны: его ценность —
+единая объяснимая оценка, мягкие критерии качества и рекомендации по улучшению.
+
+### Связь с текущей системой
+
+Исходными данными становятся правила, сформированные занятия, размеры групп, вместимость
+аудиторий, квалификации и пожелания преподавателей. Для проверки кандидатов повторно
+используются существующие валидаторы конфликтов. Версии и черновики дают безопасное место
+для результатов оптимизации.
+
+В качестве внешнего ориентира можно использовать подходы из официального
+[руководства по solver UniTime](https://help.unitime.org/manuals/courses-solver), не копируя
+его внутреннюю реализацию.
+
+### Дальнейшее развитие
+
+- настройка весов критериев для каждого тенанта;
+- сравнение нескольких найденных вариантов;
+- фоновый расчёт с прогрессом и возможностью остановки;
+- автоматическое локальное исправление после инцидента;
+- сохранение обезличенных метрик качества по семестрам.
+
+**Ожидаемый результат:** переход от проверки корректности к измеримому повышению качества
+расписания. **Сложность:** L. **Демонстрационный эффект:** максимальный и подходящий для
+исследовательской части магистерской работы.
+
+## 9. Расписание экзаменационной сессии
+
+### Проблема и пользователи
+
+Календарный учебный график уже поддерживает код экзаменационной сессии `Э`, но обычные
+занятия на таких датах намеренно не генерируются. Отдельной модели экзаменов, консультаций,
+экзаменаторов и экзаменационных аудиторий пока нет.
+
+### Пользовательский сценарий
+
+1. Учебный отдел задаёт экзаменационные периоды семестра.
+2. Кафедры указывают дисциплины, группы, экзаменаторов, длительность и особые требования.
+3. Система проверяет допустимые даты, вместимость и занятость ресурсов.
+4. Пользователь вручную размещает экзамены или запускает подбор вариантов.
+5. После проверки экзаменационное расписание публикуется студентам и преподавателям.
+
+### Минимальная версия
+
+- экзамен и консультация как отдельные сущности, не маскируемые под обычную пару;
+- связь с дисциплиной, семестром, группами и экзаменаторами;
+- дата, период, длительность и одна или несколько аудиторий;
+- проверка пересечений групп, преподавателей и помещений;
+- проверка суммарной вместимости аудиторий;
+- ручной конструктор и отдельный режим просмотра;
+- публикация в личных кабинетах и календарных feeds.
+
+На первом этапе конфликты можно считать на уровне групп. Для индивидуальных конфликтов
+студентов понадобится модель зачислений на дисциплины или экзамены.
+
+### Связь с текущей системой
+
+Модуль использует семестры, коды календарной активности, группы, дисциплины, преподавателей,
+аудитории и общий подход к проверке ресурсов. При этом экзаменационное расписание должно
+оставаться отдельным доменом: у экзаменов другие длительности, правила вместимости и
+критерии качества.
+
+Полезным внешним ориентиром является официальное
+[руководство UniTime по экзаменационному расписанию](https://help.unitime.org/manuals/examination-timetabling).
+
+### Дальнейшее развитие
+
+- автоматическое распределение экзаменов по периодам и аудиториям;
+- минимизация двух экзаменов подряд и перегруженных экзаменационных дней;
+- индивидуальные конфликты студентов;
+- печатные ведомости, рассадка и распределение по нескольким аудиториям;
+- отчёты по использованию экзаменационных помещений.
+
+**Ожидаемый результат:** новый самостоятельный контур учебного процесса на основе уже
+существующих справочников и календаря. **Сложность:** L. **Демонстрационный эффект:**
+максимальный.
+
+## Рекомендуемые варианты развития
+
+### Быстрые продуктовые улучшения
+
+1. Привязать студента к группе и подгруппе.
+2. Добавить ICS-подписку для преподавателей и групп.
+3. Реализовать импорт календарного графика из одного утверждённого Excel-шаблона.
+
+Эти задачи относительно изолированы, сразу заметны пользователям и подготавливают данные
+для уведомлений и персональных сервисов.
+
+### Следующий крупный релиз
+
+Объединить отсутствия преподавателей, мастер замены и внутренний центр уведомлений в один
+сквозной сценарий:
+
+```text
+Регистрация отсутствия
+        ↓
+Поиск затронутых занятий
+        ↓
+Подбор допустимых решений
+        ↓
+Подтверждение overrides
+        ↓
+Уведомление пользователей
+```
+
+Это направление максимально использует уже готовые механизмы и показывает практическую
+ценность системы в ежедневной работе университета.
+
+### Архитектурное развитие
+
+Перед массовой автоматизацией изменений целесообразно внедрить версии, черновики и
+публикацию. Такой жизненный цикл защищает конечных пользователей от промежуточного состояния
+и создаёт безопасную основу для мастера инцидентов и оптимизатора.
+
+### Исследовательское направление
+
+Для магистерской работы наиболее сильны два варианта:
+
+- анализ качества и оптимизация расписания с объяснимыми строгими и мягкими ограничениями;
+- отдельный модуль экзаменационной сессии с задачей размещения экзаменов и минимизации
+  конфликтов.
+
+Оптимизатор лучше начинать с оценки качества и локальных рекомендаций. Экзаменационный
+модуль — с ручного конструктора и строгой проверки ресурсов. Это позволит получить полезный
+MVP до разработки полного solver.
+
+## Предлагаемый порядок реализации
+
+1. Персональный контекст студента.
+2. ICS-подписки и Excel-импорт как независимые быстрые функции.
+3. Версии, черновики, аудит и публикация расписания.
+4. Отсутствия преподавателей и мастер замены.
+5. Внутренний центр уведомлений, затем внешние каналы.
+6. Пожелания преподавателей и заявки на перенос.
+7. Анализатор качества и локальные рекомендации.
+8. Полный оптимизатор либо экзаменационный модуль как отдельный крупный этап.
+
+Порядок не является обязательным roadmap. Он показывает зависимости между идеями и должен
+быть пересмотрен после выбора ближайших продуктовых целей.
+
+## Внешние ориентиры
+
+- [RFC 5545: Internet Calendaring and Scheduling Core Object Specification](https://www.rfc-editor.org/info/rfc5545/)
+  — стандарт формата iCalendar.
+- [UniTime: Course Timetabling Solver Manual](https://help.unitime.org/manuals/courses-solver)
+  — ограничения, варианты расписаний и публикация результата.
+- [UniTime: Instructor Survey](https://help.unitime.org/instructor-survey)
+  — сбор предпочтений и требований преподавателей.
+- [UniTime: Examination Timetabling Manual](https://help.unitime.org/manuals/examination-timetabling)
+  — отдельная предметная область экзаменационного расписания.
+
+Эти материалы используются только как ориентиры для продуктовой проработки. Конкретные
+контракты, модели данных и пользовательские сценарии должны соответствовать архитектуре и
+ролевой модели Magistr.
--- a/docs/README.md
+++ b/docs/README.md
@@ -121,6 +121,7 @@ magistr/
 |----------|-----------|
 | [Архитектура](ARCHITECTURE.md) | Общая архитектура, мультитенантность, взаимодействие компонентов |
 | [Бизнес-логика](BUSINESS_LOGIC.md) | Ролевая модель, правила расписания, управление ресурсами |
+| [Идеи развития](FEATURE_IDEAS.md) | Продуктовые предложения, приоритеты и возможный roadmap проекта |
 | [Календарный учебный график](ACADEMIC_CALENDAR.md) | Модель графиков по специальностям, профилям и группам |
 | [База данных](DATABASE.md) | Схема БД, описание таблиц, Flyway миграции |
 | [REST API](API.md) | Все эндпоинты с примерами запросов и ответов |