AS-IS НАБЛЮДЕНИЯ ПО СКРИНШОТАМ
Факультетский сайт / Портфолио / Подготовка к MVP ИИ-контура
Дата фиксации: 2026-04-26

1. Что уже подтверждается по присланным экранам

1.1. Экран загрузки работы студентом
- Используется маршрут /portfolio/upload/.
- На форме присутствуют поля:
  - Год обучения
  - Модуль
  - Название работы
  - Вариант
  - Преподаватель
  - Руководитель
  - Тип работы
  - Компетенция
  - Файл
- На кнопке отправки используется сценарий "Загрузить и Подписать".
- Это означает, что в текущем процессе уже существует идея подтверждения/подписания на стороне студента при загрузке документа.

1.2. Выбор модуля
- Модуль выбирается из выпадающего списка.
- Зафиксированы реальные названия модулей:
  - Введение в информационные технологии
  - Менеджмент
  - Финансы, деньги, кредит, банки
  - а также курсовые варианты тех же модулей
- Это важно для будущей привязки Rule Pack к дисциплине/модулю.

1.3. Выбор типа работы
- Тип работы задается из большого справочника.
- В списке есть как структурированные типы, так и слабоформализуемые:
  - Конспект по лабораторному практикуму
  - Конспект по практическим занятиям
  - Отчет по лабораторному практикуму
  - Отчет по текущим лабораторным практикумам
  - Отчет по текущим практическим занятиям
  - Письменная контрольная работа
  - Презентация
  - Реферат
  - Эссе
  - и другие
- Для MVP это подтверждает правильность подхода: начинать нужно с наиболее структурированных типов.

1.4. Выбор компетенций
- Компетенции выбираются из отдельного интерфейса с чекбоксами.
- Присутствуют крупные группы:
  - Общекультурные
  - Общепрофессиональные
  - Профессиональные
  - Дополнительные компетенции
  - Специальные компетенции
  - Прочие
  - Дополнительные профессиональные
  - Универсальные
  - Общие
- В одном из сценариев видны чекбоксы ОПК, ПК, УК и др.
- Это значит, что система уже хранит компетенции не как свободный текст, а как справочник.
- Потенциально одна работа может быть привязана более чем к одной компетенции.

1.5. Экран преподавательского портфолио
- Используется маршрут /portfolio/?login=yes.
- В преподавательской таблице уже есть фильтры:
  - год
  - группа
  - модуль
  - тип
  - статус
  - ФИО студента
- В таблице уже есть колонки:
  - Дата и время
  - Модуль
  - Название документа
  - ФИО студента / ФИО проверяющего / Руководителя
  - Группа
  - Тип / Компетенция
  - Статус
  - Рецензия
  - Управление
- В управлении уже есть действия:
  - Проверить
  - Удалить
  - Изменить компетенцию
- Это очень важное подтверждение: преподавательский маршрут уже централизован в одной таблице, и новая логика "Рекомендация ИИ" может быть встроена в существующий сценарий, не ломая архитектуру UX.

1.6. Техническое наблюдение из DevTools
- В DOM таблица размечена как table.table-portfolio.
- Заголовки таблицы находятся в строке tr и ячейках td.
- На скриншоте уже видно, что новая колонка "Рекомендация ИИ" может быть добавлена как еще одна td в заголовке и соответствующие ячейки в строках.
- Это косвенно подтверждает, что фронтенд можно расширять по месту, а не обязательно переписывать экран целиком.

1.7. Экран студенческого портфолио
- В студенческой таблице отображаются:
  - дата
  - модуль
  - название документа
  - ФИО проверяющего / руководителя
  - тип / компетенция
  - статус
  - рецензия
  - ссылка на отчет
- Видны реальные финальные значения:
  - статусы "Принято"
  - текстовые уровни вроде "Пороговый уровень", "Базовый уровень"
- Это подтверждает, что текущая система уже умеет отображать результат преподавательского решения на уровне интерфейса студента.

2. Критически важные выводы для MVP

2.1. Архитектурный вывод
Сайт факультета уже содержит три ключевых объекта, на которые можно опереться:
- объект "работа"
- объект "тип работы"
- объект "компетенция"

Следовательно, MVP не нужно строить с нуля как отдельную автономную систему.
Правильнее строить его как расширение существующего маршрута портфолио.

2.2. Вывод по Rule Pack
Rule Pack нужно привязывать минимум к следующей связке:
- модуль
- тип работы
- компетенция

Возможно, в некоторых случаях потребуется четвертый уровень:
- конкретный преподаватель или методический профиль дисциплины

2.3. Вывод по UI
Блок "Рекомендация ИИ" логично встраивается:
- в преподавательскую таблицу как новая колонка
- в экран/окно "Проверить" как расширенная расшифровка

2.4. Вывод по рискам
- Наличие большого числа типов работ означает, что нельзя запускать MVP сразу на всем справочнике.
- Наличие множества компетентностных справочников означает, что без нормализации кодов и правил можно быстро получить хаос.
- Действие "Изменить компетенцию" показывает, что у преподавателя уже есть право ручной коррекции метаданных работы, а значит ИИ не должен считать входные поля абсолютно достоверными.

3. Что пока не подтверждено по скриншотам

На присланных экранах пока не зафиксированы:
- само окно "Проверить" / "Рецензировать"
- поля итогового академического решения преподавателя
- точная форма рецензии
- способ выбора финального уровня
- переход "подтверждено к переносу"
- реальный экран БРС
- форма внесения баллов в БРС
- форма подписи преподавателя в БРС
- технический формат связи между факультетским сайтом и БРС

4. Что особенно важно запросить следующим пакетом

4.1. По сайту факультета
- скрин окна "Проверить" или "Рецензировать"
- какие поля преподаватель меняет вручную
- как выглядит финальное подтверждение
- можно ли сохранить черновик
- как выглядит возврат на доработку

4.2. По БРС
- экран списка ведомостей
- экран нужной ведомости
- момент ввода/редактирования балла
- момент сохранения
- момент подписи

4.3. По интеграции
- есть ли у работы уникальный ID
- есть ли у студента уникальный ID
- как кодируется компетенция
- сколько компетенций может быть у одной работы
- что именно является целевой единицей записи в БРС: уровень, балл, колонка, дата, комментарий

7. Дополнительные наблюдения по второму пакету скриншотов

7.1. Что именно подтверждено новым пакетом

Новый пакет скриншотов очень хорошо раскрывает faculty-side workflow преподавателя:
- таблицу после завершения проверки;
- модальное окно "Рецензировать";
- выбор статуса;
- выбор итогового уровня;
- ввод рецензии;
- экран итогового подписания.

Это уже позволяет довольно точно реконструировать текущий преподавательский сценарий.

7.2. Фактическая логика преподавательского маршрута

По присланным экранам текущий маршрут выглядит так:

1. Преподаватель в таблице портфолио нажимает "Проверить".
2. Открывается модальное окно "Рецензировать".
3. В модальном окне преподаватель задает:
   - статус;
   - итоговую оценку/уровень;
   - тему;
   - рецензию.
4. После заполнения преподаватель нажимает кнопку "Подписать".
5. Система открывает отдельный финальный экран-отчет с итоговой формулировкой решения и таблицей по компетенции.
6. На отдельном экране преподаватель подтверждает решение кнопкой "Подписать".
7. После этого в основной таблице портфолио запись отображается как "Принято", а в столбце рецензии и/или отчета появляется итоговый результат.

Это означает, что в текущем процессе уже существует двухшаговая логика:
- сначала формирование решения;
- затем отдельное подтверждение/подписание решения.

Для MVP это крайне важное наблюдение, потому что teacher approval уже не нужно придумывать "с нуля" как чужеродный процесс. Он в системе уже есть.

7.3. Поля модального окна "Рецензировать"

По скриншотам в модальном окне присутствуют поля:
- Статус
- Оценка
- Тема
- Рецензия

Кнопки и переходы:
- "Посмотреть" на промежуточном шаге
- "Подписать" на финальном шаге

Предварительный вывод:
- поле "Тема" заполняется из названия работы;
- поле "Рецензия" заполняется преподавателем вручную;
- поле "Оценка" представляет собой не число, а категориальную шкалу уровня освоения;
- финальное решение фиксируется только после явного действия подписи.

7.4. Подтвержденная шкала уровней

В выпадающем списке "Оценка" зафиксированы следующие значения:
- Уровень не сформирован
- Пороговый уровень выполнения работы
- Базовый уровень выполнения работы
- Продвинутый уровень выполнения работы

Это подтверждает, что текущая академическая модель сайта построена вокруг уровневой шкалы, а не прямой числовой оценки.

Следствие для проекта:
если БРС требует числовой балл, то между faculty-side оценкой и BRS-side записью должен существовать явный слой трансляции:

"уровень освоения -> числовой балл -> запись в БРС"

Этот слой должен быть формализован отдельно и не должен быть "зашит" неявно внутрь интерфейса.

7.5. Подтвержденная статусная модель преподавателя

В выпадающем списке статуса зафиксированы значения:
- Принято
- На доработку

Это подтверждает, что для MVP минимум один бинарный разворот уже есть:
- положительное решение;
- возврат на доработку.

Следствие:
на первом этапе можно не перегружать MVP большим числом академических статусов.
Правильнее сохранить существующую логику и встроить ИИ как поддержку уже работающего маршрута:

"рекомендация -> преподаватель выбирает принять или отправить на доработку"

7.6. Экран итогового подписания

Отдельный экран после заполнения формы содержит:
- реквизиты образовательной программы;
- учебный модуль;
- группу;
- ФИО студента;
- текст преподавательской рецензии;
- табличную фиксацию:
  - компетенции;
  - вида работы;
  - наименования работы;
  - уровня освоения компетенции;
- подпись преподавателя и дату;
- кнопку "Подписать".

Это один из самых важных экранов во всей системе, потому что именно он задает фактическую "точку официальности".

Следствие для MVP:
если ИИ будет внедряться корректно, то он должен влиять не на "окончательный подписанный результат" напрямую, а на предшествующий этап подготовки решения.

Иными словами:
ИИ должен подготавливать проект решения для преподавателя до нажатия итоговой подписи, но не заменять этот финальный экран.

7.7. Что видно в таблице после завершения процесса

После подписания в преподавательской таблице уже наблюдается:
- статус "Принято";
- дата принятия;
- рецензия в сжатом отображении;
- ссылка "Отчет".

Это означает, что после подписания в системе формируется устойчивый артефакт результата.

Для проектирования это очень важно:
ИИ-система должна не нарушить этот цикл, а встроиться в него так, чтобы:
- статус;
- итоговый уровень;
- рецензия;
- отчет;
- история подписи

оставались совместимыми с текущей логикой сайта.

8. Критически важное замечание: БРС в этом пакете пока не подтверждена

Несмотря на то, что в сообщении пакет описан как содержащий:
- первый экран БРС с ведомостью;
- экран ввода балла;
- экран подписи/подтверждения,

по самим присланным изображениям пока виден только контур сайта gtifem.ru и его преподавательского интерфейса.

Отдельного подтвержденного экрана БРС с:
- выбором ведомости;
- вводом числовой ячейки;
- сохранением результата;
- подписью именно в БРС

в этом пакете пока не зафиксировано.

Это означает следующее:
на текущий момент faculty-side workflow уже хорошо понятен,
а вот BRS-side workflow по-прежнему не подтвержден визуально и технически.

9. Строгий экспертный вывод после двух пакетов скриншотов

Что теперь известно надежно:
- сайт факультета уже содержит полноценный маршрут проверки работ;
- маршрут преподавателя уже построен вокруг статуса, уровневой оценки, рецензии и отдельной подписи;
- итоговое академическое решение уже отделено от первоначального просмотра;
- точка внедрения ИИ очень вероятно должна находиться между "открытием работы" и "итоговым подписанием".

Что еще нельзя считать установленным:
- как именно БРС принимает результат;
- является ли БРС отдельной системой или частично вшита в текущий контур;
- какой именно объект туда переносится: уровень, балл, дата, комментарий, колонка, подпись или их комбинация;
- существует ли автоматизируемый API-канал между факультетским сайтом и БРС.

10. Обновленная рекомендация по архитектуре MVP

На основании этих экранов архитектурно правильнее всего строить MVP так:

1. Не менять финальный экран подписания преподавателя радикально.
2. Добавить ИИ-блок в таблицу и в модальное окно "Рецензировать".
3. Дать ИИ возможность:
   - предложить статус;
   - предложить уровень;
   - предложить черновик рецензии;
   - показать найденные и отсутствующие признаки.
4. Оставить преподавателю:
   - право выбрать финальный статус;
   - право выбрать итоговый уровень;
   - право править рецензию;
   - право финальной подписи.
5. Отдельно спроектировать BRS Adapter только после того, как будет подтвержден реальный экран и технический маршрут БРС.

5. Строгая экспертная оценка текущего состояния

Сильные стороны:
- структура процесса уже цифровая;
- есть справочники модулей, типов работ и компетенций;
- есть преподавательская таблица как естественная точка встраивания;
- есть статусная и рецензионная логика;
- есть визуально наблюдаемая возможность расширения интерфейса.

Слабые места / риски:
- пока не видно экрана, где принимается финальное академическое решение;
- не виден фактический механизм фиксации результата;
- не виден контур БРС;
- не подтверждено, существуют ли удобные API или придется работать через веб-контур;
- высокая вариативность типов работ грозит расползанием пилота, если не ограничить его жестко.

6. Предварительная рекомендация

Для MVP выбирать только:
- один модуль;
- один преподавательский контур;
- один-два типа максимально структурированных работ;
- один ограниченный набор компетенций.

Наиболее вероятные кандидаты:
- отчеты по лабораторным работам;
- отчеты по практическим занятиям;
- конспекты лабораторных и практических занятий - только если структура действительно стандартизирована.